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]
Re: mailing lists for 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: > > > 4.1 in the guidelines repeats the error that I thought was fixed in the > > j-c guidelines saying that each package has its own mailing list. If > > that is intentional, I think that is a *bad* idea, especially to start. > > it was intentional in as much as it was a copy of the jakarta commons > charter :) > > > Don't like the many little lists implied by 11 -- dev + user works fine > > in j-c (I know some disagree, but I personally view this as the key to > > the health of j-c) > > i agree. just dev and user lists. > > in jakarta commons, the common mailing lists hold together the single > community. i'd like to see just one mailing list with components using > prefixing (as per jakarta commons). i'd like to see changes to the draft > so that it's clear that this will be the arrangement. > > opinions? +1 to just one dev and one user list, shared for all components, a la Jakarta Commons. -- 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]
Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/25/05, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > robert burrell donkin wrote: > > this has proved impractical in the jakarta commons. i propose we drop > > point 12. > > "12. The subproject will also provide a single JAR of all stable package > releases. It may also provide a second JAR with a subset of only JDK 1.1 > compatible releases. A gump of nightly builds will also be provided." > > > > > --8<--- > > [X] +1 Get rid! > > [ ] -1 Keep it (please give a reason...) > > -- > > One jar didn't work for commons, no reason to expect it will here. +1. Let's ditch it. -- Martin Cooper > Stephen > > - > 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]
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/25/05, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > Rahul Akolkar wrote: > >>is boils down to the question: does this subproject need it's own > >>sandbox or will neophyte components start in the jakarta commons > >>sandbox? > > > > +1 for sandbox (non-binding) > > > > Its slightly hard to imagine anything otherwise, but maybe I'm just > > used to seeing how commons and taglibs work. If Taglibs join, we have > > a bunch of Taglibs in sandbox, they will need to be housed somewhere, > > and I don't see them migrating to commons sandbox ;-) Right? > > Yes, +1 to a sandbox. Although it can create issues, I think has more > benefits than downsides. +1 -- Martin Cooper > Stephen > > - > 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]
