You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by robert burrell donkin <ro...@blueyonder.co.uk> on 2005/06/23 23:43:26 UTC
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:
<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.
is 19 needed in addition to 15?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components [WAS Re: [PROPOSAL] subproject that's a home for
bricks reusable in java web applications]
Posted by Phil Steitz <ph...@steitz.com>.
robert burrell donkin wrote:
<snip/>
>>
>>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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components [WAS Re: [PROPOSAL] subproject that's a home
for bricks reusable in java web applications]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sat, 2005-07-02 at 12:27 -0700, Phil Steitz wrote:
> Martin Cooper wrote:
> > On 6/23/05, robert burrell donkin <ro...@blueyonder.co.uk> 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components [WAS Re: [PROPOSAL] subproject that's a home for
bricks reusable in java web applications]
Posted by Phil Steitz <ph...@steitz.com>.
Martin Cooper wrote:
> On 6/23/05, robert burrell donkin <ro...@blueyonder.co.uk> 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. 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components
Posted by Steven Caswell <st...@gmail.com>.
+1
On 7/5/05, robert burrell donkin <ro...@blueyonder.co.uk> wrote:
> there doesn't see any enthusiasm for those new ideas and no objections
> to phil's draft. i think we should go ahead and make the changes
> suggested by phil.
>
> - robert
>
> On Sun, 2005-07-03 at 22:39 +0100, robert burrell donkin wrote:
> > On Sun, 2005-07-03 at 13:13 -0700, Phil Steitz wrote:
> > > Here is a stab at replacement text for 15, 17 and 18.
> >
> > great :)
> >
> > looks good but threw up some ideas...
> >
> > > 15-1 Any member of the community may propose a new package. To be
> > > accepted, a package proposal must receive majority approval of the
> > > subproject committers and at least one committer must volunteer to serve
> > > as an initial package team member. Proposals should identify the
> > > rationale for the package, its scope, its interaction with other
> > > packages and products, the <insert-subproject-name> resources, if any,
> > > to be created, the initial source from which the package is to be
> > > created, and the sponsoring committers.
> > >
> > > 15-2 The subproject will maintain an svn repository, referred to as the
> > > <i>sandbox</i>, as a workplace for new packages. Once approved, new
> > > packages must all begin in the sandbox. Any apache committer may
> > > contribute code directly to the sandbox and this code may form the
> > > initial source for new packages. Code from existing apache projects
> > > can, with the support of the contributing projects, also be imported
> > > directly into the sandbox. Finally, patches contributed incrementally
> > > by community members may be committed to the sandox by a subproject
> > > committer. If the initial source for a new package is from outside of
> > > apache, the new package must be brought into apache via the apache
> > > incubator.
> >
> > not sure but wonder whether we might need to tightening this last
> > sentence so that it can't be read as implying that having only a portion
> > of the initial source from external sources is ok. opinions?
> >
> > > 15-3 A majority vote among subproject commiters is required to
> > > "graduate" a package from the "sandbox" to become a proper package. Only
> > > proper packages may make releases. If a package remains in the sandbox
> > > for more than six months, a majority vote will be required to prevent
> > > its being archived from svn and removed from the subproject web site and
> > > any other public locations (e.g. nightly or continuous integration
> > > builds). Proper packages may not release code with dependencies on
> > > sandbox packages.
> >
> > 1. i wonder whether it'd be better to have bi-annual reviews to simplify
> > administration. in january, review all sandbox components which were
> > created before the previous july. could run them as a single vote.
> >
> > 2. i wonder whether we actually need to remove them from svn: just could
> > copy them into an archive directory.
> >
> > - robert
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
--
Steven Caswell
steven.caswell@gmail.com
Take back the web - http://www.mozilla.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components
Posted by Phil Steitz <ph...@steitz.com>.
robert burrell donkin wrote:
> there doesn't see any enthusiasm for those new ideas and no objections
> to phil's draft. i think we should go ahead and make the changes
> suggested by phil.
I went ahead and updated, making some small changes to (hopefully)
address the points above. I marked the items to be replaced as "DELETED"
and added the replacement items at the end. Given that the discussion
has referenced item numbers, I did not want to mess up the numbering.
We can reorder as appropriate when the music stops.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
there doesn't see any enthusiasm for those new ideas and no objections
to phil's draft. i think we should go ahead and make the changes
suggested by phil.
- robert
On Sun, 2005-07-03 at 22:39 +0100, robert burrell donkin wrote:
> On Sun, 2005-07-03 at 13:13 -0700, Phil Steitz wrote:
> > Here is a stab at replacement text for 15, 17 and 18.
>
> great :)
>
> looks good but threw up some ideas...
>
> > 15-1 Any member of the community may propose a new package. To be
> > accepted, a package proposal must receive majority approval of the
> > subproject committers and at least one committer must volunteer to serve
> > as an initial package team member. Proposals should identify the
> > rationale for the package, its scope, its interaction with other
> > packages and products, the <insert-subproject-name> resources, if any,
> > to be created, the initial source from which the package is to be
> > created, and the sponsoring committers.
> >
> > 15-2 The subproject will maintain an svn repository, referred to as the
> > <i>sandbox</i>, as a workplace for new packages. Once approved, new
> > packages must all begin in the sandbox. Any apache committer may
> > contribute code directly to the sandbox and this code may form the
> > initial source for new packages. Code from existing apache projects
> > can, with the support of the contributing projects, also be imported
> > directly into the sandbox. Finally, patches contributed incrementally
> > by community members may be committed to the sandox by a subproject
> > committer. If the initial source for a new package is from outside of
> > apache, the new package must be brought into apache via the apache
> > incubator.
>
> not sure but wonder whether we might need to tightening this last
> sentence so that it can't be read as implying that having only a portion
> of the initial source from external sources is ok. opinions?
>
> > 15-3 A majority vote among subproject commiters is required to
> > "graduate" a package from the "sandbox" to become a proper package. Only
> > proper packages may make releases. If a package remains in the sandbox
> > for more than six months, a majority vote will be required to prevent
> > its being archived from svn and removed from the subproject web site and
> > any other public locations (e.g. nightly or continuous integration
> > builds). Proper packages may not release code with dependencies on
> > sandbox packages.
>
> 1. i wonder whether it'd be better to have bi-annual reviews to simplify
> administration. in january, review all sandbox components which were
> created before the previous july. could run them as a single vote.
>
> 2. i wonder whether we actually need to remove them from svn: just could
> copy them into an archive directory.
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-07-03 at 13:13 -0700, Phil Steitz wrote:
> Here is a stab at replacement text for 15, 17 and 18.
great :)
looks good but threw up some ideas...
> 15-1 Any member of the community may propose a new package. To be
> accepted, a package proposal must receive majority approval of the
> subproject committers and at least one committer must volunteer to serve
> as an initial package team member. Proposals should identify the
> rationale for the package, its scope, its interaction with other
> packages and products, the <insert-subproject-name> resources, if any,
> to be created, the initial source from which the package is to be
> created, and the sponsoring committers.
>
> 15-2 The subproject will maintain an svn repository, referred to as the
> <i>sandbox</i>, as a workplace for new packages. Once approved, new
> packages must all begin in the sandbox. Any apache committer may
> contribute code directly to the sandbox and this code may form the
> initial source for new packages. Code from existing apache projects
> can, with the support of the contributing projects, also be imported
> directly into the sandbox. Finally, patches contributed incrementally
> by community members may be committed to the sandox by a subproject
> committer. If the initial source for a new package is from outside of
> apache, the new package must be brought into apache via the apache
> incubator.
not sure but wonder whether we might need to tightening this last
sentence so that it can't be read as implying that having only a portion
of the initial source from external sources is ok. opinions?
> 15-3 A majority vote among subproject commiters is required to
> "graduate" a package from the "sandbox" to become a proper package. Only
> proper packages may make releases. If a package remains in the sandbox
> for more than six months, a majority vote will be required to prevent
> its being archived from svn and removed from the subproject web site and
> any other public locations (e.g. nightly or continuous integration
> builds). Proper packages may not release code with dependencies on
> sandbox packages.
1. i wonder whether it'd be better to have bi-annual reviews to simplify
administration. in january, review all sandbox components which were
created before the previous july. could run them as a single vote.
2. i wonder whether we actually need to remove them from svn: just could
copy them into an archive directory.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components
Posted by Phil Steitz <ph...@steitz.com>.
Here is a stab at replacement text for 15, 17 and 18.
15-1 Any member of the community may propose a new package. To be
accepted, a package proposal must receive majority approval of the
subproject committers and at least one committer must volunteer to serve
as an initial package team member. Proposals should identify the
rationale for the package, its scope, its interaction with other
packages and products, the <insert-subproject-name> resources, if any,
to be created, the initial source from which the package is to be
created, and the sponsoring committers.
15-2 The subproject will maintain an svn repository, referred to as the
<i>sandbox</i>, as a workplace for new packages. Once approved, new
packages must all begin in the sandbox. Any apache committer may
contribute code directly to the sandbox and this code may form the
initial source for new packages. Code from existing apache projects
can, with the support of the contributing projects, also be imported
directly into the sandbox. Finally, patches contributed incrementally
by community members may be committed to the sandox by a subproject
committer. If the initial source for a new package is from outside of
apache, the new package must be brought into apache via the apache
incubator.
15-3 A majority vote among subproject commiters is required to
"graduate" a package from the "sandbox" to become a proper package. Only
proper packages may make releases. If a package remains in the sandbox
for more than six months, a majority vote will be required to prevent
its being archived from svn and removed from the subproject web site and
any other public locations (e.g. nightly or continuous integration
builds). Proper packages may not release code with dependencies on
sandbox packages.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sat, 2005-07-02 at 14:52 -0400, Martin Cooper wrote:
> On 6/23/05, robert burrell donkin <ro...@blueyonder.co.uk> 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Posted by Martin Cooper <mf...@gmail.com>.
On 6/23/05, robert burrell donkin <ro...@blueyonder.co.uk> 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.
> 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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org