On Thu, Oct 24, 2002 at 10:28:40PM +0100, Stephen Colebourne wrote: > From: "Justin Erenkrantz" <[EMAIL PROTECTED]> > > As we have discussed before, I believe we are going to stick with a > > single email list for all of commons. If/when a particular group > > takes over the mailing list, someone could suggest a new mailing list > > to be created. (I'd say majority of the participants on the list get > > to decide if the new list should be created.) > > > > I prefer that we evolve the infrastructure rather than hash out an > > infrastructure from the beginning. -- justin
Right. Forward motion good. Blocking bad. > Please, noooo ;-) > > The j-c commons mailing list is already very, very busy. A reorg of this > nature is the time to think about breaking that down into smaller lists. if > done correctly, the committers on the mailing lists naturally fall out to be > those that should have access to that part of the CVS, very much like j-c > current (pretty successful) model, but with more controls. Let's plan out the *style* of multiple lists. But until we actually get the components to fall into those lists, then let's defer their creation and final specification. Stephen listed a bunch of components and a possible breakdown, but we can't choose that UNTIL we know those components will transfer themselves. And who knows what is going to arrive? I have zero visibility into the assortment of Avalon, J-C, and XML reusable components. So I'm advocating "figure them out on-demand *as* new components arrive". Here we go: [ ] One mother general@ list, with specific breakouts when needed [ ] Per-concept mailing lists (define "concept" however) [ ] Per-language mailing lists [ ] ____________________________________________ > The exception comes if two languages share a mailing list. In that case CVS > commit priveledges should probably be separated by language. I think commit privs should be per-component. That easily solves the per-language issue above, and it also solves the cross-concept-domain problem (e.g. there is no way a Xerces developer should have commit access to the HTTP client code (C or Java!) unless they demonstrated commitment and competency). I'll also state: the "per-component" rule should be the default. There is *NOTHING* preventing multiple components from sharing the same set of committers. If 5 components want to aggregate their committer maintenance, then fine. It is up to those 5 to choose that. [ and the Commons PMC should be defining ways to enable this and make it easy for the components to self-organize ] Cheers, -g -- Greg Stein, http://www.lyra.org/
