Re: [Jakarta-commons Wiki] Update of JakartaCommonsEtiquette by SimonKitching
At 2005-05-14 00:51, Simon Kitching wrote: On Thu, 2005-05-12 at 09:44 +0200, Mattias J wrote: And if I am not currently a Jakarta commiter, but would like sandbox commit access for existing sandbox projects? If you're not an ASF committer, then I think the current policy is that no, you can't get commit access to the sandbox. However ... they can always nominate you as a commons committer (or any other relevant ASF project) which then gives you access to the sandbox too. So you cannot be a commons sandbox only committer? The main issue with having commit access is that you need to have signed the appropriate legal forms. As understand it, you must sign the CLA before anybody else commits your patches too. Anyway, a link to http://jakarta.apache.org/site/source.html or any of it's parents from the etiquette page might be appropriate. /Mattias Jiderhamn
Re: [Jakarta-commons Wiki] Update of JakartaCommonsEtiquette by SimonKitching
On 5/14/05, Mattias J [EMAIL PROTECTED] wrote: At 2005-05-14 00:51, Simon Kitching wrote: On Thu, 2005-05-12 at 09:44 +0200, Mattias J wrote: And if I am not currently a Jakarta commiter, but would like sandbox commit access for existing sandbox projects? If you're not an ASF committer, then I think the current policy is that no, you can't get commit access to the sandbox. However ... they can always nominate you as a commons committer (or any other relevant ASF project) which then gives you access to the sandbox too. So you cannot be a commons sandbox only committer? Correct. The intent of the sandbox is to provide an area in which existing ASF committers can explore the viability of extracting potentially common code from an existing ASF code base into a shareable component. (That intent has been stretched somewhat, but that is still the real purpose of the sandbox.) The main issue with having commit access is that you need to have signed the appropriate legal forms. As understand it, you must sign the CLA before anybody else commits your patches too. That depends on the scale of the patches. For most patches that are bug fixes or perhaps minor enhancements, a CLA is not generally necessary. (I say generally because it may depend on your employer's policies on IP ownership and contributing to open source projects.) For substantial contributions, a CLA may be necessary. -- Martin Cooper Anyway, a link to http://jakarta.apache.org/site/source.html or any of it's parents from the etiquette page might be appropriate. /Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of JakartaCommonsEtiquette by SimonKitching
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by SimonKitching: http://wiki.apache.org/jakarta-commons/JakartaCommonsEtiquette The comment on the change is: Added useful links section -- * Please give the proposal enough time to give everything the chance to VOTE. I leave promotion VOTEs several days - maybe up to a week. When VOTEs have stopped coming in then please the proposer should post a tt[VOTE][RESULT]/tt giving counts. Only the VOTEs of commons committers are binding so please make sure that these are tallied separately. The reason why a result email is good is that VOTE thread tend to peter out and so without a final email, it's hard to look back through the archives and find out what's happened. Another reason is that it's a good way to let everyone know what the result was. If there are any disagreements about the result, they can be resolved then. + + + + = Other Useful Links = + + * http://jakarta.apache.org/site/source.html + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta-commons Wiki] Update of JakartaCommonsEtiquette by SimonKitching
On Thu, 2005-05-12 at 09:44 +0200, Mattias J wrote: SimonKitching wrote: + Any Jakarta committer (not just commons committers) has the right ask for karma (commit access) and have it granted. The right place to ask is on the commons-dev mailing list. + Commit access to the sandbox is unfortunately '''not''' available to people who are not existing Jakarta committers, no matter how good their idea. Such projects are generally encouraged to start somewhere like sourceforge.net. Once a solid community has been established and existing projects are using the component, it may be possible to integrate the project direct into commons if the project developers feel that is appropriate, and the commons community feels the component is a good fit with commons goals. And if I am not currently a Jakarta commiter, but would like sandbox commit access for existing sandbox projects? As you may have seen, the page has been corrected to say that any ASF committer can get access to the sandbox (not just Jakarta committers). If you're not an ASF committer, then I think the current policy is that no, you can't get commit access to the sandbox. However if you have provided a good set of patches to the ASF members who created the sandbox project, they can always nominate you as a commons committer (or any other relevant ASF project) which then gives you access to the sandbox too. The main issue with having commit access is that you need to have signed the appropriate legal forms. And also access control isn't per-sandbox-project, but across the whole sandbox, so people need to know you a bit first before granting that. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of JakartaCommonsEtiquette by SimonKitching
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by SimonKitching: http://wiki.apache.org/jakarta-commons/JakartaCommonsEtiquette -- The sandbox is a space provided by Jakarta for the development of experimental code by existing committers. It is divided into components. - Any Jakarta committer has the right ask for karma and have it granted. The right place to ask is on the commons-dev mailing list. + Any Jakarta committer (not just commons committers) has the right ask for karma (commit access) and have it granted. The right place to ask is on the commons-dev mailing list. - Components cannot be released from the sandbox. + Components cannot be released from the sandbox. This means no binaries posted anywere on the apache site as 0.x releases, as this implies that Apache supports the released code. Users of sandbox code are expected to extract the latest source from the source code repository and build the code themselves. + + Commit access to the sandbox is unfortunately '''not''' available to people who are not existing Jakarta committers, no matter how good their idea. Such projects are generally encouraged to start somewhere like sourceforge.net. Once a solid community has been established and existing projects are using the component, it may be possible to integrate the project direct into commons if the project developers feel that is appropriate, and the commons community feels the component is a good fit with commons goals. = Sandbox Etiquette = @@ -48, +50 @@ There is one important point about the list on the STATUS file. It is used to work out whose VOTEs are binding. (Since there are a lot of commons committers, this is more useful than it might first seem.) If you're name isn't on the list, your vote won't count :) + For components that use '''Maven''' as their build tool (and that is most of them now), you should add your name to the developers list in the project.xml file rather than the STATUS file if you intend to work on a component. + = VOTEs = The commons-dev mailing list is a busy place. Very much a bazaar rather than a Cathedral. This means that VOTE threads have a habit of petering out. It a good idea to post a tt[VOTE][RESULT]/tt which counts the binding VOTEs and tells people the result. @@ -60, +64 @@ Promotion to the commons proper is not the only route out of the sandbox. The commons proper isn't always the best place for all components from the sandbox. There isn't any reason why a component couldn't move directly from the sandbox to become a project or a subproject. At least one component has moved from the sandbox to sourceforge and then finally back to the incubator. - Promotion is basically a beauty contest. If the component can win enough votes and few enough people vote against it, then the component is promoted. But there is one thing that is most definitly required: + Promotion is basically a beauty contest. If the component can win enough votes and few enough people vote against it, then the component is promoted. But there is one thing that is most definitely required: * Compliance with Apache Software Federation policies. This means a full license at the top of every file. It means auditing the dependencies. It means ensuring the copyright date is correct on the licenses. @@ -70, +74 @@ * A good PROPOSAL. A good PROPOSAL is clearly written and tightly scoped (ie. specific rather than general). Commons components are small, resuable components. The commons does not do frameworks and anything frameworkesque is likely to be viewed with scepticism. A PROPOSAL that duplicates an existing component will probably be viewed with suspicion. This is not because duplication is disallowed (overlapping components are specifically allowed by the charter) but because it indicates that the PROPOSAL fails to indicate the essential difference between the proposed component and the existing one. For example, a PROSPOSAL for a small, fast, compact xml-object mapper with minimal dependencies would be more likely to succeed than a PROPOSAL for 'a better version of commons-digester'. - * The health of the development community. Fellow committers need to be persuaded that users will be supported and the code pushed forward by the listed committers. This is a major issue since there's only a limited amount of energy amongst the commons committers and no one wants to have to support a component whose committers have gone AWAL. + * The health of the development community. Fellow committers need to be persuaded that users will be supported and the code pushed forward by the listed committers. This is a major issue since there's only a limited amount of energy amongst the commons committers and no
[Jakarta-commons Wiki] Update of JakartaCommonsEtiquette by SimonKitching
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by SimonKitching: http://wiki.apache.org/jakarta-commons/JakartaCommonsEtiquette -- = Sandbox Oversight = - Oversight for the sandbox is provided by the Commons team. Oversight means responsibility for ensuring that everything in the sandbox complies with Apache Software Foundation policies. Though (it is to be hoped that) committers should be able to be trusted, in the last resort the Commons team reserves the right to remove offending material from CVS. + Oversight for the sandbox is provided by the Commons team. Oversight means responsibility for ensuring that everything in the sandbox complies with Apache Software Foundation policies. Though (it is to be hoped that) committers should be able to be trusted, in the last resort the Commons team reserves the right to remove offending material from the source code repository. If questionable material is found, the right way to proceed is to first raise the matter on the commons-dev mailing list. The community will form a judgement about the material and the committers will be able to respond. It's a good idea to inform the committers directly (in case they are not on the list). It's also a good idea to copy the Jakarta PMC. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta-commons Wiki] Update of JakartaCommonsEtiquette by SimonKitching
SimonKitching wrote: + Any Jakarta committer (not just commons committers) has the right ask for karma (commit access) and have it granted. The right place to ask is on the commons-dev mailing list. + Commit access to the sandbox is unfortunately '''not''' available to people who are not existing Jakarta committers, no matter how good their idea. Such projects are generally encouraged to start somewhere like sourceforge.net. Once a solid community has been established and existing projects are using the component, it may be possible to integrate the project direct into commons if the project developers feel that is appropriate, and the commons community feels the component is a good fit with commons goals. And if I am not currently a Jakarta commiter, but would like sandbox commit access for existing sandbox projects? /Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
