Re: [doc] are board resolutions ok for http://incubator.apache.org/official/...?
On Tue, Aug 29, 2006 at 08:30:32AM -0700, Justin Erenkrantz wrote: I just don't see the cause for your angst here. -- justin And I just don't see any reason to keep things private. Private ~= bad, when it can be avoided. Basic way to keep a distributed volunteer organisation transparent. Etc etc. We're obviously not communicating well. I'll let Robert figure out what he wanted and argue a specific point. Sorry for the mess. LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] are board resolutions ok for http://incubator.apache.org/official/...?
On 8/30/06, Leo Simons [EMAIL PROTECTED] wrote: On Tue, Aug 29, 2006 at 08:30:32AM -0700, Justin Erenkrantz wrote: I just don't see the cause for your angst here. -- justin And I just don't see any reason to keep things private. Private ~= bad, when it can be avoided. Basic way to keep a distributed volunteer organisation transparent. Etc etc. We're obviously not communicating well. I'll let Robert figure out what he wanted and argue a specific point. Sorry for the mess. i suspect that the documents are not actually official minutes until they have been approved. to publicise private drafts would be misleading. i wanted to include some resolutions about mailing lists (naming and so on) from months and months ago so that should be fine. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
Jason van Zyl wrote: Hi, It looks like people objected to creating another mailing list for policy so I just used [policy] as Robert did in a previous message. Henri has setup Maven repositories for the incubator and there is a document which is an attempt to describe the current setup here: http://www.apache.org/dev/repository-faq.html I think that everyone agrees that a separate repository for incubating projects is a good idea as 1) you can clearly see what incubator artifacts have been created 2) we can perform analysis and create reports for incubator artifacts easily (using Archiva, the maven repository manager) 3) separating the administration duties of the incubator repository is a good idea I think. This might involve a different instance of Archiva and/or different people looking after the respective repositories I haven't looked at all the projects using Maven in the incubator but cxf, the one I'm most involved with, looks like its settling on versions like: 2.0-incubator-SNAPSHOT So the repository is clearly separated, and from a dependency element in a Maven POM you can clearly see it's an incubator version. There was discussion that incubator repository would not be sync'd to the central repository but I don't really see much point in this. A few folks with incubating projects have voiced concerns that they don't want to see their projects be taken out of circulation in the central repository because they are incubating. If each and every incubating project has a version for each artifact like that above then it will be fairly clear that it's from the incubator. Moreso then if you just had a repository definition pointing at the incubator repository. Also someone may make an repository request to place an incubator artifact in the central repository and at this point a policy mandated here would conflict with someone's right to redistribute artifacts created in the incubator. I don't really want to get into the business of policing repository requests. I think it is in the best interests of the incubating projects to have the incubator repository sync'd to Maven's central repository. The source of artifacts for incubating projects is clear from the version so I don't think there will be any confusion by consumers of these artifacts and as such I don't really see any downside to allowing the sync to Maven's central repository. Thoughts? Jason van Zyl [EMAIL PROTECTED] +1. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
Niclas Hedhman wrote: On Monday 28 August 2006 11:31, Jason van Zyl wrote: Could that report be made part of the release:prepare and the release manager had to explicitly approve it?? How are we supposed to enforce that? And what if they are not using Maven? Say using either the Maven Ant Tasks, or Ivy, or just an http get to get artifacts from a repository. We are probably misunderstanding each other... The question that came up was about transitive dependencies, which the user do not necessarily check for, and could end up being dependent on incubating projects against his/her will. Something that can't happen for snapshots (unless you bypass Maven's intended behaviours) You said, that one can check the full set of dependencies from a report generated by Maven2. I said, if that report could be output during the release:prepare phase, and that if the release:prepare phase would require the release manager to approve the use of that dependency tree, then we put the responsibility in the hands of the Maven2 user. You then start talking about 'enforcement'... And I am lost. Enforcing what? If the report can be generated, then either your statement above isn't valid, or the report is not capable of reporting the dependencies, in which case the original statement is not accurate. I suspect that you are trying to find problems with non-Maven systems, but that can always happen and not the issue at hand. BuildSystemAbc could pull down all kinds of stuff for the users, including snapshots, pirated software and virii. IMHO, Maven repositories exist mainly to support Maven and Maven-compatible(!) build systems. Your suggestions in the original mail is very good, and *I* don't have any opinion about whether a separate Incubating repository is needed or not. Both arguments for and against sound reasonable. I don't really think that this is going to help anything. The user is always in control. The responsibility has never left their hands. Lets step away from the incubator a sec and take GPL jars for instance - if there is a transitive dependency on GPL jars, the user is completely responsible for that. Why would it be any different for an incubator JAR? - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
If it comes to a VOTE, i'd vote -1 on automatic syncing of incubator artifacts to maven central repo. -- dims On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: Jason van Zyl wrote: Hi, It looks like people objected to creating another mailing list for policy so I just used [policy] as Robert did in a previous message. Henri has setup Maven repositories for the incubator and there is a document which is an attempt to describe the current setup here: http://www.apache.org/dev/repository-faq.html I think that everyone agrees that a separate repository for incubating projects is a good idea as 1) you can clearly see what incubator artifacts have been created 2) we can perform analysis and create reports for incubator artifacts easily (using Archiva, the maven repository manager) 3) separating the administration duties of the incubator repository is a good idea I think. This might involve a different instance of Archiva and/or different people looking after the respective repositories I haven't looked at all the projects using Maven in the incubator but cxf, the one I'm most involved with, looks like its settling on versions like: 2.0-incubator-SNAPSHOT So the repository is clearly separated, and from a dependency element in a Maven POM you can clearly see it's an incubator version. There was discussion that incubator repository would not be sync'd to the central repository but I don't really see much point in this. A few folks with incubating projects have voiced concerns that they don't want to see their projects be taken out of circulation in the central repository because they are incubating. If each and every incubating project has a version for each artifact like that above then it will be fairly clear that it's from the incubator. Moreso then if you just had a repository definition pointing at the incubator repository. Also someone may make an repository request to place an incubator artifact in the central repository and at this point a policy mandated here would conflict with someone's right to redistribute artifacts created in the incubator. I don't really want to get into the business of policing repository requests. I think it is in the best interests of the incubating projects to have the incubator repository sync'd to Maven's central repository. The source of artifacts for incubating projects is clear from the version so I don't think there will be any confusion by consumers of these artifacts and as such I don't really see any downside to allowing the sync to Maven's central repository. Thoughts? Jason van Zyl [EMAIL PROTECTED] +1. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
Why? Davanum Srinivas wrote: If it comes to a VOTE, i'd vote -1 on automatic syncing of incubator artifacts to maven central repo. -- dims On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: Jason van Zyl wrote: Hi, It looks like people objected to creating another mailing list for policy so I just used [policy] as Robert did in a previous message. Henri has setup Maven repositories for the incubator and there is a document which is an attempt to describe the current setup here: http://www.apache.org/dev/repository-faq.html I think that everyone agrees that a separate repository for incubating projects is a good idea as 1) you can clearly see what incubator artifacts have been created 2) we can perform analysis and create reports for incubator artifacts easily (using Archiva, the maven repository manager) 3) separating the administration duties of the incubator repository is a good idea I think. This might involve a different instance of Archiva and/or different people looking after the respective repositories I haven't looked at all the projects using Maven in the incubator but cxf, the one I'm most involved with, looks like its settling on versions like: 2.0-incubator-SNAPSHOT So the repository is clearly separated, and from a dependency element in a Maven POM you can clearly see it's an incubator version. There was discussion that incubator repository would not be sync'd to the central repository but I don't really see much point in this. A few folks with incubating projects have voiced concerns that they don't want to see their projects be taken out of circulation in the central repository because they are incubating. If each and every incubating project has a version for each artifact like that above then it will be fairly clear that it's from the incubator. Moreso then if you just had a repository definition pointing at the incubator repository. Also someone may make an repository request to place an incubator artifact in the central repository and at this point a policy mandated here would conflict with someone's right to redistribute artifacts created in the incubator. I don't really want to get into the business of policing repository requests. I think it is in the best interests of the incubating projects to have the incubator repository sync'd to Maven's central repository. The source of artifacts for incubating projects is clear from the version so I don't think there will be any confusion by consumers of these artifacts and as such I don't really see any downside to allowing the sync to Maven's central repository. Thoughts? Jason van Zyl [EMAIL PROTECTED] +1. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
I guess, you need to read more emails on this list :) For example see [1] thanks, dims [1] http://marc.theaimsgroup.com/?l=incubator-generalm=115440663222532w=2 On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: Why? Davanum Srinivas wrote: If it comes to a VOTE, i'd vote -1 on automatic syncing of incubator artifacts to maven central repo. -- dims On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: Jason van Zyl wrote: Hi, It looks like people objected to creating another mailing list for policy so I just used [policy] as Robert did in a previous message. Henri has setup Maven repositories for the incubator and there is a document which is an attempt to describe the current setup here: http://www.apache.org/dev/repository-faq.html I think that everyone agrees that a separate repository for incubating projects is a good idea as 1) you can clearly see what incubator artifacts have been created 2) we can perform analysis and create reports for incubator artifacts easily (using Archiva, the maven repository manager) 3) separating the administration duties of the incubator repository is a good idea I think. This might involve a different instance of Archiva and/or different people looking after the respective repositories I haven't looked at all the projects using Maven in the incubator but cxf, the one I'm most involved with, looks like its settling on versions like: 2.0-incubator-SNAPSHOT So the repository is clearly separated, and from a dependency element in a Maven POM you can clearly see it's an incubator version. There was discussion that incubator repository would not be sync'd to the central repository but I don't really see much point in this. A few folks with incubating projects have voiced concerns that they don't want to see their projects be taken out of circulation in the central repository because they are incubating. If each and every incubating project has a version for each artifact like that above then it will be fairly clear that it's from the incubator. Moreso then if you just had a repository definition pointing at the incubator repository. Also someone may make an repository request to place an incubator artifact in the central repository and at this point a policy mandated here would conflict with someone's right to redistribute artifacts created in the incubator. I don't really want to get into the business of policing repository requests. I think it is in the best interests of the incubating projects to have the incubator repository sync'd to Maven's central repository. The source of artifacts for incubating projects is clear from the version so I don't think there will be any confusion by consumers of these artifacts and as such I don't really see any downside to allowing the sync to Maven's central repository. Thoughts? Jason van Zyl [EMAIL PROTECTED] +1. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (INCUBATOR-46) [policy neutral] tightened prose
[policy neutral] tightened prose Key: INCUBATOR-46 URL: http://issues.apache.org/jira/browse/INCUBATOR-46 Project: Incubator Issue Type: Improvement Components: policy Reporter: Robert Burrell Donkin Assigned To: Robert Burrell Donkin This patch tightens the langauge and removes discursive paragraph. The discursive material is better suited for guides and will be moved there. I have no clear idea what (including code held in publically -available SVN)' means so I think that it can be removed without altering the sense of the policy. Index: site-author/incubation/Incubation_Policy.xml === --- site-author/incubation/Incubation_Policy.xml(revision 438191) +++ site-author/incubation/Incubation_Policy.xml(working copy) @@ -430,13 +430,10 @@ section id=Releases titleReleases /title -pAs podlings are not yet fully accepted as part of the Apache Software -Foundation, any software releases (including code held in publically -available SVN) made by Podlings will not be endorsed by the ASF. +pPodlings are not yet fully accepted as part of the Apache Software +Foundation. No release made by a Podling will be endorsed by the ASF. +Unendorsed releases may be made by Podlings subject to the following policy. /p -pHowever, as software releases are an important part of any software -project, they are permitted in certain circumstances, as follows. -/p pPodlings in Incubation SHALL NOT perform any releases of software without the explicit approval of the Incubator PMC. Such approval SHALL be given only after the Incubator PMC has followed the process Index: site-publish/incubation/Incubation_Policy.html === --- site-publish/incubation/Incubation_Policy.html (revision 438193) +++ site-publish/incubation/Incubation_Policy.html (working copy) @@ -534,13 +534,10 @@ /a /h3 div class=section-content -pAs podlings are not yet fully accepted as part of the Apache Software -Foundation, any software releases (including code held in publically -available SVN) made by Podlings will not be endorsed by the ASF. +pPodlings are not yet fully accepted as part of the Apache Software +Foundation. No release made by a Podling will be endorsed by the ASF. +Unendorsed releases may be made by Podlings subject to the following policy. /p -pHowever, as software releases are an important part of any software -project, they are permitted in certain circumstances, as follows. -/p pPodlings in Incubation SHALL NOT perform any releases of software without the explicit approval of the Incubator PMC. Such approval SHALL be given only after the Incubator PMC has followed the process -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (INCUBATOR-47) [policy neutral] move reading material into release guide
[policy neutral] move reading material into release guide - Key: INCUBATOR-47 URL: http://issues.apache.org/jira/browse/INCUBATOR-47 Project: Incubator Issue Type: Improvement Reporter: Robert Burrell Donkin Assigned To: Robert Burrell Donkin References to reading material is more suitable for the release management guide than the policy document. Index: site-author/guides/releasemanagement.xml === --- site-author/guides/releasemanagement.xml(revision 438542) +++ site-author/guides/releasemanagement.xml(working copy) @@ -109,6 +109,12 @@ lia href='http://jakarta.apache.org/commons'Jakarta Commons/a/li lia href='http://struts.apache.org/releases.html'Struts/a/li /ul +pPlease also check the a href=http://www.apache.org/dev/release.html;Apache Release guidelines/a +in particular the a href=http://www.apache.org/dev/release.html#license;license requirements/a. +Also you might find it useful to read some of the +a href=http://wiki.apache.org/general/ReleaseGuides;release guides/a from other projects. +/p + /section section id='check-list'titleCheck List/title p Index: site-author/incubation/Incubation_Policy.xml === --- site-author/incubation/Incubation_Policy.xml(revision 438191) +++ site-author/incubation/Incubation_Policy.xml(working copy) @@ -478,10 +478,6 @@ documentation or README file. /li /ul - -pPlease also check the a href=http://www.apache.org/dev/release.html;Apache Release guidelines/a in particular the a href=http://www.apache.org/dev/release.html#license;license requirements/a. Also you might find it useful to read some of the a href=http://wiki.apache.org/general/ReleaseGuides;release guides/a from other projects. -/p - /section section id=Use+of+Apache+Resources titleUse of Apache Resources Index: site-publish/guides/releasemanagement.html === --- site-publish/guides/releasemanagement.html (revision 438542) +++ site-publish/guides/releasemanagement.html (working copy) @@ -187,6 +187,11 @@ lia href=http://jakarta.apache.org/commons;Jakarta Commons/a/li lia href=http://struts.apache.org/releases.html;Struts/a/li /ul +pPlease also check the a href=http://www.apache.org/dev/release.html;Apache Release guidelines/a +in particular the a href=http://www.apache.org/dev/release.html#license;license requirements/a. +Also you might find it useful to read some of the +a href=http://wiki.apache.org/general/ReleaseGuides;release guides/a from other projects. +/p /div h2img src=/images/redarrow.gif / a name=check-listCheck List/a Index: site-publish/incubation/Incubation_Policy.html === --- site-publish/incubation/Incubation_Policy.html (revision 438193) +++ site-publish/incubation/Incubation_Policy.html (working copy) @@ -580,8 +580,6 @@ documentation or README file. /li /ul -pPlease also check the a href=http://www.apache.org/dev/release.html;Apache Release guidelines/a in particular the a href=http://www.apache.org/dev/release.html#license;license requirements/a. Also you might find it useful to read some of the a href=http://wiki.apache.org/general/ReleaseGuides;release guides/a from other projects. -/p /div h3 a name=Use+of+Apache+ResourcesUse of Apache Resources -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][policy] policy neutral clean up for policy document, phase three
another batch of (what i hope are) policy neutral changes to the policy document. i'll tally this vote no earlier than 2000 GMT wednesday 6th september 2006. i'm +1 to all - robert --8--- https://issues.apache.org/jira/browse/INCUBATOR-40 adds license header [ ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-41 cut unnessary preamble [ ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-42 tighter, more consistent wording [ ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-43 cut unnecessary words [ ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-44 cut discursive material better handled in the guides [ ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-45 improvement to wording in ongoing activities and add link to referenced section [ ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-46 tightened prose [ ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-47 move reading material into release guide [ ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
Justin Erenkrantz wrote: On 8/30/06, Davanum Srinivas [EMAIL PROTECTED] wrote: If it comes to a VOTE, i'd vote -1 on automatic syncing of incubator artifacts to maven central repo. I would -1 it as well. The idea behind a separate repository was to make it very explicit to the user that they are fetching stuff from the Incubator. This strikes me as an end-run around that policy... -- justin Well it can be run around right now too. I as a user of an incubating project can request that a jar be uploaded to ibiblio. The incubator and ibiblio policies are distinct. Unless the incubator can enforce policy on the Ibiblio/Maven project for them to police the artifacts, they can currently be redistributed on Ibiblio, it is just an extra pain for me as a user. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (INCUBATOR-47) [policy neutral] move reading material into release guide
[ http://issues.apache.org/jira/browse/INCUBATOR-47?page=all ] Robert Burrell Donkin updated INCUBATOR-47: --- Component/s: policy [policy neutral] move reading material into release guide - Key: INCUBATOR-47 URL: http://issues.apache.org/jira/browse/INCUBATOR-47 Project: Incubator Issue Type: Improvement Components: policy Reporter: Robert Burrell Donkin Assigned To: Robert Burrell Donkin References to reading material is more suitable for the release management guide than the policy document. Index: site-author/guides/releasemanagement.xml === --- site-author/guides/releasemanagement.xml(revision 438542) +++ site-author/guides/releasemanagement.xml(working copy) @@ -109,6 +109,12 @@ lia href='http://jakarta.apache.org/commons'Jakarta Commons/a/li lia href='http://struts.apache.org/releases.html'Struts/a/li /ul +pPlease also check the a href=http://www.apache.org/dev/release.html;Apache Release guidelines/a +in particular the a href=http://www.apache.org/dev/release.html#license;license requirements/a. +Also you might find it useful to read some of the +a href=http://wiki.apache.org/general/ReleaseGuides;release guides/a from other projects. +/p + /section section id='check-list'titleCheck List/title p Index: site-author/incubation/Incubation_Policy.xml === --- site-author/incubation/Incubation_Policy.xml(revision 438191) +++ site-author/incubation/Incubation_Policy.xml(working copy) @@ -478,10 +478,6 @@ documentation or README file. /li /ul - -pPlease also check the a href=http://www.apache.org/dev/release.html;Apache Release guidelines/a in particular the a href=http://www.apache.org/dev/release.html#license;license requirements/a. Also you might find it useful to read some of the a href=http://wiki.apache.org/general/ReleaseGuides;release guides/a from other projects. -/p - /section section id=Use+of+Apache+Resources titleUse of Apache Resources Index: site-publish/guides/releasemanagement.html === --- site-publish/guides/releasemanagement.html (revision 438542) +++ site-publish/guides/releasemanagement.html (working copy) @@ -187,6 +187,11 @@ lia href=http://jakarta.apache.org/commons;Jakarta Commons/a/li lia href=http://struts.apache.org/releases.html;Struts/a/li /ul +pPlease also check the a href=http://www.apache.org/dev/release.html;Apache Release guidelines/a +in particular the a href=http://www.apache.org/dev/release.html#license;license requirements/a. +Also you might find it useful to read some of the +a href=http://wiki.apache.org/general/ReleaseGuides;release guides/a from other projects. +/p /div h2img src=/images/redarrow.gif / a name=check-listCheck List/a Index: site-publish/incubation/Incubation_Policy.html === --- site-publish/incubation/Incubation_Policy.html (revision 438193) +++ site-publish/incubation/Incubation_Policy.html (working copy) @@ -580,8 +580,6 @@ documentation or README file. /li /ul -pPlease also check the a href=http://www.apache.org/dev/release.html;Apache Release guidelines/a in particular the a href=http://www.apache.org/dev/release.html#license;license requirements/a. Also you might find it useful to read some of the a href=http://wiki.apache.org/general/ReleaseGuides;release guides/a from other projects. -/p /div h3 a name=Use+of+Apache+ResourcesUse of Apache Resources -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: Well it can be run around right now too. I as a user of an incubating project can request that a jar be uploaded to ibiblio. The incubator and ibiblio policies are distinct. Unless the incubator can enforce policy on the Ibiblio/Maven project for them to police the artifacts, they can currently be redistributed on Ibiblio, it is just an extra pain for me as a user. As I understand it, the ibiblio repository is under the de facto control of the Maven PMC. So, if the policy was that only project owners can upload the JARs, that would be respected. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
Yes, and I feel that Jason is addressing the issues brought up previously. As Jason stated, and I reiterated in my message to Justin, the incubator policy doesn't really affect the ibiblio distribution policy, so I see those as in conflict right now. So I want to know on what grounds the incubator can prevent me from requesting that some incubating jars from being uploaded to ibiblio. - Dan Davanum Srinivas wrote: I guess, you need to read more emails on this list :) For example see [1] thanks, dims [1] http://marc.theaimsgroup.com/?l=incubator-generalm=115440663222532w=2 On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: Why? Davanum Srinivas wrote: If it comes to a VOTE, i'd vote -1 on automatic syncing of incubator artifacts to maven central repo. -- dims On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: Jason van Zyl wrote: Hi, It looks like people objected to creating another mailing list for policy so I just used [policy] as Robert did in a previous message. Henri has setup Maven repositories for the incubator and there is a document which is an attempt to describe the current setup here: http://www.apache.org/dev/repository-faq.html I think that everyone agrees that a separate repository for incubating projects is a good idea as 1) you can clearly see what incubator artifacts have been created 2) we can perform analysis and create reports for incubator artifacts easily (using Archiva, the maven repository manager) 3) separating the administration duties of the incubator repository is a good idea I think. This might involve a different instance of Archiva and/or different people looking after the respective repositories I haven't looked at all the projects using Maven in the incubator but cxf, the one I'm most involved with, looks like its settling on versions like: 2.0-incubator-SNAPSHOT So the repository is clearly separated, and from a dependency element in a Maven POM you can clearly see it's an incubator version. There was discussion that incubator repository would not be sync'd to the central repository but I don't really see much point in this. A few folks with incubating projects have voiced concerns that they don't want to see their projects be taken out of circulation in the central repository because they are incubating. If each and every incubating project has a version for each artifact like that above then it will be fairly clear that it's from the incubator. Moreso then if you just had a repository definition pointing at the incubator repository. Also someone may make an repository request to place an incubator artifact in the central repository and at this point a policy mandated here would conflict with someone's right to redistribute artifacts created in the incubator. I don't really want to get into the business of policing repository requests. I think it is in the best interests of the incubating projects to have the incubator repository sync'd to Maven's central repository. The source of artifacts for incubating projects is clear from the version so I don't think there will be any confusion by consumers of these artifacts and as such I don't really see any downside to allowing the sync to Maven's central repository. Thoughts? Jason van Zyl [EMAIL PROTECTED] +1. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
Justin Erenkrantz wrote: On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: Well it can be run around right now too. I as a user of an incubating project can request that a jar be uploaded to ibiblio. The incubator and ibiblio policies are distinct. Unless the incubator can enforce policy on the Ibiblio/Maven project for them to police the artifacts, they can currently be redistributed on Ibiblio, it is just an extra pain for me as a user. As I understand it, the ibiblio repository is under the de facto control of the Maven PMC. So, if the policy was that only project owners can upload the JARs, that would be respected. -- justin I don't believe thats the current policy. Some projects don't care about maven, so users need to take things into their own hands. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: policy, so I see those as in conflict right now. So I want to know on what grounds the incubator can prevent me from requesting that some incubating jars from being uploaded to ibiblio. Common decency? If we (as the project owners) ask those artifacts not to be posted, then they shouldn't be posted as a matter of courtesy. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][policy] policy neutral clean up for policy document, phase three
Hi, --8--- https://issues.apache.org/jira/browse/INCUBATOR-40 adds license header [ X ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-41 cut unnessary preamble [ ] +1 Approve [ ] +0 [ X ] -0 I don't think the preamble hurts, and it provides readers with the useful notice that the document they're reading may be incomplete (as it's guaranteed to become over time). [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-42 tighter, more consistent wording [ X ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-43 cut unnecessary words [ X ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-44 cut discursive material better handled in the guides [ ] +1 Approve [ ] +0 [ X ] -0 Like Craig Russel's comment on the JIRA issue itself, I find this material useful. If it's better handled somewhere, fine, but let's provide a link to that better location here. [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-45 improvement to wording in ongoing activities and add link to referenced section [ X ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-46 tightened prose [ X ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-47 move reading material into release guide [ X ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject - Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][policy] policy neutral clean up for policy document, phase three
+1 to all items. On 8/30/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, --8--- https://issues.apache.org/jira/browse/INCUBATOR-40 adds license header [ X ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-41 cut unnessary preamble [ ] +1 Approve [ ] +0 [ X ] -0 I don't think the preamble hurts, and it provides readers with the useful notice that the document they're reading may be incomplete (as it's guaranteed to become over time). [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-42 tighter, more consistent wording [ X ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-43 cut unnecessary words [ X ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-44 cut discursive material better handled in the guides [ ] +1 Approve [ ] +0 [ X ] -0 Like Craig Russel's comment on the JIRA issue itself, I find this material useful. If it's better handled somewhere, fine, but let's provide a link to that better location here. [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-45 improvement to wording in ongoing activities and add link to referenced section [ X ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-46 tightened prose [ X ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject https://issues.apache.org/jira/browse/INCUBATOR-47 move reading material into release guide [ X ] +1 Approve [ ] +0 [ ] -0 [ ] -1 Reject - Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [VOTE][policy] policy neutral clean up for policy document, phase three
On 8/30/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, (grouping together a couple of related issues) https://issues.apache.org/jira/browse/INCUBATOR-41 cut unnessary preamble [ ] +1 Approve [ ] +0 [ X ] -0 I don't think the preamble hurts, and it provides readers with the useful notice that the document they're reading may be incomplete (as it's guaranteed to become over time). snip https://issues.apache.org/jira/browse/INCUBATOR-44 cut discursive material better handled in the guides [ ] +1 Approve [ ] +0 [ X ] -0 Like Craig Russel's comment on the JIRA issue itself, I find this material useful. If it's better handled somewhere, fine, but let's provide a link to that better location here. the policy document is RTC. this means it's hard to improve or keep information up to date. the discursive material also makes it hard to see what the policies actually are. discursive material also is much more likely to become outdated than policy. i think that it would be much better to move the discursive material to CTR documents (and in particular into the new longer more discursive guides) leaving pretty much just minimal statements of policy in the document. (hopefully anyone disagrees with this approach will jump in) but it's probably that i'll overstep the mark in some cases. i'll have a think and add some comments to the JIRAs. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [VOTE][policy] policy neutral clean up for policy document, phase three
Hi, On 8/30/06, robert burrell donkin [EMAIL PROTECTED] wrote: snip / i think that it would be much better to move the discursive material to CTR documents (and in particular into the new longer more discursive guides) leaving pretty much just minimal statements of policy in the document. (hopefully anyone disagrees with this approach will jump in) but it's probably that i'll overstep the mark in some cases. i'll have a think and add some comments to the JIRAs. This is something like what I was hoping you'd say. It's fine by me. Because you're shepherding this effort and seem to have a clear overall vision, I only wanted to voice my comments and maybe -0 a couple of them, not -1. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIni Proposal
Hi, Is anyone opposed to the proposed Jini project being called Apache Jini after the latest comments from the Jini community? They are essentially saying that it would make most sense for the project to maintain it's own specifications, and thus be the Jini implementation even though there is nothing stopping external projects from implementing some of the core components. I tend to agree with them that the name issue was at least partly based on a misunderstanding of the nature of the Jini technology and standards. I also acknowledge and support the Jini community's strong desire to keep the name. Unless anyone objects to the name, I think the way forward is to revise the proposal to meet Jim's points 1 and 2 before proceeding to vote on accepting the project. If Apache Jini is still considered inappropriate, then the next step for us and the Jini community would be to come up with an alternative name for the project. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [VOTE][policy] policy neutral clean up for policy document, phase three
On 8/30/06, Yoav Shapira [EMAIL PROTECTED] wrote: https://issues.apache.org/jira/browse/INCUBATOR-44 cut discursive material better handled in the guides [ ] +1 Approve [ ] +0 [ X ] -0 Like Craig Russel's comment on the JIRA issue itself, I find this material useful. If it's better handled somewhere, fine, but let's provide a link to that better location here. i'm going to withdraw this patch for now and come back with an alternative proposal in a later round. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (INCUBATOR-44) [policy neutral] cut discursive material better handled in the guides
[ http://issues.apache.org/jira/browse/INCUBATOR-44?page=comments#action_12431699 ] Robert Burrell Donkin commented on INCUBATOR-44: One of the issues I've noticed in incubation is that the incubating project often does not know who can help in what area. good point need to address this comprehensively somewhere in the documentation: possibly the FAQ or in a separate document. The trouble with the proposed patch is that it removes any clue as to who might be the usual party to request help. good point Maybe a better resolution would be to identify the responsible party for each of the tasks noted: i'd assumed that a Mentor would always do these tasks (see https://issues.apache.org/jira/browse/INCUBATOR-42). Setting up the svn repo: The general requesting resources page says, New projects will need to ask for their SVN-space to be created. Send to [EMAIL PROTECTED] and Cc your PMC. Add an issue to Jira in the Subversion category. What it doesn't say is who usually does the request. Creation of mailing lists: The general requesting resources page says, Gather the required information about the new lists. This includes the precise name and domain, the email addresses of the people who will be moderators (ideally three+ and well spread). Send to [EMAIL PROTECTED] and Cc your PMC. Add an issue to Jira in the Mailing Lists category. Who would normally be expected to submit the request? good question :-) it's been quite laissez-faire in the past but that's probably not a good answer going forward probably the answer should be something like: anyone on the PMC can but typically the PMC chair will probably would be good to add that to the document There is no detail on how to add an issue to which jira. Maybe a direct reference to the correct jira would help here. +1 submit a patch :-) for the www.apache.org site, use INFRA with component website https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidepid=10410sorter/order=DESCsorter/field=priorityresolution=-1component=11708 - robert [policy neutral] cut discursive material better handled in the guides - Key: INCUBATOR-44 URL: http://issues.apache.org/jira/browse/INCUBATOR-44 Project: Incubator Issue Type: Improvement Components: policy Reporter: Robert Burrell Donkin Assigned To: Robert Burrell Donkin Cuts non-policy discursive material that is better located in the guides. This change is intended to be policy neutral. Index: site-author/incubation/Incubation_Policy.xml === --- site-author/incubation/Incubation_Policy.xml(revision 437587) +++ site-author/incubation/Incubation_Policy.xml(working copy) @@ -285,21 +285,9 @@ liIncubator PMC mandating a helper Mentor/li /ul p - Your project's mentors are able to undertake many of the setup - tasks. See notes about how to - a href=http://www.apache.org/dev/reporting-issues.html;request project resources/a - such as new committer accounts and new mailing lists. - (Note that a committer account will not be created - a href=http://www.apache.org/dev/pmc.html#newcommitter;until the - Contributor License Agreement (CLA) has been recorded./a) -/p -p - Your project committers/PPMC members need to become familiar with - the a href=http://www.apache.org/dev/;ASF Infrastructure information/a - and in particular the - a href=http://www.apache.org/dev/#pmc;PMC/a notes. - Also see the a href=../guides/pmc.htmlIncubator PMC Guide/a. - /p + See a href=http://www.apache.org/dev/reporting-issues.html;how to/a + request project resources. + /p /section section id=Ongoing+Activities titleOngoing Activities/title Index: site-publish/incubation/Incubation_Policy.html === --- site-publish/incubation/Incubation_Policy.html (revision 437587) +++ site-publish/incubation/Incubation_Policy.html (working copy) @@ -376,21 +376,9 @@ liIncubator PMC mandating a helper Mentor/li /ul p - Your project's mentors are able to undertake many of the setup - tasks. See notes about how to - a href=http://www.apache.org/dev/reporting-issues.html;request project resources/a - such as new committer accounts and new mailing lists. - (Note that a committer account will not be created - a href=http://www.apache.org/dev/pmc.html#newcommitter;until the -
[jira] Resolved: (INCUBATOR-44) [policy neutral] cut discursive material better handled in the guides
[ http://issues.apache.org/jira/browse/INCUBATOR-44?page=all ] Robert Burrell Donkin resolved INCUBATOR-44. Resolution: Won't Fix I think that it would be best to withdrawl this patch. On reflection, IMHO it would probably be better to remove all the content without replacement and link to improved information from the tasks themselves. I'll create a new patch for a later round. [policy neutral] cut discursive material better handled in the guides - Key: INCUBATOR-44 URL: http://issues.apache.org/jira/browse/INCUBATOR-44 Project: Incubator Issue Type: Improvement Components: policy Reporter: Robert Burrell Donkin Assigned To: Robert Burrell Donkin Cuts non-policy discursive material that is better located in the guides. This change is intended to be policy neutral. Index: site-author/incubation/Incubation_Policy.xml === --- site-author/incubation/Incubation_Policy.xml(revision 437587) +++ site-author/incubation/Incubation_Policy.xml(working copy) @@ -285,21 +285,9 @@ liIncubator PMC mandating a helper Mentor/li /ul p - Your project's mentors are able to undertake many of the setup - tasks. See notes about how to - a href=http://www.apache.org/dev/reporting-issues.html;request project resources/a - such as new committer accounts and new mailing lists. - (Note that a committer account will not be created - a href=http://www.apache.org/dev/pmc.html#newcommitter;until the - Contributor License Agreement (CLA) has been recorded./a) -/p -p - Your project committers/PPMC members need to become familiar with - the a href=http://www.apache.org/dev/;ASF Infrastructure information/a - and in particular the - a href=http://www.apache.org/dev/#pmc;PMC/a notes. - Also see the a href=../guides/pmc.htmlIncubator PMC Guide/a. - /p + See a href=http://www.apache.org/dev/reporting-issues.html;how to/a + request project resources. + /p /section section id=Ongoing+Activities titleOngoing Activities/title Index: site-publish/incubation/Incubation_Policy.html === --- site-publish/incubation/Incubation_Policy.html (revision 437587) +++ site-publish/incubation/Incubation_Policy.html (working copy) @@ -376,21 +376,9 @@ liIncubator PMC mandating a helper Mentor/li /ul p - Your project's mentors are able to undertake many of the setup - tasks. See notes about how to - a href=http://www.apache.org/dev/reporting-issues.html;request project resources/a - such as new committer accounts and new mailing lists. - (Note that a committer account will not be created - a href=http://www.apache.org/dev/pmc.html#newcommitter;until the - Contributor License Agreement (CLA) has been recorded./a) -/p -p - Your project committers/PPMC members need to become familiar with - the a href=http://www.apache.org/dev/;ASF Infrastructure information/a - and in particular the - a href=http://www.apache.org/dev/#pmc;PMC/a notes. - Also see the a href=../guides/pmc.htmlIncubator PMC Guide/a. - /p + See a href=http://www.apache.org/dev/reporting-issues.html;how to/a + request project resources. + /p /div h3 a name=Ongoing+ActivitiesOngoing Activities/a -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote: On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: policy, so I see those as in conflict right now. So I want to know on what grounds the incubator can prevent me from requesting that some incubating jars from being uploaded to ibiblio. Common decency? If we (as the project owners) ask those artifacts not to be posted, then they shouldn't be posted as a matter of courtesy. It just means that we have to start watching for requests coming from users to put artifacts in the repository. Effectively you are asking us to deny the terms of redistribution stated in our license are you not? We could watch for requests going into Ibiblio, but we can't prevent someone else from putting in a repository that they might use. What is going to happen is that people are going to want to use these artifacts and they will want to rsync Ibiblio, which many people do, and then attempt to rsync the incubator repository. We are just going to try and circumvent a path that we cannot fully block off. I don't see what is not clear with *every* incubator artifact being marked with a version that has incubator in it. Plus the reports that can be generated give a clear view to users what they are consuming. I read this: http://marc.theaimsgroup.com/?l=incubator-generalm=115440663222532w=2 and to be frank (4) is somewhat paradoxical to me. You want an incubator project to thrive, and grow while we are tacitly, yet actively, discouraging their use? I think we should let people use their common sense to protect themselves. What is being envisioned here as the worst case scenario of using an incubator artifact for a failed incubator project? The mail says protect the user, but from what? I'm not going to discourage the use of a project I'm mentoring and fully support. I'm going to get everyone on the planet I can to use it as fast and as widely as possible. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator POM as parent for podlings
Very nice. Regards, Alan Jeremy Boynes wrote: The Maven project maintains a POM that can be used as a parent by other ASF projects http://svn.apache.org/repos/asf/maven/pom/trunk/asf/pom.xml I think it would help if we had a similar thing for the incubator that podlings can use - for example, defining the distribution repo to be the incubator one. I took a swag at modifying the one above for the incubator - see below. -- Jeremy ?xml version=1.0 encoding=UTF-8? !-- * Licensed to the Apache Software Foundation (ASF) under one * or more contributor license agreements. See the NOTICE file * distributed with this work for additional information * regarding copyright ownership. The ASF licenses this file * to you under the Apache License, Version 2.0 (the * License); you may not use this file except in compliance * with the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, * software distributed under the License is distributed on an * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY * KIND, either express or implied. See the License for the * specific language governing permissions and limitations * under the License. -- !-- Shared parent for Incubator projects and podlings. Version: $Rev$ $Date$ -- project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdorg.apache.incubator/groupId artifactIdparent/artifactId version1-SNAPSHOT/version packagingpom/packaging nameThe Apache Incubator/name description The Incubator project is the entry path into The Apache Software Foundation (ASF) for projects and codebases wishing to become part of the Foundation's efforts. All code donations from external organisations and existing external projects wishing to join Apache enter through the Incubator. /description licenses license nameThe Apache Software License, Version 2.0/name urlhttp://www.apache.org/licenses/LICENSE-2.0.txt/url distributionrepo/distribution /license /licenses organization nameApache Software Foundation/name urlhttp://www.apache.org//url /organization urlhttp://incubator.apache.org//url repositories repository idapache.snapshots/id nameApache Snapshot Repository/name urlhttp://people.apache.org/repo/m2-snapshot-repository/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots /repository repository idapache.incubator/id nameApache Incubator Repository/name urlhttp://people.apache.org/repo/m2-incubating-repository//url releases enabledtrue/enabled /releases snapshots enabledfalse/enabled /snapshots /repository /repositories distributionManagement !-- Site omitted - each podling must provide their own -- repository idapache.incubator/id nameApache Incubator Repository/name urlscp://people.apache.org/www/people.apache.org/repo/m2-incubating-repository/url /repository snapshotRepository idapache.snapshots/id nameApache Snapshot Repository/name urlscp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository/url /snapshotRepository /distributionManagement mailingLists mailingList nameApache Incubator Genera; List/name subscribe[EMAIL PROTECTED]/subscribe unsubscribe[EMAIL PROTECTED]/unsubscribe postgeneral@incubator.apache.org/post archivehttp://mail-archives.apache.org/mod_mbox/incubator-general//archive /mailingList /mailingLists /project - 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: [policy] incubating projects and maven repositories v1.0
Jason, Is it rocket science to add a new repo location in pom.xml? *Any* maven newbie learns *very* quickly how to add a new repo. Are you stating that *IF* the artifacts are not in the central repo they won't find it and won't know how to use it? The least anyone will need to know is the artifact id and version id and they find this when they browse a project's pages, are you stating that a user will never look at anyone's web site or download area and will *ONLY* look at ibiblio repo and decide to use a project? If they do indeed look, isn't it trivial to add instructions on adding info on how to add the incubation repo? Where's the problem? -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote: On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: policy, so I see those as in conflict right now. So I want to know on what grounds the incubator can prevent me from requesting that some incubating jars from being uploaded to ibiblio. Common decency? If we (as the project owners) ask those artifacts not to be posted, then they shouldn't be posted as a matter of courtesy. It just means that we have to start watching for requests coming from users to put artifacts in the repository. Effectively you are asking us to deny the terms of redistribution stated in our license are you not? We could watch for requests going into Ibiblio, but we can't prevent someone else from putting in a repository that they might use. What is going to happen is that people are going to want to use these artifacts and they will want to rsync Ibiblio, which many people do, and then attempt to rsync the incubator repository. We are just going to try and circumvent a path that we cannot fully block off. I don't see what is not clear with *every* incubator artifact being marked with a version that has incubator in it. Plus the reports that can be generated give a clear view to users what they are consuming. I read this: http://marc.theaimsgroup.com/?l=incubator-generalm=115440663222532w=2 and to be frank (4) is somewhat paradoxical to me. You want an incubator project to thrive, and grow while we are tacitly, yet actively, discouraging their use? I think we should let people use their common sense to protect themselves. What is being envisioned here as the worst case scenario of using an incubator artifact for a failed incubator project? The mail says protect the user, but from what? I'm not going to discourage the use of a project I'm mentoring and fully support. I'm going to get everyone on the planet I can to use it as fast and as widely as possible. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
On 30 Aug 06, at 7:53 PM 30 Aug 06, Davanum Srinivas wrote: Jason, Is it rocket science to add a new repo location in pom.xml? *Any* maven newbie learns *very* quickly how to add a new repo. Are you stating that *IF* the artifacts are not in the central repo they won't find it and won't know how to use it? As a force of habit most Maven users, particularly those coming from Maven 1.x, assume all open source artifacts are in the central repository. And in most cases for Maven 2.x all artifact required are placed in the central repository. It would be an unnecessary inconvenience. If the goal is to raise awareness that it is from the incubator then it can be done with the version. It could even be 1.0-apache-incubator-foo (1) As I think that would be preferable to users and that is abundantly clear I think. The least anyone will need to know is the artifact id and version id and they find this when they browse a project's pages, are you stating that a user will never look at anyone's web site or download area and will *ONLY* look at ibiblio repo and decide to use a project? The whole point of Maven is to make this easy for users and not have to look at a project's site. Maven users expect what they need to be in the central repository as shown by the many threads when users go to use Sun JARs and we don't have them in the central repository. If they do indeed look, isn't it trivial to add instructions on adding info on how to add the incubation repo? Where's the problem? A lot of times people actually go to the central repository to find the artifact's groupId and artifactId. They don't go to project websites, they go to the authority which is the central repository. If the goal here is user awareness then I think using an version like (1) supports this end to a great extent while being more convenient for the average Maven user. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote: On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: policy, so I see those as in conflict right now. So I want to know on what grounds the incubator can prevent me from requesting that some incubating jars from being uploaded to ibiblio. Common decency? If we (as the project owners) ask those artifacts not to be posted, then they shouldn't be posted as a matter of courtesy. It just means that we have to start watching for requests coming from users to put artifacts in the repository. Effectively you are asking us to deny the terms of redistribution stated in our license are you not? We could watch for requests going into Ibiblio, but we can't prevent someone else from putting in a repository that they might use. What is going to happen is that people are going to want to use these artifacts and they will want to rsync Ibiblio, which many people do, and then attempt to rsync the incubator repository. We are just going to try and circumvent a path that we cannot fully block off. I don't see what is not clear with *every* incubator artifact being marked with a version that has incubator in it. Plus the reports that can be generated give a clear view to users what they are consuming. I read this: http://marc.theaimsgroup.com/?l=incubator- generalm=115440663222532w=2 and to be frank (4) is somewhat paradoxical to me. You want an incubator project to thrive, and grow while we are tacitly, yet actively, discouraging their use? I think we should let people use their common sense to protect themselves. What is being envisioned here as the worst case scenario of using an incubator artifact for a failed incubator project? The mail says protect the user, but from what? I'm not going to discourage the use of a project I'm mentoring and fully support. I'm going to get everyone on the planet I can to use it as fast and as widely as possible. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
Please see this email from Noel: http://marc.theaimsgroup.com/?l=incubator-generalm=115440482328786w=2 -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 7:53 PM 30 Aug 06, Davanum Srinivas wrote: Jason, Is it rocket science to add a new repo location in pom.xml? *Any* maven newbie learns *very* quickly how to add a new repo. Are you stating that *IF* the artifacts are not in the central repo they won't find it and won't know how to use it? As a force of habit most Maven users, particularly those coming from Maven 1.x, assume all open source artifacts are in the central repository. And in most cases for Maven 2.x all artifact required are placed in the central repository. It would be an unnecessary inconvenience. If the goal is to raise awareness that it is from the incubator then it can be done with the version. It could even be 1.0-apache-incubator-foo (1) As I think that would be preferable to users and that is abundantly clear I think. The least anyone will need to know is the artifact id and version id and they find this when they browse a project's pages, are you stating that a user will never look at anyone's web site or download area and will *ONLY* look at ibiblio repo and decide to use a project? The whole point of Maven is to make this easy for users and not have to look at a project's site. Maven users expect what they need to be in the central repository as shown by the many threads when users go to use Sun JARs and we don't have them in the central repository. If they do indeed look, isn't it trivial to add instructions on adding info on how to add the incubation repo? Where's the problem? A lot of times people actually go to the central repository to find the artifact's groupId and artifactId. They don't go to project websites, they go to the authority which is the central repository. If the goal here is user awareness then I think using an version like (1) supports this end to a great extent while being more convenient for the average Maven user. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote: On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: policy, so I see those as in conflict right now. So I want to know on what grounds the incubator can prevent me from requesting that some incubating jars from being uploaded to ibiblio. Common decency? If we (as the project owners) ask those artifacts not to be posted, then they shouldn't be posted as a matter of courtesy. It just means that we have to start watching for requests coming from users to put artifacts in the repository. Effectively you are asking us to deny the terms of redistribution stated in our license are you not? We could watch for requests going into Ibiblio, but we can't prevent someone else from putting in a repository that they might use. What is going to happen is that people are going to want to use these artifacts and they will want to rsync Ibiblio, which many people do, and then attempt to rsync the incubator repository. We are just going to try and circumvent a path that we cannot fully block off. I don't see what is not clear with *every* incubator artifact being marked with a version that has incubator in it. Plus the reports that can be generated give a clear view to users what they are consuming. I read this: http://marc.theaimsgroup.com/?l=incubator- generalm=115440663222532w=2 and to be frank (4) is somewhat paradoxical to me. You want an incubator project to thrive, and grow while we are tacitly, yet actively, discouraging their use? I think we should let people use their common sense to protect themselves. What is being envisioned here as the worst case scenario of using an incubator artifact for a failed incubator project? The mail says protect the user, but from what? I'm not going to discourage the use of a project I'm mentoring and fully support. I'm going to get everyone on the planet I can to use it as fast and as widely as possible. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen
Re: [policy] incubating projects and maven repositories v1.0
Hmm, we are not setting any limits on anyone else, just ourselves. We the incubator folks will not automatically sync *our* repo to the central repo *automatically*. Everyone else can do what they want within their rights. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 10:16 PM 30 Aug 06, Davanum Srinivas wrote: Please see this email from Noel: http://marc.theaimsgroup.com/?l=incubator- generalm=115440482328786w=2 Why can't both aims be met? That of user protection and user convenience? I cannot see the how marking *each* and *every* incubator artifact with a version that clearly says it is from the Apache Incubator gives less clarity then adding a repository element. In a standard dependency report like: http://jackrabbit.apache.org/dependencies.html It would be very clear looking at the version that it came from the incubator. And if people download these artifacts with non-Maven tools like an Ant Task, Ivy or simply check in versions of these artifacts then they will clearly be seen as coming from the incubator. If we are going to make it clear then let's do it in the place where it will be seen by everyone regardless of the tool they use to build. Also the Maven 2.x IDE integration will soon have the ability to pull indices from repositories in order to provide drop down/searchable lists of available artifacts so it will be easy to grab new artifacts to put in your POMs. An IDE could easily provide a set of repositories to pull indices from at which point the user is going to merrily start pulling down dependencies. When you select an artifact you always select the version, like in the Eclipse integration, so people will see apache-incubator over and over. They will see the repository entry once. If I then had to go to the people doing IDE integration and say please don't include the apache incubator repository. So you are going to make us: 1) Deny people the right to distribute software as described in our license 2) Make the Maven developers go search out all third party integration efforts to prevent them from providing convenient access to certain repositories I think this is a little heavy handed, unfair and unnecessary. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 7:53 PM 30 Aug 06, Davanum Srinivas wrote: Jason, Is it rocket science to add a new repo location in pom.xml? *Any* maven newbie learns *very* quickly how to add a new repo. Are you stating that *IF* the artifacts are not in the central repo they won't find it and won't know how to use it? As a force of habit most Maven users, particularly those coming from Maven 1.x, assume all open source artifacts are in the central repository. And in most cases for Maven 2.x all artifact required are placed in the central repository. It would be an unnecessary inconvenience. If the goal is to raise awareness that it is from the incubator then it can be done with the version. It could even be 1.0-apache-incubator-foo (1) As I think that would be preferable to users and that is abundantly clear I think. The least anyone will need to know is the artifact id and version id and they find this when they browse a project's pages, are you stating that a user will never look at anyone's web site or download area and will *ONLY* look at ibiblio repo and decide to use a project? The whole point of Maven is to make this easy for users and not have to look at a project's site. Maven users expect what they need to be in the central repository as shown by the many threads when users go to use Sun JARs and we don't have them in the central repository. If they do indeed look, isn't it trivial to add instructions on adding info on how to add the incubation repo? Where's the problem? A lot of times people actually go to the central repository to find the artifact's groupId and artifactId. They don't go to project websites, they go to the authority which is the central repository. If the goal here is user awareness then I think using an version like (1) supports this end to a great extent while being more convenient for the average Maven user. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote: On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: policy, so I see those as in conflict right now. So I want to know on what grounds the incubator can prevent me from requesting that some incubating jars from being uploaded to ibiblio. Common decency? If we (as the project owners) ask those artifacts not to be posted, then they shouldn't be posted as a matter of courtesy. It just means that we have to start watching for requests coming from users to put artifacts in the repository. Effectively you are asking us to deny the terms of redistribution stated in our license are you not? We could watch for
Re: [policy] incubating projects and maven repositories v1.0
On 30 Aug 06, at 11:18 PM 30 Aug 06, Davanum Srinivas wrote: Hmm, we are not setting any limits on anyone else, just ourselves. We the incubator folks will not automatically sync *our* repo to the central repo *automatically*. Everyone else can do what they want within their rights. That doesn't really jive with what Justin said in an earlier thread. In that we should tell people not to redistribute incubator artifacts and ask they comply out of courtesy. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 10:16 PM 30 Aug 06, Davanum Srinivas wrote: Please see this email from Noel: http://marc.theaimsgroup.com/?l=incubator- generalm=115440482328786w=2 Why can't both aims be met? That of user protection and user convenience? I cannot see the how marking *each* and *every* incubator artifact with a version that clearly says it is from the Apache Incubator gives less clarity then adding a repository element. In a standard dependency report like: http://jackrabbit.apache.org/dependencies.html It would be very clear looking at the version that it came from the incubator. And if people download these artifacts with non-Maven tools like an Ant Task, Ivy or simply check in versions of these artifacts then they will clearly be seen as coming from the incubator. If we are going to make it clear then let's do it in the place where it will be seen by everyone regardless of the tool they use to build. Also the Maven 2.x IDE integration will soon have the ability to pull indices from repositories in order to provide drop down/searchable lists of available artifacts so it will be easy to grab new artifacts to put in your POMs. An IDE could easily provide a set of repositories to pull indices from at which point the user is going to merrily start pulling down dependencies. When you select an artifact you always select the version, like in the Eclipse integration, so people will see apache-incubator over and over. They will see the repository entry once. If I then had to go to the people doing IDE integration and say please don't include the apache incubator repository. So you are going to make us: 1) Deny people the right to distribute software as described in our license 2) Make the Maven developers go search out all third party integration efforts to prevent them from providing convenient access to certain repositories I think this is a little heavy handed, unfair and unnecessary. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 7:53 PM 30 Aug 06, Davanum Srinivas wrote: Jason, Is it rocket science to add a new repo location in pom.xml? *Any* maven newbie learns *very* quickly how to add a new repo. Are you stating that *IF* the artifacts are not in the central repo they won't find it and won't know how to use it? As a force of habit most Maven users, particularly those coming from Maven 1.x, assume all open source artifacts are in the central repository. And in most cases for Maven 2.x all artifact required are placed in the central repository. It would be an unnecessary inconvenience. If the goal is to raise awareness that it is from the incubator then it can be done with the version. It could even be 1.0-apache-incubator-foo (1) As I think that would be preferable to users and that is abundantly clear I think. The least anyone will need to know is the artifact id and version id and they find this when they browse a project's pages, are you stating that a user will never look at anyone's web site or download area and will *ONLY* look at ibiblio repo and decide to use a project? The whole point of Maven is to make this easy for users and not have to look at a project's site. Maven users expect what they need to be in the central repository as shown by the many threads when users go to use Sun JARs and we don't have them in the central repository. If they do indeed look, isn't it trivial to add instructions on adding info on how to add the incubation repo? Where's the problem? A lot of times people actually go to the central repository to find the artifact's groupId and artifactId. They don't go to project websites, they go to the authority which is the central repository. If the goal here is user awareness then I think using an version like (1) supports this end to a great extent while being more convenient for the average Maven user. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote: On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: policy, so I see those as in conflict right now. So I want to know on what grounds the incubator can prevent me from requesting that some incubating jars from being uploaded to ibiblio. Common decency? If we (as the project owners) ask those artifacts not to be posted, then they
[STATUS] (incubator) Wed Aug 30 23:52:39 2006
APACHE INCUBATOR PROJECT STATUS: -*-indented-text-*- Last modified at [$Date: 2006-02-05 04:40:19 -0500 (Sun, 05 Feb 2006) $] Web site: http://Incubator.Apache.Org/ Wiki page: http://wiki.apache.org/incubator/ [note: the Web site is the 'official' documentation; the wiki pages are for collaborative development, including stuff destined for the Web site.] Pending Issues == o We need to be very very clear about what it takes to be accepted into the incubator. It should be a very low bar to leap, possibly not much more than 'no problematic code' and the existence of a healthy community (we don't want to become a dumping ground). o We need to be very very clear about what it takes for a podling to graduate from the incubator. The basic requirements obviously include: has a home, either as part of another ASF project or as a new top-level project of its own; needs to be a credit to the ASF and function well in the ASF framework; ... See also: https://issues.apache.org/jira/browse/INCUBATOR Resolved Issues === o The policy documentation does not need ratification of changes if there seems consensus. Accordingly, the draft status of these documents can be removed and we will use the lazy commit first, discuss later mode common across the ASF for documentation (http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=517190) o Coming up with a set of bylaws for the project (http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=517190) o All projects under incubation must maintain a status Web page that contains information the PMC needs about the project. (http://incubator.apache.org/guides/website.html) o Projects under incubation should display appropriate disclaimers so that it is clear that they are, indeed, under incubation (http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=504543) o Clearly and authoritatively document how to edit, generate, and update the Web site (three separate functions) (http://incubator.apache.org/guides/website.html). The Incubation Process == TODO: this does not belong in the STATUS file and probably was integrated into other documentation a while ago. That should be double-checked and then this section should be removed. This tries to list all the actions items that must be complete for a project before it can graduate from the incubator. It is probably incomplete. Identify the project to be incubated: -- Make sure that the requested project name does not already exist and check www.nameprotect.com to be sure that the name is not already trademarked for an existing software product. -- If request from an existing Apache project to adopt an external package, then ask the Apache project for the cvs module and mail address names. -- If request from outside Apache to enter an existing Apache project, then post a message to that project for them to decide on acceptance. -- If request from anywhere to become a stand-alone PMC, then assess the fit with the ASF, and create the lists and modules under the incubator address/module names if accepted. Interim responsibility: -- Who has been identified as the mentor for the incubation? -- Are they tracking progress on the project status Web page? Copyright: -- Have the papers that transfer rights to the ASF been received? It is only necessary to transfer rights for the package, the core code, and any new code produced by the project. -- Have the files been updated to reflect the new ASF copyright? Verify distribution rights: -- For all code included with the distribution that is not under the Apache license, do we have the right to combine with Apache-licensed code and redistribute? -- Is all source code distributed by the project covered by one or more of the following approved licenses: Apache, BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially the same terms? Establish a list of active committers: -- Are all active committers listed in the project status file? -- Do they have accounts on cvs.apache.org? -- Have they submitted a contributors agreement? Infrastructure: -- CVS modules created and committers added to avail file? -- Mailing lists set up and archived? -- Problem tracking system (Bugzilla)? -- Has the project migrated to our infrastructure? Collaborative Development: -- Have all of the active long-term volunteers been identified and acknowledged as committers on the project? -- Are there three or more independent committers? [The legal definition of independent is long and boring, but basically it means that there is no binding relationship between the individuals, such as a
Re: [policy] incubating projects and maven repositories v1.0
Jason, Justin used the word common decency. No one can twist anyone's arm. If either the ibiblio folks or Maven PMC folks don't honor the request, well, it's upto them...Here we are setting policy for us the incubator participants, incubator mentors and incubator pmc folks. If people working on the incubation project break the policy, then that's an issue for us. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 11:18 PM 30 Aug 06, Davanum Srinivas wrote: Hmm, we are not setting any limits on anyone else, just ourselves. We the incubator folks will not automatically sync *our* repo to the central repo *automatically*. Everyone else can do what they want within their rights. That doesn't really jive with what Justin said in an earlier thread. In that we should tell people not to redistribute incubator artifacts and ask they comply out of courtesy. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 10:16 PM 30 Aug 06, Davanum Srinivas wrote: Please see this email from Noel: http://marc.theaimsgroup.com/?l=incubator- generalm=115440482328786w=2 Why can't both aims be met? That of user protection and user convenience? I cannot see the how marking *each* and *every* incubator artifact with a version that clearly says it is from the Apache Incubator gives less clarity then adding a repository element. In a standard dependency report like: http://jackrabbit.apache.org/dependencies.html It would be very clear looking at the version that it came from the incubator. And if people download these artifacts with non-Maven tools like an Ant Task, Ivy or simply check in versions of these artifacts then they will clearly be seen as coming from the incubator. If we are going to make it clear then let's do it in the place where it will be seen by everyone regardless of the tool they use to build. Also the Maven 2.x IDE integration will soon have the ability to pull indices from repositories in order to provide drop down/searchable lists of available artifacts so it will be easy to grab new artifacts to put in your POMs. An IDE could easily provide a set of repositories to pull indices from at which point the user is going to merrily start pulling down dependencies. When you select an artifact you always select the version, like in the Eclipse integration, so people will see apache-incubator over and over. They will see the repository entry once. If I then had to go to the people doing IDE integration and say please don't include the apache incubator repository. So you are going to make us: 1) Deny people the right to distribute software as described in our license 2) Make the Maven developers go search out all third party integration efforts to prevent them from providing convenient access to certain repositories I think this is a little heavy handed, unfair and unnecessary. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 7:53 PM 30 Aug 06, Davanum Srinivas wrote: Jason, Is it rocket science to add a new repo location in pom.xml? *Any* maven newbie learns *very* quickly how to add a new repo. Are you stating that *IF* the artifacts are not in the central repo they won't find it and won't know how to use it? As a force of habit most Maven users, particularly those coming from Maven 1.x, assume all open source artifacts are in the central repository. And in most cases for Maven 2.x all artifact required are placed in the central repository. It would be an unnecessary inconvenience. If the goal is to raise awareness that it is from the incubator then it can be done with the version. It could even be 1.0-apache-incubator-foo (1) As I think that would be preferable to users and that is abundantly clear I think. The least anyone will need to know is the artifact id and version id and they find this when they browse a project's pages, are you stating that a user will never look at anyone's web site or download area and will *ONLY* look at ibiblio repo and decide to use a project? The whole point of Maven is to make this easy for users and not have to look at a project's site. Maven users expect what they need to be in the central repository as shown by the many threads when users go to use Sun JARs and we don't have them in the central repository. If they do indeed look, isn't it trivial to add instructions on adding info on how to add the incubation repo? Where's the problem? A lot of times people actually go to the central repository to find the artifact's groupId and artifactId. They don't go to project websites, they go to the authority which is the central repository. If the goal here is user awareness then I think using an version like (1) supports this end to a great extent while being more convenient for the average Maven user. -- dims
Re: [policy] incubating projects and maven repositories v1.0
On 31 Aug 06, at 12:18 AM 31 Aug 06, Davanum Srinivas wrote: Jason, Justin used the word common decency. No one can twist anyone's arm. If either the ibiblio folks or Maven PMC folks don't honor the request, well, it's upto them...Here we are setting policy for us the incubator participants, incubator mentors and incubator pmc folks. If people working on the incubation project break the policy, then that's an issue for us. It's not policy until we vote on it. So I guess it's time to vote. How is this done, no the general list? For 72 hours? A majority wins? -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 11:18 PM 30 Aug 06, Davanum Srinivas wrote: Hmm, we are not setting any limits on anyone else, just ourselves. We the incubator folks will not automatically sync *our* repo to the central repo *automatically*. Everyone else can do what they want within their rights. That doesn't really jive with what Justin said in an earlier thread. In that we should tell people not to redistribute incubator artifacts and ask they comply out of courtesy. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 10:16 PM 30 Aug 06, Davanum Srinivas wrote: Please see this email from Noel: http://marc.theaimsgroup.com/?l=incubator- generalm=115440482328786w=2 Why can't both aims be met? That of user protection and user convenience? I cannot see the how marking *each* and *every* incubator artifact with a version that clearly says it is from the Apache Incubator gives less clarity then adding a repository element. In a standard dependency report like: http://jackrabbit.apache.org/dependencies.html It would be very clear looking at the version that it came from the incubator. And if people download these artifacts with non-Maven tools like an Ant Task, Ivy or simply check in versions of these artifacts then they will clearly be seen as coming from the incubator. If we are going to make it clear then let's do it in the place where it will be seen by everyone regardless of the tool they use to build. Also the Maven 2.x IDE integration will soon have the ability to pull indices from repositories in order to provide drop down/searchable lists of available artifacts so it will be easy to grab new artifacts to put in your POMs. An IDE could easily provide a set of repositories to pull indices from at which point the user is going to merrily start pulling down dependencies. When you select an artifact you always select the version, like in the Eclipse integration, so people will see apache-incubator over and over. They will see the repository entry once. If I then had to go to the people doing IDE integration and say please don't include the apache incubator repository. So you are going to make us: 1) Deny people the right to distribute software as described in our license 2) Make the Maven developers go search out all third party integration efforts to prevent them from providing convenient access to certain repositories I think this is a little heavy handed, unfair and unnecessary. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 7:53 PM 30 Aug 06, Davanum Srinivas wrote: Jason, Is it rocket science to add a new repo location in pom.xml? *Any* maven newbie learns *very* quickly how to add a new repo. Are you stating that *IF* the artifacts are not in the central repo they won't find it and won't know how to use it? As a force of habit most Maven users, particularly those coming from Maven 1.x, assume all open source artifacts are in the central repository. And in most cases for Maven 2.x all artifact required are placed in the central repository. It would be an unnecessary inconvenience. If the goal is to raise awareness that it is from the incubator then it can be done with the version. It could even be 1.0-apache-incubator-foo (1) As I think that would be preferable to users and that is abundantly clear I think. The least anyone will need to know is the artifact id and version id and they find this when they browse a project's pages, are you stating that a user will never look at anyone's web site or download area and will *ONLY* look at ibiblio repo and decide to use a project? The whole point of Maven is to make this easy for users and not have to look at a project's site. Maven users expect what they need to be in the central repository as shown by the many threads when users go to use Sun JARs and we don't have them in the central repository. If they do indeed look, isn't it trivial to add instructions on adding info on how to add the incubation repo? Where's the problem? A lot of times people actually go to the central repository to find the artifact's groupId and artifactId. They don't go to project websites, they
Re: [policy] incubating projects and maven repositories v1.0
Yes, general list and majority of binding votes AFAIK. please start another thread with a set of well defined choices to vote on. thanks, dims On 8/31/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 31 Aug 06, at 12:18 AM 31 Aug 06, Davanum Srinivas wrote: Jason, Justin used the word common decency. No one can twist anyone's arm. If either the ibiblio folks or Maven PMC folks don't honor the request, well, it's upto them...Here we are setting policy for us the incubator participants, incubator mentors and incubator pmc folks. If people working on the incubation project break the policy, then that's an issue for us. It's not policy until we vote on it. So I guess it's time to vote. How is this done, no the general list? For 72 hours? A majority wins? -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 11:18 PM 30 Aug 06, Davanum Srinivas wrote: Hmm, we are not setting any limits on anyone else, just ourselves. We the incubator folks will not automatically sync *our* repo to the central repo *automatically*. Everyone else can do what they want within their rights. That doesn't really jive with what Justin said in an earlier thread. In that we should tell people not to redistribute incubator artifacts and ask they comply out of courtesy. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 10:16 PM 30 Aug 06, Davanum Srinivas wrote: Please see this email from Noel: http://marc.theaimsgroup.com/?l=incubator- generalm=115440482328786w=2 Why can't both aims be met? That of user protection and user convenience? I cannot see the how marking *each* and *every* incubator artifact with a version that clearly says it is from the Apache Incubator gives less clarity then adding a repository element. In a standard dependency report like: http://jackrabbit.apache.org/dependencies.html It would be very clear looking at the version that it came from the incubator. And if people download these artifacts with non-Maven tools like an Ant Task, Ivy or simply check in versions of these artifacts then they will clearly be seen as coming from the incubator. If we are going to make it clear then let's do it in the place where it will be seen by everyone regardless of the tool they use to build. Also the Maven 2.x IDE integration will soon have the ability to pull indices from repositories in order to provide drop down/searchable lists of available artifacts so it will be easy to grab new artifacts to put in your POMs. An IDE could easily provide a set of repositories to pull indices from at which point the user is going to merrily start pulling down dependencies. When you select an artifact you always select the version, like in the Eclipse integration, so people will see apache-incubator over and over. They will see the repository entry once. If I then had to go to the people doing IDE integration and say please don't include the apache incubator repository. So you are going to make us: 1) Deny people the right to distribute software as described in our license 2) Make the Maven developers go search out all third party integration efforts to prevent them from providing convenient access to certain repositories I think this is a little heavy handed, unfair and unnecessary. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 7:53 PM 30 Aug 06, Davanum Srinivas wrote: Jason, Is it rocket science to add a new repo location in pom.xml? *Any* maven newbie learns *very* quickly how to add a new repo. Are you stating that *IF* the artifacts are not in the central repo they won't find it and won't know how to use it? As a force of habit most Maven users, particularly those coming from Maven 1.x, assume all open source artifacts are in the central repository. And in most cases for Maven 2.x all artifact required are placed in the central repository. It would be an unnecessary inconvenience. If the goal is to raise awareness that it is from the incubator then it can be done with the version. It could even be 1.0-apache-incubator-foo (1) As I think that would be preferable to users and that is abundantly clear I think. The least anyone will need to know is the artifact id and version id and they find this when they browse a project's pages, are you stating that a user will never look at anyone's web site or download area and will *ONLY* look at ibiblio repo and decide to use a project? The whole point of Maven is to make this easy for users and not have to look at a project's site. Maven users expect what they need to be in the central repository as shown by the many threads when users go to use Sun JARs and we don't have them in the central repository. If
Re: [policy] incubating projects and maven repositories v1.0
On Thursday 31 August 2006 00:15, Dan Diephouse wrote: I don't really think that this is going to help anything. The user is always in control. The responsibility has never left their hands. Lets step away from the incubator a sec and take GPL jars for instance - if there is a transitive dependency on GPL jars, the user is completely responsible for that. Why would it be any different for an incubator JAR? The difference is that no Apache project has a transitive dependency on a GPL'd project. The Apache PMC is responsible to ensure that no GPL code is sneaking in via transitive dependencies, and an improved reporting facility in Maven's release plugin would *really* be good, both for licensing and other concerns. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
