www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <steve.lough...@gmail.com>
Subject Re: Staging repository
Date Wed, 06 Dec 2006 20:28:59 GMT
On 06/12/06, Reinhard Poetz <reinhard@apache.org> wrote:
> Jorg Heymans wrote:
> > Wendy Smoak wrote:
> >
> >> It's not formalized yet, but opinion is leaning towards "projects
> >> shouldn't release directly to the rsync repos".
> >
> > If one shouldn't use it as a remote repo and one shouldn't release to it
> > then perhaps it shouldn't be named 'repo' anymore. It only confuses people.
> >
> >>
> >> There was talk at ApacheCon US and on dev@maven about staging releases
> >> and then promoting them to the release/rsync repo after a vote.

> though it's an important reason for us because we want to vote on the artifacts
> that are available in the staging repository.

yes, you are required to vote on releases before they are released,
and that means vote on teh real binaries.

> >>, but your concern
> >> about releasing during a sync made me think you're concerned about not
> >> having a chance to review it before it syncs.)
> >>
> >
> > It's not so much that we wouldn't get a chance to review, it's more that
> > we are afraid that the sync cronjob kicks in during a release execution
> > and publishes only half or parts of the released artifacts.

With a transacted FS or SVN/clearcase behind the scenes, that wouldnt
be an issue.

> that's definitly another good argument for a staging repo.

I'm actually in favour of having a a staging repo for a different
reason. We know too many projects publish stuff with bad metadata, or
even artifacts in the wrong place. Carlos does an excellent job fixing
this where possible, but is still damage limitation -and we know
things like commons-logging get in there with duff MD that we cannot
do anything about.

The public repository should be locked down to the extent that no
group can get artifacts in there if they fail the audit. This should
be something that looks for bad pom content, and flags to the repo
management places where oversight is needed. An unexpected use of
junit or logkit, a dependency on an unreleased artifact, unexpanded
${project.version} strings, bad XMLNS, no license. This is not some
team we-can-fix-it-I-know-all-eight-developers repository, this is the
defacto standard for redistributing artifacts in the Java space. And
right now the quality of the metadata is a bit inconsistent. What's
particularly saddening is that the m2 repo is about as messy as the m1
one was.

As usual, I have no free time to contribute to this. But once the POM
to RDF conversion is complete, we should have everything in a state
that tools can analyze and flag trouble. Over to the RDF people....


View raw message