Re: Dormant guidelines proposal?
On Fri, 2005-07-01 at 01:55 -0500, Curt Arnold wrote: There has been some discussion about modifying the Logging Services project bylaws (http://logging.apache.org/site/bylaws.html) to address some concerns particular to the project. I was researching the Jakarta guidelines and stumbled across http://jakarta.apache.org/ site/proposal.html. It is referenced at the bottom of http:// jakarta.apache.org/site/guidelines.html as a working proposal, but it does not appear from the SVN log to have any activity for over two years. i thought that it'd been removed during spring cleaning earlier this way. anyone remember any reasons why it was retained? Was there a resolution on the proposal? If so or if has been abandoned, then it might be good to pull it and the link from the site or at least update the status. Has the activity moved elsewhere or is it just sleeping? it's a bit of a long story. the only real records exist on the (private) archives of the jakarta pmc mailing list. IIRC this represents the earliest stage of the long road towards reform. the consensus was that the problem wasn't the guidelines but the basic bylaws. once these were fixed, arguing about the guidelines became moot... If either was going to be considered as a starting point for a rework of the LS bylaws, would you recommend the proposal or the accepted guidelines? i'm not sure whether it'd be a good idea to start from either. i'd start from the bylaws and from henri's wiki pages. it seems to me that the guidelines have really turned into a directory page for general information. a lot of the information linked to probably belongs at the foundation level (though would need editing). I haven't had a chance to attempt to compare and contrast the current and proposed guidelines, but the proposal's one page format left a better impression since you can see everything at one glance. the proposals are a good document in a cool format but didn't solve the real problems One of significant differences between our current bylaws and either of the proposal or existing guidelines is that the PMC is tasked with electing new committers. There is a desire to move that decision towards the sub-project, i recommend asking this question again on community. the model used by jakarta is believed (by many seniors figures from other projects) to be both unusual (within apache) and far from best practise. some feel that too much delegation to sub-projects may be to the detriment of the community spirit at project level. others that it creates problems with oversight. IMHO the model works ok for us here but i'd hesitate to recommend it to other projects. but I'm concerned that without any role for the PMC and no private medium for the vote, that there isn't a clean way for the PMC to address a potential disruptive or legally entangling committer candidate except to accept the sub-project vote and for the PMC to attempt to revoke his committer rights requiring a full consensus. AIUI no project is actually entitled to abdicate responsibility for oversight. IMHO the right way to proceed (if this happened here at jakarta) would be to -1 the result posted to the pmc list and so veto the action (lazy consensus). this should force a vote on the pmc list. one of the problems with holding votes for committers on public lists is that there is no way that the individual in question could be kept from the knowledge of their rejection. There would also be no private forum to discuss any sensitive issues since only the PMC has a private list. this is a problem that we have here at jakarta. current practise is that there is usually a certain amount of private chat (but it would be better if this happened on a private list). For the LS bylaws, I was considering suggesting a two-phase vote, lazy consensus at the sub-project and then lazy approval followed by lazy consensus at the PMC. Considering the damage a rogue committer could do, having the PMC with some means of intervening without invoking the nuclear option would seem to be warranted. the pmc is charged with oversight. whatever system is agreed must provide that. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][POLL] drop point 12
i count 4 +1's the consensus seems to be in favour of removal so that's what i'm going to do. i propose to leave retain the number by noting those that have been deleted (rather than removing them). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by RobertBurrellDonkin: http://wiki.apache.org/jakarta/DraftCharterForWebComponentCommons The comment on the change is: Deleted point 12 -- 1. External configuration files are discouraged, but if required, XML format files are preferred for configuration options. 1. Each package will be hosted on its own page on the subproject Web site, and will also be indexed in a master directory. 1. The subproject will also host a top-level 'general' mailing list in addition to any lists for specific packages. -1. 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. +1. '''DELETED''' ''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.'' 1. Volunteers become committers to this subproject in the same way they are entered to any Jakarta subproject. Being a committer in another Jakarta subproject is not a prerequisite. 1. Each committer has karma to all the packages, but committers are required to add their name to a package's status file before their first commit to that package. 1. New packages may be proposed to the Jakarta Commons mailing list. To be accepted, a package proposal must receive majority approval of the subproject committers. Proposals are to identify the rationale for the package, its scope, its interaction with other packages and products, the Commons resources, if any, to be created, the initial source from which the package is to be created, the coding conventions used for the package (if different from the Sun coding conventions), and the initial set of committers. - 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 Sat, 2005-07-02 at 14:33 -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: 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. i think we've established a consensus on this. any objections to amending the draft appropriately? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[POLL] drop 8
8. Packages are encouraged to either use JavaBeans as core objects, a JavaBean-style API, or to provide an optional JavaBean wrapper. doesn't seem very relevant. i think that it'd be simpler just to drop it. here's my +1 - robert --8--- [ ] +1 Get rid! [ ] -1 Keep it (please give a reason...) -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] drop 8
+1 to drop this Phil robert burrell donkin wrote: 8. Packages are encouraged to either use JavaBeans as core objects, a JavaBean-style API, or to provide an optional JavaBean wrapper. doesn't seem very relevant. i think that it'd be simpler just to drop it. here's my +1 - robert --8--- [ ] +1 Get rid! [ ] -1 Keep it (please give a reason...) -- - 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
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: [POLL] drop 8
+1 -- Martin Cooper On 7/3/05, Phil Steitz [EMAIL PROTECTED] wrote: +1 to drop this Phil robert burrell donkin wrote: 8. Packages are encouraged to either use JavaBeans as core objects, a JavaBean-style API, or to provide an optional JavaBean wrapper. doesn't seem very relevant. i think that it'd be simpler just to drop it. here's my +1 - robert --8--- [ ] +1 Get rid! [ ] -1 Keep it (please give a reason...) -- - 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] - 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: [POLL] drop 8
+1 -Rahul On 7/3/05, Martin Cooper [EMAIL PROTECTED] wrote: +1 -- Martin Cooper On 7/3/05, Phil Steitz [EMAIL PROTECTED] wrote: +1 to drop this Phil robert burrell donkin wrote: 8. Packages are encouraged to either use JavaBeans as core objects, a JavaBean-style API, or to provide an optional JavaBean wrapper. doesn't seem very relevant. i think that it'd be simpler just to drop it. here's my +1 - robert --8--- [ ] +1 Get rid! [ ] -1 Keep it (please give a reason...) -- - 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] - 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
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]
