On Sat, 2005-07-02 at 12:27 -0700, Phil Steitz wrote: > Martin Cooper wrote: > > On 6/23/05, robert burrell donkin <[EMAIL PROTECTED]> wrote: > > > >>On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: > >> > >><snip> > >> > >>>Interpreted literally, 17 goes against standard practice in jakarta (or > >>>apache, to my knowledge, other than in the incubator). I would > >>>recommend that new packages require existing committers to support them. > >>>I would at least recommend changing "Anyone" to "Any apache committer." > >>> If an individual has already contributed enough to be voted in as a > >>>committer, then that should be done in a separate VOTE. > >> > >>this certainly doesn't reflect the current practise in the jakarta > >>commons. though anyone can propose a new component, they really won't > >>have any chance of winning a VOTE unless they have the support of > >>existing committers. > >> > >>there is also the issue of the incubator: any new component bringing > >>code from outside apache would need to be incubated. > > > > > > We have a few different scenarios here, I believe. > > > > 1) A new component is proposed, with no existing code to back it up. > > I'm not sure that this has ever happened in Jakarta Commons, or is > > likely to happen in the new subproject, so frankly I don't much care > > about how that would work. ;-) > > > > 2) A new component is proposed by an existing Apache committer. This > > will almost certainly be backed up by code in the sandbox. > > Historically, in Jakarta Commons, there hasn't so much been a > > proposal, but rather a new project materialises in the sandbox. This > > has, in part, been responsible for dregs that lie around forever. This > > could be handled through the "after 6 months" vote that has been > > mentioned in another thread. > > > > 3) A new component is proposed by a non-committer. Code to back up > > such a proposal would necessarily be coming from somewhere else. This > > is a situation in which the component should, I believe, come in > > through the incubator. The incubation process would resolve the > > questions of committers, etc., before the component lands in the new > > subproject. (I want to emphasise here, for the folks that might be > > concerned about this, that incubation need not be an onerous process, > > and can happen rather quickly, if conditions are right.) > > > > I would suggest that we come up with wording in the charter to reflect > > these scenarios, rather than trying to crib from the Jakarta Commons > > charter in this instance. > > Agreed. After a little more discussion, we should rewrite this.
+1 anyone feel like jumping volunteering to come up with a draft? > FWIW, I did NOT mean to suggest that only committers could *suggest* > projects, > only that to actually get one *started*, support from ideally more than > one committer is required. I think the following is also possible, > since at least one j-c component started this way: > > 4) A new component is proposed by a (some) non-committer(s). One or > more existing committers are interested in working on the component. > The initial code base is built up incrementally in the sandbox from > patches contributed by community members. This is more or less the way > we started commons-math. The initial code base was contributed > incrementally, with patches discussed, reviewed and in some cases > refactored before being committed. I don't see anything wrong with this, > nor requiring a trip through the incubator. +1 but i think that this can be covered as a subcase of the sandbox route. the key factor is that the code is original. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
