<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 22 Jan 2025, at 23:54, NeilBrown <neilb@suse.de> wrote:</div><br class="Apple-interchange-newline"><div><div>On Mon, 20 Jan 2025, Alexey Lyahkov wrote:<br><blockquote type="cite"><br><blockquote type="cite">On 19 Jan 2025, at 11:03, NeilBrown <neilb@suse.de> wrote:<br><br>On Sun, 19 Jan 2025, Alexey Lyahkov wrote:<br><blockquote type="cite">Neil,<br><blockquote type="cite"><br><br><blockquote type="cite"><br>It does not hep that there are what 3? 4? trees, not "dual-tree" by any<br>stretch of imagination.<br><br>There's DDN/whamcloud (that's really two trees), there's HPE, LLNL<br>keeps their fork still I think (thought it's mostly backports?). There<br>are likely others I am less exposed to.<br></blockquote><br>"dual-tree" maybe isn't the best way of describing what was wrong with<br>the previous approach. "upstream-first" is one way of describing how it<br>should be run, though that needs to be in understood correctly.<br><br>Patches should always flow upstream first, then flow downstream into<br>distro. So I write a patch in my own devel tree. I post it or submit a<br>pull request and eventually it is accepted into the maintainers<br>"testing" tree (upsream from me). There it gets more testing and moves<br>to the maintainers "next" tree from which it is pulled into linux-next<br>for integration testing. Then it goes upstream to Linus (possibly<br>through an intermediary). From Linus it goes to -stable and to various<br>distros etc. Individual patches are selected for further backporting to<br>all sorts of different LTS tree.<br><br>Occasionally there are short-cuts. I might submit a patch from my tree<br>to a SUSE kernel before it is accepted upstream, or maybe even before it<br>is sent if it is urgent. But these are not the norm.<br><br>But you know all this I expect. It isn't about the total number of<br>trees. It is about the flow of patches which must all flow through Linus.<br>And developers must develop against current linus, or something very<br>close to that. Developing against an older kernel is simply making more<br>work for yourself.<br></blockquote><br>This will don’t work. Let explain situation in past.<br></blockquote><br>No. I'm not at all interested in explanations of why it won't work.<br><br>I'm only interested in suggestions of how to make it work, and offers of<br>help.<br><br></blockquote>If you have a good way how to solve such situation, which had crazy brain in past.<br>Please share a way how to avoid lustre source code fragmentation because of freeze a code at the different stage in different distributions.<br>Ubuntu might have a modern lustre with 6.5 kernel, but Redhat had frozen a lustre version in 3 releases in past and these clients not compatible each other.<br>And not compatible with installed server.<br>So question - who will do such support ? Did you have an ideas how to solve this problem?<br><br></blockquote><br>sorry - I didn't mean to go quite on you - I've been busy :-)<br><br>It's not entirely clear to me what the problem is.<br>You talk about clients not being compatible with each other or with the<br>server, but Andreas has said that there is good compatibility between<br>different versions so I wonder if that is really (still) an issue.<br></div></div></blockquote><div><br></div><div>Lustre have good compatibility, but not at all cases. It have tested with +/-1 release only.</div><div>I remember a several cases then it caused a probles with clients more than one release old.</div><div>As about Andreas, Andreas don’t work with client support for long time so don’t know about all problems in this area.</div><div><br></div><blockquote type="cite"><div><div><br>Keeping different kernels up to date with new updates is something that<br>the linux-stable team does all the time. We do it at SUSE to. It isn't<br>that hard.<br>You identify which patches *need* to be backported (ideally when the<br>patch is created but that isn't always easy) and you use tools to help<br>you backport them.<br></div></div></blockquote><div>So Lustre developers needs control all stable kernels and think which patch needs back ported and send it to Distro owner </div><div>And for each LTS kernels on the <a href="http://kernel.org">kernel.org</a>.. I think it increase a work dramatically.</div><div><br></div><blockquote type="cite"><div><div><br>Certainly there is effort involved, but maintaining a package that works<br>on a large set of kernels also involves effort. It isn't clear to me<br>that it is *more* effort, just *different* effort.<br><br>NeilBrown<br></div></div></blockquote></div><br><div>Alex</div></body></html>