Re: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
robert burrell donkin wrote: Agreed. After a little more discussion, we should rewrite this. +1 anyone feel like jumping volunteering to come up with a draft? Working on this now... Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: > >> > >> > >> > >>>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]
Re: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: 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. 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. Phil 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. +1 - different topic and one of the charming features of j-c that should, IMHO, be carried over. -- Martin Cooper - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/23/05, robert burrell donkin <[EMAIL PROTECTED]> wrote: > On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: > > > > > 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. > 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. -- Martin Cooper > - robert > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: > 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. is 19 needed in addition to 15? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
