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
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 > >
(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 > >
Bill, The list of addresses is getting rather unwieldily. Even after hand-tuning the recipient list, I got a number of bounces due to bad addresses. How would you care to handle the mailing list? We can create a list on lustre.org and give you administrator rights over it or you could set something up on Google under HPCFS control and add lustre-discuss as a member. In any case, I''m re-posting my response because lustre-discuss holds posts with too many recipients. Cheers, Bojanic On 2010-09-13, at 4:32 AM, Peter Bojanic wrote:> 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 >> >> >