All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: lustre-devel@lists.lustre.org
Subject: [lustre-devel] A new drivers/staging/lustre
Date: Fri, 08 Jun 2018 07:50:37 +1000	[thread overview]
Message-ID: <87efhimfki.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <DM3PR1101MB1213BB514F8D6E25F725BB1DCB640@DM3PR1101MB1213.namprd11.prod.outlook.com>

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>

  reply	other threads:[~2018-06-07 21:50 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-07  2:29 [lustre-devel] A new drivers/staging/lustre NeilBrown
2018-06-07  5:25 ` James Simmons
2018-06-07  9:58   ` NeilBrown
2018-06-07 13:07     ` Doug Oucharek
2018-06-07 13:25       ` Patrick Farrell
2018-06-07 21:50         ` NeilBrown [this message]
2018-06-07 21:38       ` NeilBrown
2018-06-07 23:06         ` Dilger, Andreas
2018-06-07 23:27           ` Patrick Farrell
2018-06-08  5:45           ` NeilBrown
2018-06-12  0:12           ` James Simmons
2018-06-12  1:24             ` NeilBrown
2018-06-12  0:21     ` James Simmons
2018-06-12  1:16       ` NeilBrown
2018-06-07 22:46 ` Dilger, Andreas
2018-06-07 22:53   ` Doug Oucharek
2018-06-07 23:24     ` Dilger, Andreas
2018-06-08  6:00       ` NeilBrown
2018-06-08  6:07   ` NeilBrown
2018-06-12  0:13 ` James Simmons
2018-06-12  0:55   ` NeilBrown
2018-06-13 21:46     ` James Simmons
2018-06-13 22:31       ` NeilBrown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87efhimfki.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=lustre-devel@lists.lustre.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.