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 >> >> > _______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
