Re: new components
+1
Re: new components
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 isandbox/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components
+1 On 7/5/05, robert burrell donkin [EMAIL PROTECTED] 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 isandbox/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components
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]
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: 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]
Re: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components
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 isandbox/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components
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 isandbox/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: [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: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: 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: [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: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
