<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div id="x_compose-container" itemscope="" itemtype="https://schema.org/EmailMessage" style="direction:ltr">
<span itemprop="creator" itemscope="" itemtype="https://schema.org/Organization"><span itemprop="name"></span></span>
<div>
<div style="direction:ltr">Does this mean we would be pushing patches to Gerrit rather than having to email them out? I believe for the test system to work automatically, the answer is yes. </div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">Doug</div>
<div><br>
</div>
<div class="x_acompli_signature"></div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><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 5:46:26 PM<br>
<b>To:</b> NeilBrown<br>
<b>Cc:</b> lustre-devel<br>
<b>Subject:</b> Re: [lustre-devel] A new drivers/staging/lustre</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:11pt;">
<div class="PlainText">On Jun 6, 2018, at 20:29, NeilBrown <neilb@suse.com> wrote:<br>
> Greg's patch to remove lustre has now landed in this staging-next tree,<br>
> so I suspect it will get to Linus before too long. So I have to find a<br>
> new place to work on lustre.<br>
> <br>
> I've added 2 branches to<br>
> git://git.neil.brown.name/linux<br>
> <br>
> lustre:<br>
> is based on Greg's patch that removes lustre, and starts with a<br>
> revert of the patch, followed by a merge of v4.17.<br>
> I plan to merge each release and RC from Linus, and also<br>
> add lustre patches that I think are "ready". That will usually mean<br>
> they have been posted to this list at least a week earlier, and<br>
> have not had a credible negative response (Acks and Reviewed-by<br>
> would be nice).<br>
> I plan to update this branch about once a week, and to never rebase<br>
> it.<br>
> <br>
> lustre-testing:<br>
> is based on 'lustre' and has most of my current lustre-related work.<br>
> It includes assorted patches that are not specifically for lustre<br>
> (rhashtables mostly at the moment). Patches will move from here<br>
> to 'lustre' or to mainline when they are ready.<br>
> I plan to update this branch on most days that I work on Lustre,<br>
> and expect it to rebase frequently.<br>
<br>
We also have a clone of Greg's staging branch on our Gerrit server,<br>
which could be replaced with a "vanilla" upstream kernel clone that<br>
holds a copy of the for-upstream Lustre tree.<br>
<br>
One benefit of hosting the tree on the Gerrit server is that it is<br>
much easier to get automated testing of the patches (a lot or a little)<br>
to ensure that the code doesn't break anything obvious.<br>
<br>
> I'm happy to review and, if acceptable, apply patches from other<br>
> developers. I have fairly high standards, but if I don't accept your<br>
> patch I'll explain why and possible help fix it.<br>
> I'm happy to accept enhancements and new features, but these need<br>
> to be of a quality that would be accepted upstream.<br>
> I'm only interested in client-side code at present - nothing that is<br>
> only used on the server. I do want to include server-side eventually,<br>
> but I need some focus for now.<br>
> <br>
> I hope to get to a stage where the code is of suitable quality that I<br>
> can submit it to Linux as a new filesystem. I hope that will happen<br>
> this year.<br>
<br>
I think one major drawback of starting with the from-staging version of<br>
the code is that this is significantly behind the out-of-tree master<br>
code and would need a lot of effort to catch up.<br>
<br>
I think the only way we are going to make this work is if the cleanups<br>
go into the same repo as the ongoing development. Otherwise, we'll be<br>
back in the same situation as we are now where there are two different<br>
versions of the code and we need to move patches back and forth between<br>
them.<br>
<br>
On the plus side, this will avoid code drift, and the extra efforts of<br>
porting patches back and forth. On the minus side, it means (on some<br>
fronts) that the code will regress from what is upstream, because we<br>
don't have all of the trivial whitespace cleanups and other drive-by<br>
kernel newbie patches that went into the upstream client. However, it<br>
does mean that those cleanups would now become part of the single code<br>
tree and not be lost again in the future.<br>
<br>
This would also mean some restructuring of the current Lustre tree so<br>
that it could build as a drop-in at linux/fs/lustre but that is probably<br>
a good idea for the long term in any case.<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>
</body>
</html>