[lustre-devel] A new drivers/staging/lustre
NeilBrown
neilb at suse.com
Thu Jun 7 14:50:37 PDT 2018
On Thu, Jun 07 2018, Patrick Farrell wrote:
> Doug,
>
> Another thought about the core reason.
>
> Commitment to this. The existing code state (weird, abandoned 2.4.something code) and merge rules seemingly made it impossible to shift development in this direction in any meaningful way, so perhaps it's chicken and egg... but as long as Lustre is released and developed primarily out of tree, I can't see this working. Would it just be a "sync everything but still do releases" approach? Is that viable? Etc.
>
> Thoughts appreciated.
Yes, commitment is important - from management was well as developers.
If you think getting lustre upstream is important then make sure you
manager understands why.
Having development in two separate tree - one heading for upstream
inclusion, the other used by customers - could be a problem and
certainly needs an end date, but I think it is our best option at the
moment (even though Greg claimed it was part of his reason for ejecting
lustre from staging).
I think that imposing an upstream development module on (what I've
decided to call) legacy-lustre would be a constant battle with a low
success rate. Conversely moving code from legacy-lustre into an
upstream work-flow should be quite manageable providing time and skills
are available.
I would really like to be able to point to a location in the
legacy-lustre git history and be able to say "linux-lustre has all
features up to this point", and then to progressively copy features
across and move that point forward. As a feature is copied, we make
sure it conforms with upstream standards. I won't be doing any of this
until I'm really happy with what is already in linux-lustre, but I won't
try to set priorities for other people.
Once we get to the point where linux-lustre has feature-parity with
legacy-lustre, then we can discuss doing development in linux-lustre
first, and copying it across to legacy-lustre only as long as people
care.
Thanks,
NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20180608/7da00f5f/attachment.sig>
More information about the lustre-devel
mailing list