I'm going to cc this discussion onto infrastructure. I think it is a valid topic which we need to address there in more detail.
Infrastructure, please review this posting before responding to this subject:
http://article.gmane.org/gmane.comp.jakarta.commons.devel/39469
Jason van Zyl wrote:
On Sat, 2004-07-17 at 21:03, Brett Porter wrote:
I don't know very much about cvs.apache.org/repository.
What I was suggesting was that snapshots that we want to keep should go to /dist/java-repository (which is what happens now).
Cool, that's all that's needed then. Whatever a projects wishes to store on Ibiblio should be stored on Ibiblio. That's all I want to happen. If that can happen with the current setup then that's good.
I'm not going to suggest the current setup is optimal, its not going to meet everyones needs. The infrastructure issues are valid. And you have to consider what the nature of the "www.apache.org/dist directory is in terms of the ASF Repository being there.
My goal in placing it into dist was to actually supersede dist in the long run with the ASF Repository Structure defined in the Specification.
http://wiki.apache.org/old/ASFRepository http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax
This is something some may consider aggressive. Eventually we should actually have a ASF Repository structure that all Apache releases go into (even if it is simply a project placing their stuff into www.apache.org/dist/project/...
Most projects out there do maintain major version releases in dist, and if they are removed from the projects releases directory, its upto the mirror to decide its cleanup strategy in rsync, this means some mirrors will not delete copies, while others will. I beleive archive.apache.org is meant to be such a mirror that maintains all the content that was ever in the www.apache.org/dist directory.
As such, IMHO, the restictions placed on dist are to reduce the archiving of any unofficial releases. So, IMHO placing any "dated build" releases into the ASF Repository violates the requirements because they will be "archived" and they are not a full release.
I recognize its almost impossible for Infrustructure to enforce this policy; for example; managing the release of every single maven plugin within Infrustructure is probibly not in their interest. What is in their interest is being able to maintain a secure release directory with properly signed releases. I'm convinced we are at a point where Infrastructure needs to reflect on the current release strategy and attempt to open it up so that we can manage more complex release scenarios. We also need to establish a course of action to migrate the directory structures to that structure defined by the ASF Repository Spec.
The battle here for us is to maintain "group cohesion" between all the Apache projects in terms of where and how to release content, no matter how painful interaction can become. So, pushing content off to a different location isn't very beneficial in this regard. It may be tedious and frustrating to deal with, but we need to maintain such interaction.
What this means to me is that we have a few possible solutions for the future direction of ASF Repository:
1.) do not allow any interim content into www/dist. Interm content gets placed under cvs.apache.org/repository. This gives us a means to allow testing of interim content while not having all the mirrors (including ibibilio and the archive) get flooded with it.
2.) Establish a means to filter what gets into the archive (and possibly the mirrors). Store all content under one repository location (in dist). This is allot more complex and will require effort across multiple projects and infrastructure to establish as a practice. (I'm not convinced this will be possible).
3.) Establish the ASF Repository independent of the www/dist directory and manage all the content within it, providing our own mechanisms for archiving and allowing interim builds. Initial structure will be "Maven" like, migrating however, to the ASF Repository Specification. The problem is that this fractures the community into those that want to release in the old directory structure and those that want to release in the Repository.
So, theres allot of discussion and voting that needs to continue on this subject to determine the best course of action, I think that the current compromise is not an effective solution for the long term, It reflects my initial efforts to establish a repository for ASF projects and now that we have our footing we need more member involvement and decision making to establish the proper direction for this to go into. This kind of growth is hard, changing the way a project releases is a project in and of itself.
-Mark Diggory
Quoting Jason van Zyl <[EMAIL PROTECTED]>:
On Sat, 2004-07-17 at 19:46, Brett Porter wrote:
Nightly builds go to http://cvs.apache.org/repository, which is
something we don't do at the moment, and something I don't think needs to be synced out to the mirrors. My understanding is that the ASF for legal reasons needs a PMC vote on a release
to have it officially released, and automated builds are obviously not that.
I think what we have at the moment is fine.
If someone wishes to have a snapshot persist does this happen? If
the snapshots are not archived in perpetuity then it's not fine.
A project should be able to have last what it desires to last. If the Apache repository where snapshots go lives on that's cool,
otherwise something else needs to be done. Either the PMC for a
project should just be able to say snapshots between versions
are fine for release to ibiblio or the snapshots place in the
Apache repo for this must persist. I agree that storing nightlies
might be a little excessive but if a project makes a snapshot per
week and wishes it to live on at Ibiblio they should be able to
do this.
Do you know what the lifespan is for snapshots stored in cvs.apache.org/repository
?
Cheers, Brett
Quoting Carlos Sanchez <[EMAIL PROTECTED]>:
Hi,
I've read recently a mail about an apache repository for non
public releases at http://cvs.apache.org/repository/, not mirrored to ibiblio, that we (maven-plugins developers) don't
use.
I suggest setting it up so we can deploy SNAPSHOT versions there, avoiding user's need to compile sources.
The mail is here http://article.gmane.org/gmane.comp.jakarta.commons.devel/39469
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
