From: Eric Barton <eeb@whamcloud.com>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] Lustre community collaboration
Date: Mon, 13 Sep 2010 14:26:04 +0900 [thread overview]
Message-ID: <002d01cb5304$78de72d0$6a9b5870$@com> (raw)
In-Reply-To: <EEE116340D7B44499F3DC2765F63852D@BillGWAYLAPTOP>
Peter,
I'd like to lend my support to the suggestions you made on community
collaboration that Bill Boas quoted in his last HPCFS email. It seems
obvious to me that community discussions should take place on a
lustre.org mailing list. I note you mentioned lustre-discuss (which
I've cc-ed) - but I would have assumed lustre-devel since I think
making coherent sense of development is the single most important
issue for the community. Actually a new dedicated list, as you
suggest, is better and keeps the existing list clean for technical
issues.
If I had to prioritise community discussion topics, I'd want to put
the contribution process right at the top of the list. My biggest
concern is keeping the code clean and stable - I think taking care of
that makes everything else 100x easier.
Firstly, I think there should be a requirement for "no surprises" when
it comes to upstream contributions. All landings have the potential
to destabilize the tree or introduce architectural debt so I don't
think it's reasonable to expect upstream contributions to land at
short notice, whether the rush is by design or by
omission. Contributions should be planned and discussed throughout the
development process to ensure landing proceeds smoothly for both the
upstream gatekeeper and the contributor. If people wish to benefit
from the presence of a Lustre community, they must accept that
membership also has its duties and responsibilities.
Secondly, I think providing some sort of QA collateral should be
required for upstream contributions. Code reviews, a test plan and a
test history in standard formats could all relieve the burden on the
upstream gatekeeper. The 2.0 stabilization effort demonstrated the
value of a test results database for visualizing the progress towards
stability of features in development and directing testing effort on
them. I think we'd all benefit if we could adopt a similar process
across the community.
Cheers,
Eric
Eric Barton
CTO Whamcloud, Inc.
Tel: +44 (117) 330 1575
Mob: +44 (7920) 797 273
next parent reply other threads:[~2010-09-13 5:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <EEE116340D7B44499F3DC2765F63852D@BillGWAYLAPTOP>
2010-09-13 5:26 ` Eric Barton [this message]
2010-09-13 11:32 ` [Lustre-devel] Lustre community collaboration Peter Bojanic
2010-09-13 11:40 ` Peter Bojanic
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='002d01cb5304$78de72d0$6a9b5870$@com' \
--to=eeb@whamcloud.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.