<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
<br>
For what it’s worth, I agree strongly with Andreas about getting this in sync with the current Intel branch FIRST. There is far more additional code/history there in the form of already complete features and fixes than here in cleanups.<br>
<br>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> lustre-devel <lustre-devel-bounces@lists.lustre.org> on behalf of Dilger, Andreas <andreas.dilger@intel.com><br>
<b>Sent:</b> Thursday, June 7, 2018 6:06:23 PM<br>
<b>To:</b> NeilBrown<br>
<b>Cc:</b> Drokin, Oleg; lustre-devel<br>
<b>Subject:</b> Re: [lustre-devel] A new drivers/staging/lustre</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On Jun 7, 2018, at 15:38, NeilBrown <neilb@suse.com> wrote:<br>
> <br>
> On Thu, Jun 07 2018, Doug Oucharek wrote:<br>
> <br>
>> What is the focus of landings in this tree? There are two things needing to be done for an upstream Lustre:<br>
>> <br>
>> <br>
>> * Get the source code to meet the Linux guidelines so it is acceptable to be in mainline.<br>
>> * Get the binary product to have all the features and bug fixes that are in the Intel community tree so end users are interested in using the upstream version (users are unlikely to use a version of Lustre which is not current).<br>
>> <br>
>> For the now-deleted staging area, we were supposed to be focusing on the first item but were submitting patches for the second item (syncing with Intel tree). In my opinion, this is the core reason for never being able to get out of staging and getting
deleted.<br>
> <br>
> My (undoubtedly biased) perspective on the history of lustre in staging<br>
> goes like this:<br>
> There are two things needed for some out-of-tree code to get into<br>
> mainline Linux: the code needs to be integrated and the community needs<br>
> to be integrated (or a new sub-community needs to form).<br>
> In the case of lustre, the code was never really integrated because the<br>
> community never really tried to integrate.<br>
<br>
One of the issues here was that the group (not Intel) that submitted the<br>
Lustre code to the staging tree promptly abandoned it for a couple of<br>
years after they submitted it upstream, after promising the community<br>
that they were in it for the long run. That put the upstream integration<br>
behind the eight-ball from the start.<br>
<br>
> Integrating and becoming<br>
> part of the Linux community takes time and effort, and it is quite<br>
> possible that management for various developers didn't allocate enough<br>
> time over a long enough period. Integrating also requires a change in<br>
> attitude and I don't see much evidence of that. I see clear evidence of<br>
> an "us and them" attitude among (some) lustre developers - almost as<br>
> though upstream linux is hostile territory full of unfriendly developers<br>
<br>
Ah, but it *is* hostile territory, if you are not among the "in crowd".<br>
Christoph can get any change he wants to be accepted, but if someone else<br>
tries to push something similar it can be rejected outright or ignored<br>
for months or years.<br>
<br>
> who always reject our excellent code (even though they have lots of<br>
> horrible code themselves). *We* need to see ourselves as part of the<br>
> Linux community, and we need to care about all of Linux as though it was<br>
> all ours (it *is* all ours, but *we* are a much larger group now).<br>
> <br>
> Yes, the current code needs to be improved, bugs need to be fixed, and<br>
> features need to be added. The order in which these is done is not the<br>
> most important things - if it were, Greg would have never accepted any<br>
> new features. However he *did* accept them, but tried to remind the<br>
> lustre developers that there was other work to do.<br>
> <br>
> Working together in one (single) community requires give-and-take.<br>
> Greg's behaviour as just described seems to be evidence of<br>
> give-and-take. I think he kicked lustre out of staging because he<br>
> concluded that he was never going to get the matching give-and-take in<br>
> return.<br>
> <br>
> So to answer your opening question, my focus for this tree is to train<br>
> any lustre developers who wish to engage about how to be part of the<br>
> Linux community. As I've already said - I will accept features but I<br>
> prefer cleanups first. I don't want to try to explain further than that<br>
> because it will be too hypothetical and unhelpful. We - the Linux<br>
> community - don't work in hypotheticals. We work with concrete objects<br>
> like patches. So send me a patch and I will tell you what I think of<br>
> that specific patch. It is up to you to generalise what I say to other<br>
> patches. It might also be up to you to argue your case and tell me why<br>
> I'm wrong. I'll be patient (because good upstream maintainers are) but<br>
> patience doesn't last forever (for Greg, it lasted about 5 years - I<br>
> hope mine won't be tried to that extent).<br>
<br>
Like I said in my other email, I think having another fork of the Lustre<br>
tree, especially one that is starting from two-year-old code is likely to<br>
fail, because there will be twice as much effort spent to maintain the two<br>
trees. I'd rather see the cleanups and features go hand-in-hand into the<br>
same tree. I'd be thrilled to have more reviews done on the features before<br>
they are landed, but we can't just stop all feature development for a year<br>
or two (or five) while the code is merged into the upstream kernel.<br>
<br>
>> There are some very big (as in code size) features missing from<br>
>> upstream. For example, Multi-Rail. When should that be pushed<br>
>> relative to code cleanups?<br>
> <br>
> Never add features to ugly code - fix the code first.<br>
> The doesn't mean you cannot add any feature to lustre until all of<br>
> lustre is beautiful. But it does mean that if I can see in a patch some<br>
> ugly code and a new feature, then I won't be happy. First clean up just<br>
> enough of the ugliness so that it won't be visible in the patch that<br>
> adds the feature.<br>
<br>
The issue is that we _can't_ just stop the development of new code/features<br>
for such a long time. There are huge supercomputers being deployed or in<br>
planning that depend on these new features, or they wouldn't have been<br>
developed in the first place.<br>
<br>
Consider if the NFSv4 spec was written and the code was developed, and you<br>
were told you needed to go back to NFSv2 and start again?<br>
<br>
> But again, this is getting a bit too hypothetical. If you care about a<br>
> feature, then post a patch. We can take it from there. The fact that<br>
> you care enough to post a patch cares significant weight - a lot more<br>
> weight than just asking about some feature.<br>
<br>
We definitely aren't at the point of "asking for some feature to be developed".<br>
At a minimum the starting point of the new upstream code needs to be the<br>
current release, or any resources that could possibly be put towards improving<br>
the Lustre code would be squandered on porting all of those patches to the<br>
upstream tree. I'm fine with spending time to improve the code that exists<br>
today, but lets not start with a huge deficit from the outset.<br>
<br>
Cheers, Andreas<br>
--<br>
Andreas Dilger<br>
Lustre Principal Architect<br>
Intel Corporation<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
lustre-devel mailing list<br>
lustre-devel@lists.lustre.org<br>
<a href="http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org">http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org</a><br>
</div>
</span></font></div>
</body>
</html>