On Sat, 2005-07-02 at 14:52 -0400, 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. ;-)
yep. vaporware can take care of itself :) > 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. then at some time later, a promotion vote is held. > 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.) +1 > 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. +1 maybe the whole sandbox issue should have it's own subsection detailing how the sandbox is to work and how promotion should work. > > is 19 needed in addition to 15? > > This seems to be a different topic entirely, but my vote would be yes, > because 15 relates only to the proposal, while 19 relates to the > component as it exists, and is developed, within the subproject. sorry: meant 17 - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
