Re: counting downloads
FYI, Vadim is already providing stats on some (non incubating) projects: http://people.apache.org/~vgritsenko/stats/projects/index.html I don't know if it's easy for him to add incubating projects, and how he deals with mirrors. In a sense even if the download counter is not accurate, I agree with eelco to say that the trend can still be interesting. Xavier On 5/2/07, Marshall Schor [EMAIL PROTECTED] wrote: We're curious to see how many downloads we're getting, perhaps sorted by ip number or who's downloading (I realize that would need be volunteered information). Do other projects have a good way to track this? I know we could pull the logs for the p.a.o webserver and grep through them looking for things, but I'm wondering if there's something we can put on our download page that users would click on that would count things? -Marshall Schor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Xavier Hanin - Independent Java Consultant Manage your dependencies with Ivy! http://incubator.apache.org/ivy/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: counting downloads
On 5/3/07, Daniel Kulp [EMAIL PROTECTED] wrote: Noel, On Thursday 03 May 2007 03:59, Noel J. Bergman wrote: Except you forget one detail: incubator artifacts don't go to the mirror system. And that's changing/changed. Can I ask when?The vote that was called in mid march [1] never had a result posted. The discussion [2] that started that vote also didn't seem to reach any type of concensus. we've now had a clear call from infra (incubator works within broader apache policy) i've done this kind of infrastructure work before so i'll pull together a plan in JIRA and run it past people on this list and infra I guess my major concern right now is the CXF/Wicket releases that have gone out in the lasts couple days. Did we do the right thing just putting them in /www/people.apache.org/dist/incubator or should they have gone to the mirrors? There isn't a /www/www.apache.org/dist/incubator directory. Anyway, I'd just like to make sure we didn't do something wrong due to a policy change I missed. (I could easily have missed it, email overload and all) don't worry - IIRC the policy hasn't changed yet IMHO this is something that needs to be fixed by the IPMC. it's going to take a little while to pull everything together. we have some scripts in jakarta that generate the download pages from meta-data and that's the direction i think we need to move in. (they also have some cool RSS/news stuff for releases is cool) i'd rather have CXF and wicket in the old places and have the time to do this properly than delay the releases or rush the move - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: counting downloads
On 5/3/07, Danny Angus [EMAIL PROTECTED] wrote: On 5/2/07, Garrett Rooney [EMAIL PROTECTED] wrote: Do other projects have a good way to track this? I know we could pull the logs for the p.a.o webserver and grep through them looking for things, but I'm wondering if there's something we can put on our download page that users would click on that would count things? James uses google analytics. We currently count the hits to the download cgi page, which is probably over generous, but you can put google javascript on the links to the files themselves, we just haven't done it. i'm going to need to create download pages for the incubator. this isn't one of my personal itches and i would need to research the analytics-foo. but if someone wants to create a JIRA with the required javascripts, i'll take a look at including it. any volunteers? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (INCUBATOR-62) [policy] State distribution directory
[ https://issues.apache.org/jira/browse/INCUBATOR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Burrell Donkin updated INCUBATOR-62: --- Attachment: (was: distribution.patch) [policy] State distribution directory - Key: INCUBATOR-62 URL: https://issues.apache.org/jira/browse/INCUBATOR-62 Project: Incubator Issue Type: Improvement Components: site Reporter: Robert Burrell Donkin Assigned To: Robert Burrell Donkin Attachments: distribution.patch Infrastructure requires that all releases are distributed through www.apache.org/dist. We do not state this explicitly in policy. This has resulted in confusion over the right location for releases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (INCUBATOR-62) [policy] State distribution directory
[ https://issues.apache.org/jira/browse/INCUBATOR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Burrell Donkin updated INCUBATOR-62: --- Attachment: distribution.patch [policy] State distribution directory - Key: INCUBATOR-62 URL: https://issues.apache.org/jira/browse/INCUBATOR-62 Project: Incubator Issue Type: Improvement Components: site Reporter: Robert Burrell Donkin Assigned To: Robert Burrell Donkin Attachments: distribution.patch Infrastructure requires that all releases are distributed through www.apache.org/dist. We do not state this explicitly in policy. This has resulted in confusion over the right location for releases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [suggestion] making documentation management more lightweight
On 5/5/07, Leo Simons [EMAIL PROTECTED] wrote: Jo! The whole jira-patch-commit workflow for the documentation seems annoying. At least it annoys me -- in particular the patches don't show up in my email so I have to visit jira which I try and avoid as much as possible :-). Suggestions: 1) create http://svn.apache.org/repos/asf/incubator/public/staging writeable by *all* committers svn cp http://svn.apache.org/repos/asf/incubator/public/trunk \ http://svn.apache.org/repos/asf/incubator/public/staging vi infrastructure/trunk/subversion/authorization/asf-authorization svn commit infrastructure/trunk/subversion/authorization/asf- authorization ok 2) create an svn:externals on http://svn.apache.org/repos/asf/incubator/public/trunk/site- publish like this website-staging http://svn.apache.org/repos/asf/incubator/ public/staging/site-publish so that you can see the work-in-progress at http://incubator.apache.org/website-staging/ perhaps http://incubator.apache.org/~website-draft-staging/ would be better 3) instead of sending documentation patches, people who are helping with the documentation work on the staging branch ok 4) set up svnmerge.py for staging/ and trunk/ * see http://www.orcaware.com/svn/wiki/Svnmerge.py * make sure to block the revision from step #2! looks good 5) propose documentation changes on the mailing list * get diffs cd incubator/trunk svnmerge.py --bidirectional diff ~/staging-diffs.txt # or use -r to get only a few revisions * send diff to mailing list for discussion and lazy consensus approval ok 6) merge cd incubator/trunk svnmerge.py --bidirectional avail svnmerge.py --bidirectional # or use -r12345,... svn commit -F svnmerge-commit-message.txt cd ../staging svnmerge.py svn commit -F svnmerge-commit-message.txt bit uncertain whether a single set of drafts will work but willing to give it a go so, ok by me - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Fix Release Distribution (Outside maven repo)
infra requires that all releases are contained within /www/www.apache.org/dist/. here's my proposal for fixing the current situation for standard (non-maven) releases: 1 clarify policy (https://issues.apache.org/jira/browse/INCUBATOR-62) 2 explain policy in release management guide 3 create /www/www.apache.org/dist/incubator but no subdirectories as yet 4 locate and archive all existing incubator releases 5 link current releases in archived version 6 generate unified download script for incubator from meta-data. the unified download page will contain a disclaimer. 7 create directories for all current podlings with standard layout and appropriate permissions. README.html documents will contain the disclaimer 8 new releases are placed are mirrored and placed into the appropriate subdirectory of /www/www.apache.org/dist/incubator quick opinions can use poll below - robert 8 [ ] +1 [ ] +0 [ ] -0 [ ] -1 -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[POLL] Incubator Maven Repository
incubator distributions need to be stored under /www/www.apache.org/dist AFACT there are two reasonable options: either create repositories under /www.apache.org/dist/incubator or use the standard maven ones of course, staging for the purpose of release verification would continue to happen under people.apache.org - robert [ ] use standard repositories [ ] relocate repositories under /www.apache.org/dist/incubator - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PROPOSAL vs VOTE [WAS Re: [PROPOSAL] Fix Release Distribution (Outside maven repo)]
On 5/6/07, Martijn Dashorst [EMAIL PROTECTED] wrote: [X] +1 (non-binding) it's a PROPOSAL not a VOTE. it's an informal way of gauging whether there's general consensus around a plan. so there's no difference between binding and non-binding votes. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PROPOSAL vs VOTE [WAS Re: [PROPOSAL] Fix Release Distribution (Outside maven repo)]
On 5/6/07, robert burrell donkin [EMAIL PROTECTED] wrote: On 5/6/07, Martijn Dashorst [EMAIL PROTECTED] wrote: [X] +1 (non-binding) it's a PROPOSAL not a VOTE. it's an informal way of gauging whether there's general consensus around a plan. so there's no difference between binding and non-binding votes. heh... just making sure people would know that I'm not on the IPMC, it caused a bit of confusion at apache con while working with you guys (which I really enjoyed!) Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
On 5/6/07, robert burrell donkin [EMAIL PROTECTED] wrote: [X] use standard repositories I would say that podlings using maven would be required to set their project's group id to org.apache.incubator.podling, and possibly even extend an incubator parent pom. This way the podling distributables are nicely contained inside the incubator space inside the maven repository. There would not be a requirement to name the java packages to org.apache.incubator.podling (as that would require renaming of all projects that are using the code, which is unnecessary IMO). Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
On 5/6/07, Daniel Kulp [EMAIL PROTECTED] wrote: I disagree with setting the groupId to org.apache.incubator.podling. I greatly prefer requiring a version string that includes either incubator or incubating.(ex: 2.0-incubator, 1.3-incubating, etc..) Putting it in the group ID causes a MUCH larger set of headaches for both the project itself as well as all dependent projects upon graduation. You can also end up with two jars on the classpath with the same code in it, just different versions. This is already a concern for existing projects coming from outside Apache. It is completely and easily possible to become dependent on both org.apache.wicket/wicket-1.3.0-incubating-beta1.jar and wicket/wicket-1.2.6.jar Only _not_ depending on podling releases will prevent this for depending projects. Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
On 5/6/07, Martijn Dashorst [EMAIL PROTECTED] wrote: On 5/6/07, Daniel Kulp [EMAIL PROTECTED] wrote: I disagree with setting the groupId to org.apache.incubator.podling. I greatly prefer requiring a version string that includes either incubator or incubating.(ex: 2.0-incubator, 1.3-incubating, etc..) Putting it in the group ID causes a MUCH larger set of headaches for both the project itself as well as all dependent projects upon graduation. You can also end up with two jars on the classpath with the same code in it, just different versions. This is already a concern for existing projects coming from outside Apache. It is completely and easily possible to become dependent on both org.apache.wicket/wicket-1.3.0-incubating-beta1.jar and wicket/wicket-1.2.6.jar I agree, but why add one more possible confusion for your users, and one more possible case for this kind of conflict? I think using only a tag in the version (as you have done for your 1.3 beta 1 version) is enough and less confusing. Xavier Only _not_ depending on podling releases will prevent this for depending projects. Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Xavier Hanin - Independent Java Consultant Manage your dependencies with Ivy! http://incubator.apache.org/ivy/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
[ x ] use standard repositories [ ] relocate repositories under /www.apache.org/dist/incubator Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RAT [Re: [VOTE] approve release of OpenJPA 0.9.7]
On 4/27/07, Eddie O'Neil [EMAIL PROTECTED] wrote: Also, I'm all for requesting that incubating projects requesting IPMC approval of a release provide a RAT report as well as explanations for any missing license headers since that's a focus of a lot of the ensuing conversation about a release. my latest plan is to add the ability to read detached license meta-data and then run RAT continuously (probably using gump) leo's keen on bring RAT in on from the cold (or was at apachecon) so expect a proposal sometime soon - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: counting downloads
Thanks for the clarification Robert. I'm glad we didn't mess something up. :-) I'll definitely keep an eye on the various threads for information about the changes. It all sounds very good to me. :-) Dan On Sunday 06 May 2007 06:55, robert burrell donkin wrote: On 5/3/07, Daniel Kulp [EMAIL PROTECTED] wrote: Noel, On Thursday 03 May 2007 03:59, Noel J. Bergman wrote: Except you forget one detail: incubator artifacts don't go to the mirror system. And that's changing/changed. Can I ask when?The vote that was called in mid march [1] never had a result posted. The discussion [2] that started that vote also didn't seem to reach any type of concensus. we've now had a clear call from infra (incubator works within broader apache policy) i've done this kind of infrastructure work before so i'll pull together a plan in JIRA and run it past people on this list and infra I guess my major concern right now is the CXF/Wicket releases that have gone out in the lasts couple days. Did we do the right thing just putting them in /www/people.apache.org/dist/incubator or should they have gone to the mirrors? There isn't a /www/www.apache.org/dist/incubator directory. Anyway, I'd just like to make sure we didn't do something wrong due to a policy change I missed. (I could easily have missed it, email overload and all) don't worry - IIRC the policy hasn't changed yet IMHO this is something that needs to be fixed by the IPMC. it's going to take a little while to pull everything together. we have some scripts in jakarta that generate the download pages from meta-data and that's the direction i think we need to move in. (they also have some cool RSS/news stuff for releases is cool) i'd rather have CXF and wicket in the old places and have the time to do this properly than delay the releases or rush the move - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][policy] Remove post-graduation check list from policy document
the current policy document unnecessarily specifies actions to be done
after graduation. i would like to see these removed from policy and
replaced by a link to the graduation guide.
see https://issues.apache.org/jira/browse/INCUBATOR-55 or the diff at
the bottom of this document
- robert
8-
[ ] +1Cut the material
[ ] +0 Sounds like a good idea (but not enough time to check)
[ ] -0 Sounds like a bad idea (but not enough time to check)
[ ] -1 Leave the material
Index: site-author/incubation/Incubation_Policy.xml
===
--- site-author/incubation/Incubation_Policy.xml(revision 506650)
+++ site-author/incubation/Incubation_Policy.xml(working copy)
@@ -682,120 +682,8 @@
section id=Post-Graduation+Check+List
titlePost-Graduation Check List
/title
-pThe list below summarizes steps a project needs to perform after
-graduation to move out of the Incubator.
-
- strongPPMC
-/strongrefers to the old PPMC for the graduating project,
-
- strongPMC
-/strongrefers to the new PMC under which the graduating project falls (this
-might be the former PPMC for a new TLP), and
-
- strongProject
-/strongrefers to the committers on the graduating project.
-
+pSee a href='/guides/graduation.html'Gradation Guide/a.
/p
-ul
- liMove svn repository from incubator to new location
-
-ul
- liPMC sends email to infrastructure@ and opens a JIRA
issue requesting
-that infrastructure move the svn repository.
-/li
- liPMC updates the svn-authorization files to provide
committers access
-to the newly-named repositories.
-/li
- liProject verifies all committers have commit access.
-/li
- liProject removes incubator disclaimer notices.
-/li
-/ul
- /li
- liMove web site
-
-ul
- liPMC emails root@ and opens a JIRA issue requesting
UNIX karma for
-committers to access new location on people.apache.org.
-/li
- liProject verifies all committers know how to and
have karma to update
-the new web site.
-/li
- liProject checks out/deploys the files in the new location.
-/li
- liPPMC redirects old incubator URL to the new one by editing
-https://svn.apache.org/repos/asf/incubator/public/trunk/site-publish/.htaccess
.
-/li
- liProject verifies the redirect works, then deletes
old stuff at
-/www/incubator.apache.org/${PROJECT} .
-/li
- liPPMC updates
http://incubator.apache.org/projects/projectname.html
-with graduation status and link to new website location.
-/li
-/ul
- /li
- liCleanup incubator
-
-ul
- liPPMC updates
http://incubator.apache.org/projects/index.html project
-from Currently Incubating to Successfully Incubated table.
-/li
-/ul
- /li
- liUpdate JIRA/Bugzilla
-
-ul
- liPMC emails infrastructure@ requesting that
information for the
-project be updated.
-/li
-/ul
- /li
- liMove mail lists:
-
-ul
- liPMC sends email to infrastructure@ and opens a JIRA
issue requesting
-that the mailing lists and archives be moved.
-/li
-/ul
- /li
- liIf the graduating project wants to send out a press
release, it must
-be cleared with the PRC.
-/li
-/ul
-pAdditional steps for a TLP include:
-/p
-ul
- liA new TLP needs board approval. The PPMC creates a
proposal including
-a proposed PMC chair and sends that to the board.
-/li
- liThe ASF Chairman sends out an official notice that the board has
-approved a new TLP.
-/li
- liPMC may then notify infrastructure@ about the new TLP
so they can add
-DNS entries (and anything else).
-/li
- liThe mentor or other member updates www.apache.org to
add a link to
-the new TLP web site.
-/li
- liThe mentor or other member adds the new PMC to the
board reporting
-schedule (update the committee.txt file).
-/li
- liThe new TLP must send monthly board reports for three
months after
-approval.
-/li
-/ul
-pResources include:
-/p
-ul
- li
-a
href=http://www.apache.org/dev/pmc.html;http://www.apache.org/dev/pmc.html
-/a
- /li
- li
-a
href=http://www.apache.org/dev/#pmc;http://www.apache.org/dev/#pmc
-/a
- /li
-/ul
/section
/section
section id=Roles+in+the+Incubation+Process
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
On 6 May 07, at 4:57 AM 6 May 07, robert burrell donkin wrote: incubator distributions need to be stored under /www/www.apache.org/ dist AFACT there are two reasonable options: either create repositories under /www.apache.org/dist/incubator or use the standard maven ones of course, staging for the purpose of release verification would continue to happen under people.apache.org Wasn't there a vote about this not too long ago? Was that vote not definitive? Jason. - robert [ ] use standard repositories [ ] relocate repositories under /www.apache.org/dist/incubator - 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: [POLL] Incubator Maven Repository
[ ] use standard repositories [ x ] relocate repositories under /www.apache.org/dist/incubator My reasons are as follows: First, NMaven does not follow the standard repo layout; second, the repository layout structure is still in a state of flux, meaning that there is a need for potentially changing the layout for .NET artifacts, while still doing releases. Getting more into some more specifics, with NMaven, there is no version information contained within the artifact file name and the version must follow a standard 0.0.0.0 format. This precludes the use of incubator within the version itself. As mentioned above, at this early stage, it's also not 100% clear on exactly how NMaven .NET artifacts will reside within the repo. For instance, there is an open question as to where pom files will reside when we add the concept of classifiers to the repo. Also, given the repository layout structure for NET artifacts may change over time, as the incubator project evolves, I have concerns whether any of the standard maven repos would accept - and with good reason - an NMaven incubator release at all. I would expect that an incubator release repo would be more amendable to such changes. Shane On 5/6/07, Eelco Hillenius [EMAIL PROTECTED] wrote: [ x ] use standard repositories [ ] relocate repositories under /www.apache.org/dist/incubator Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
On 5/6/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 6 May 07, at 4:57 AM 6 May 07, robert burrell donkin wrote: incubator distributions need to be stored under /www/www.apache.org/ dist AFACT there are two reasonable options: either create repositories under /www.apache.org/dist/incubator or use the standard maven ones of course, staging for the purpose of release verification would continue to happen under people.apache.org Wasn't there a vote about this not too long ago? dunno - anyone have an url? Was that vote not definitive? in the incubator, if the vote doesn't include a patch for policy then it tends to get forgotten - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][RESULT] Graduate OpenJPA from incubation
The vote in the OpenJPA community to graduate from the incubator to a new top level project has completed. The vote thread can be viewed at [1] starting with message [2]. The next step is to prepare a vote for the incubator. +1 votes were recorded from: Craig Russell Patrick Linskey Marc Prud'hommeaux Phill Moran Dain Sundstrom Hans J. Prueller Pinaki Poddar David Jencks Brian McCallister Kevin Sutter Michael Dick Geir Magnusson Jr. Jay D. McHugh Michael Bouschen Eddie O'Neil No -1 or 0 votes were recorded. A couple of personal observations on the vote I very much appreciate the contributions by our Mentors during the process of incubation, and we still would like to have all of you on the new PMC. So if you change your minds, just speak up and we'll be happy to have you back. The discussion regarding the charter of the new project brings up again the importance of communication, both in terms of knowing what people in the community are thinking and if there is an issue, raising it as soon as anyone notices it. [1] http://mail-archives.apache.org/mod_mbox/incubator-open-jpa-dev/ 200705.mbox/thread [2] http://mail-archives.apache.org/mod_mbox/incubator-open-jpa-dev/ 200705.mbox/[EMAIL PROTECTED] Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
RE: [POLL] Incubator Maven Repository
Jason, Would you please address Shane's issues? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
[X ] use standard repositories [ ] relocate repositories under /www.apache.org/dist/incubator On May 6, 2007, at 4:57 AM, robert burrell donkin wrote: incubator distributions need to be stored under /www/www.apache.org/ dist AFACT there are two reasonable options: either create repositories under /www.apache.org/dist/incubator or use the standard maven ones When you talk about repositories it makes me very nervous. Maven does not do a good job with multiple repositories. [If you have a single SNAPSHOT dependency, maven searches through every repository looking for each SNAPSHOT at least once per day and if the repository is not extremely responsive, you end up wasting a lot of time.] So if we choose for special incubator repositories, I'd have to vote in favor of a single incubator repository not multiple repositories. But having read all of the other responses as of right now, I don't see any issues with using the standard maven repository for publishing incubating project release artifacts. The releases are official incubating artifacts that have been through release clearance and as long as they are correctly identified with - incubating in their [version id, artifact id, or group id], IMHO no one will be confused about the status of the artifact. And whether to put -incubating into the group id, artifact id, or version id, I'd leave that decision up to the project. My own preference is in the version id, but I can see reasons for projects preferring the -incubating flag in any of the maven name locations. Craig of course, staging for the purpose of release verification would continue to happen under people.apache.org - robert [ ] use standard repositories [ ] relocate repositories under /www.apache.org/dist/incubator - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE][policy] Remove post-graduation check list from policy document
+1 with one comment.
The guides/graduation.html is absent from the left navbar. If you
update the stylesheet so it appears there, then I'm ok with removing
it. Maybe it belongs as a sub-bullet under Podling Guides as the last
entry.
Craig
On May 6, 2007, at 10:50 AM, robert burrell donkin wrote:
the current policy document unnecessarily specifies actions to be done
after graduation. i would like to see these removed from policy and
replaced by a link to the graduation guide.
see https://issues.apache.org/jira/browse/INCUBATOR-55 or the diff at
the bottom of this document
- robert
8-
[ ] +1Cut the material
[ ] +0 Sounds like a good idea (but not enough time to check)
[ ] -0 Sounds like a bad idea (but not enough time to check)
[ ] -1 Leave the material
Index: site-author/incubation/Incubation_Policy.xml
===
--- site-author/incubation/Incubation_Policy.xml(revision 506650)
+++ site-author/incubation/Incubation_Policy.xml(working copy)
@@ -682,120 +682,8 @@
section id=Post-Graduation+Check+List
titlePost-Graduation Check List
/title
-pThe list below summarizes steps a project needs to
perform after
-graduation to move out of the Incubator.
-
- strongPPMC
-/strongrefers to the old PPMC for the graduating project,
-
- strongPMC
-/strongrefers to the new PMC under which the graduating project
falls (this
-might be the former PPMC for a new TLP), and
-
- strongProject
-/strongrefers to the committers on the graduating project.
-
+pSee a href='/guides/graduation.html'Gradation Guide/a.
/p
-ul
- liMove svn repository from incubator to new location
-
-ul
- liPMC sends email to infrastructure@ and opens a JIRA
issue requesting
-that infrastructure move the svn repository.
-/li
- liPMC updates the svn-authorization files to provide
committers access
-to the newly-named repositories.
-/li
- liProject verifies all committers have commit access.
-/li
- liProject removes incubator disclaimer notices.
-/li
-/ul
- /li
- liMove web site
-
-ul
- liPMC emails root@ and opens a JIRA issue requesting
UNIX karma for
-committers to access new location on people.apache.org.
-/li
- liProject verifies all committers know how to and
have karma to update
-the new web site.
-/li
- liProject checks out/deploys the files in the new
location.
-/li
- liPPMC redirects old incubator URL to the new one
by editing
-https://svn.apache.org/repos/asf/incubator/public/trunk/site-
publish/.htaccess
.
-/li
- liProject verifies the redirect works, then deletes
old stuff at
-/www/incubator.apache.org/${PROJECT} .
-/li
- liPPMC updates
http://incubator.apache.org/projects/projectname.html
-with graduation status and link to new website location.
-/li
-/ul
- /li
- liCleanup incubator
-
-ul
- liPPMC updates
http://incubator.apache.org/projects/index.html project
-from Currently Incubating to Successfully Incubated table.
-/li
-/ul
- /li
- liUpdate JIRA/Bugzilla
-
-ul
- liPMC emails infrastructure@ requesting that
information for the
-project be updated.
-/li
-/ul
- /li
- liMove mail lists:
-
-ul
- liPMC sends email to infrastructure@ and opens a JIRA
issue requesting
-that the mailing lists and archives be moved.
-/li
-/ul
- /li
- liIf the graduating project wants to send out a press
release, it must
-be cleared with the PRC.
-/li
-/ul
-pAdditional steps for a TLP include:
-/p
-ul
- liA new TLP needs board approval. The PPMC creates a
proposal including
-a proposed PMC chair and sends that to the board.
-/li
- liThe ASF Chairman sends out an official notice that
the board has
-approved a new TLP.
-/li
- liPMC may then notify infrastructure@ about the new TLP
so they can add
-DNS entries (and anything else).
-/li
- liThe mentor or other member updates www.apache.org to
add a link to
-the new TLP web site.
-/li
- liThe mentor or other member adds the new PMC to the
board reporting
-schedule (update the committee.txt file).
-/li
- liThe new TLP must send monthly board reports for three
months after
-approval.
-/li
-/ul
-pResources include:
-/p
-ul
- li
-a
href=http://www.apache.org/dev/pmc.html;http://www.apache.org/dev/
pmc.html
-/a
- /li
- li
-a
href=http://www.apache.org/dev/#pmc;http://www.apache.org/dev/#pmc
-/a
- /li
-
Re: [POLL] Incubator Maven Repository
Shane, Honestly, it sounds like the NMaven stuff will need a complete new set of repositories for NMaven artifacts. There isn't any way, IMO, that the repo layout can change for the normal maven 1 and maven 2 repositories. Incubator or repo1.maven.org is relatively irrelevant in that regards. The layout is pretty much set in stone. There are too many plugins (deploy, etc...) that rely on it, there are too many other apps (several different proxy applications, etc...) that rely on it, etc... If the current layout is inadequate for NMaven, the NMaven team should figure out an appropriate place for a new repository. My personal suggestion is to work with the Maven team and create a new area at repo1.maven.org/nmaven or similar. But that's me. In either case, I think that discussion is separate from where the m2 artifacts go. It make make sense to put the nmaven stuff in dist/incubator for a while until the layout is finalized, then move to central.However, the layouts for m1/m2 are finalized. Thus, they can/should go to central. (IMO) That said, I don't know the NMaven details. But my #1 concern is your line: I would expect that an incubator release repo would be more amendable to such changes. No chance, IMO. Once an artifact is released, it's SET IN STONE. That includes the layout of the repository it's sitting in. Once theres the possibility that another project is relying on a particular artifact to be living at a particular location, it needs to stay there. The incubator m2 release repository is no different from central in that regard. Dan On Sunday 06 May 2007 14:11, Shane Isbell wrote: [ ] use standard repositories [ x ] relocate repositories under /www.apache.org/dist/incubator My reasons are as follows: First, NMaven does not follow the standard repo layout; second, the repository layout structure is still in a state of flux, meaning that there is a need for potentially changing the layout for .NET artifacts, while still doing releases. Getting more into some more specifics, with NMaven, there is no version information contained within the artifact file name and the version must follow a standard 0.0.0.0 format. This precludes the use of incubator within the version itself. As mentioned above, at this early stage, it's also not 100% clear on exactly how NMaven .NET artifacts will reside within the repo. For instance, there is an open question as to where pom files will reside when we add the concept of classifiers to the repo. Also, given the repository layout structure for NET artifacts may change over time, as the incubator project evolves, I have concerns whether any of the standard maven repos would accept - and with good reason - an NMaven incubator release at all. I would expect that an incubator release repo would be more amendable to such changes. Shane On 5/6/07, Eelco Hillenius [EMAIL PROTECTED] wrote: [ x ] use standard repositories [ ] relocate repositories under /www.apache.org/dist/incubator Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
I didn't have a chance to talk about this with Shane but the idea in the end is to make the repository agnostic on how things are stored and how the client uses them. Right now is a simple directory, but could be a database with a web front end or anything like that. It shouldn't matter how NMaven artifacts are stored, as long as the client handles them correctly. A solution we talked about time ago was to put them as any other artifacts and either developers could choose what format their local repo is in or the pom could say how they should be stored But this is a total different discussion On 5/6/07, Daniel Kulp [EMAIL PROTECTED] wrote: Shane, Honestly, it sounds like the NMaven stuff will need a complete new set of repositories for NMaven artifacts. There isn't any way, IMO, that the repo layout can change for the normal maven 1 and maven 2 repositories. Incubator or repo1.maven.org is relatively irrelevant in that regards. The layout is pretty much set in stone. There are too many plugins (deploy, etc...) that rely on it, there are too many other apps (several different proxy applications, etc...) that rely on it, etc... If the current layout is inadequate for NMaven, the NMaven team should figure out an appropriate place for a new repository. My personal suggestion is to work with the Maven team and create a new area at repo1.maven.org/nmaven or similar. But that's me. In either case, I think that discussion is separate from where the m2 artifacts go. It make make sense to put the nmaven stuff in dist/incubator for a while until the layout is finalized, then move to central.However, the layouts for m1/m2 are finalized. Thus, they can/should go to central. (IMO) That said, I don't know the NMaven details. But my #1 concern is your line: I would expect that an incubator release repo would be more amendable to such changes. No chance, IMO. Once an artifact is released, it's SET IN STONE. That includes the layout of the repository it's sitting in. Once theres the possibility that another project is relying on a particular artifact to be living at a particular location, it needs to stay there. The incubator m2 release repository is no different from central in that regard. Dan On Sunday 06 May 2007 14:11, Shane Isbell wrote: [ ] use standard repositories [ x ] relocate repositories under /www.apache.org/dist/incubator My reasons are as follows: First, NMaven does not follow the standard repo layout; second, the repository layout structure is still in a state of flux, meaning that there is a need for potentially changing the layout for .NET artifacts, while still doing releases. Getting more into some more specifics, with NMaven, there is no version information contained within the artifact file name and the version must follow a standard 0.0.0.0 format. This precludes the use of incubator within the version itself. As mentioned above, at this early stage, it's also not 100% clear on exactly how NMaven .NET artifacts will reside within the repo. For instance, there is an open question as to where pom files will reside when we add the concept of classifiers to the repo. Also, given the repository layout structure for NET artifacts may change over time, as the incubator project evolves, I have concerns whether any of the standard maven repos would accept - and with good reason - an NMaven incubator release at all. I would expect that an incubator release repo would be more amendable to such changes. Shane On 5/6/07, Eelco Hillenius [EMAIL PROTECTED] wrote: [ x ] use standard repositories [ ] relocate repositories under /www.apache.org/dist/incubator Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Fix Release Distribution (Outside maven repo)
Hi Robert, +1 for getting this going. My only concern is the slightly ambiguous #7. I don't know that there is a standard layout for releases. It sure would be nice. I really hate to bring up maven since the subject is clearly non- maven, but I expect many projects to build the source and binary release artifacts using maven. So it might be good to see what the maven folks would produce, before we hard code the standard layout. Craig On May 6, 2007, at 4:45 AM, robert burrell donkin wrote: infra requires that all releases are contained within /www/www.apache.org/dist/. here's my proposal for fixing the current situation for standard (non-maven) releases: 1 clarify policy (https://issues.apache.org/jira/browse/INCUBATOR-62) 2 explain policy in release management guide 3 create /www/www.apache.org/dist/incubator but no subdirectories as yet 4 locate and archive all existing incubator releases 5 link current releases in archived version 6 generate unified download script for incubator from meta-data. the unified download page will contain a disclaimer. 7 create directories for all current podlings with standard layout and appropriate permissions. README.html documents will contain the disclaimer 8 new releases are placed are mirrored and placed into the appropriate subdirectory of /www/www.apache.org/dist/incubator quick opinions can use poll below - robert 8 [ ] +1 [ ] +0 [ ] -0 [ ] -1 -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
