* [Lustre-devel] Lustre community collaboration
2010-09-13 5:26 ` [Lustre-devel] Lustre community collaboration Eric Barton
@ 2010-09-13 11:32 ` Peter Bojanic
2010-09-13 11:40 ` Peter Bojanic
1 sibling, 0 replies; 3+ messages in thread
From: Peter Bojanic @ 2010-09-13 11:32 UTC (permalink / raw)
To: lustre-devel
Hi Eric,
I encourage folks to use the most appropriate mailing list (-discuss, -devel), etc. for discussion. Perhaps Bill can add to the agenda on Friday a discussion item on this, including interest in a hpcfs-specific mailing list. It will certainly make it easier for participants to come and go and to catch up through archives on historical discussions (the lists are easily mirrored to Google Groups).
I wholeheartedly support your notion of a sustainable development and keeping the development branches healthy. I expect the use of git will help us considerable here and rigorous standards for quality assurance testing and reporting will be even more important with an increasingly diversified contributor pool.
How can I convince you and Andreas to initiate and lead a "Contribution" working group that will set these standards? lustre.org may be a good repository for the working material but Google Apps is a compelling alternative. This is another possible Friday discussion topic.
Cheers,
Bojanic
On 2010-09-12, at 10:26 PM, Eric Barton wrote:
> 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
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Lustre-devel] Lustre community collaboration
2010-09-13 5:26 ` [Lustre-devel] Lustre community collaboration Eric Barton
2010-09-13 11:32 ` Peter Bojanic
@ 2010-09-13 11:40 ` Peter Bojanic
1 sibling, 0 replies; 3+ messages in thread
From: Peter Bojanic @ 2010-09-13 11:40 UTC (permalink / raw)
To: lustre-devel
(Sorry for the re-send but the list of addresses was badly corrupted with mismatched quotes and had to be fixed. All the more reason for a mailing list, ASAP)
Hi Eric,
I encourage folks to use the most appropriate mailing list (-discuss, -devel), etc. for discussion. Perhaps Bill can add to the agenda on Friday a discussion item on this, including interest in a hpcfs-specific mailing list. It will certainly make it easier for participants to come and go and to catch up through archives on historical discussions (the lists are easily mirrored to Google Groups).
I wholeheartedly support your notion of a sustainable development and keeping the development branches healthy. I expect the use of git will help us considerable here and rigorous standards for quality assurance testing and reporting will be even more important with an increasingly diversified contributor pool.
Can I convince you and Andreas to initiate and lead a "Contribution" working group that will set these standards? I'd be willing to facilitate if you require that kind of support. lustre.org may be a good repository for the working material but Google Apps is a compelling alternative. This is another possible Friday discussion topic.
Cheers,
Bojanic
On 2010-09-12, at 10:26 PM, Eric Barton wrote:
> 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
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread