You are viewing a plain text version of this content. The canonical link for it is here.
Posted to repository@apache.org by Trustin Lee <tr...@gmail.com> on 2006/12/05 07:13:30 UTC
Sync Request: Apache MINA 1.0.1
Hello,
Please sync the latest release of Apache MINA to the mirrors. The groupId
is org.apache.mina.
Thank you in advance,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: Sync Request: Apache MINA 1.0.1
Posted by Trustin Lee <tr...@gmail.com>.
On 12/5/06, Carlos Sanchez <ca...@apache.org> wrote:
>
> now it's automatic
Oops! Sorry for noise!
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: Sync Request: Apache MINA 1.0.1
Posted by Carlos Sanchez <ca...@apache.org>.
it starts every four hours, starting at 0 CST
On 12/5/06, Jorg Heymans <jh...@apache.org> wrote:
> Carlos Sanchez wrote:
> > now it's automatic
>
> I don't know if this came up before, but is it documented somewhere at
> which times this automatic sync occurs? It would help projects to avoid
> releasing during a sync.
>
> Jorg
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: Staging repository
Posted by Steve Loughran <st...@gmail.com>.
On 06/12/06, Reinhard Poetz <re...@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....
-steve
Re: Staging repository
Posted by Reinhard Poetz <re...@apache.org>.
Wendy Smoak wrote:
> On 12/6/06, Reinhard Poetz <re...@apache.org> wrote:
>
>> So what about setting up a directory
>> /x1/www/people.apache.org/repo/m2-staging-repository at
>> people.apache.org?
>
> I think staging repos will be per-project, or even per-release.
>
> As an example, for MyFaces we have
> http://people.apache.org/builds/myfaces/m2-staging-repository defined
> in the master pom.
>
> When I did the 1.1.4 build, I deployed it there, but then immediately
> moved the entire directory down underneath
> http://people.apache.org/builds/myfaces/core-1.1.4, which also held
> the release assemblies were placed prior to the vote.
I don't have a problem with /x1/www/people.apache.org/builds/cocoon (for Cocoon)
either. Do others agree with using /x1/www/people.apache.org/builds/ as staging
directory?
> That made promoting it to the rsync repo very simple-- just copy
> everything over. (Well, that messes up the repository metadata, but
> it's the best I can come up with right now.)
AFAIK the repository metadata is only important for snapshots. Releases are
fetched directly without requiring metadata.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Staging repository
Posted by Wendy Smoak <ws...@gmail.com>.
On 12/6/06, Reinhard Poetz <re...@apache.org> wrote:
> So what about setting up a directory
> /x1/www/people.apache.org/repo/m2-staging-repository at people.apache.org?
I think staging repos will be per-project, or even per-release.
As an example, for MyFaces we have
http://people.apache.org/builds/myfaces/m2-staging-repository defined
in the master pom.
When I did the 1.1.4 build, I deployed it there, but then immediately
moved the entire directory down underneath
http://people.apache.org/builds/myfaces/core-1.1.4, which also held
the release assemblies were placed prior to the vote.
That made promoting it to the rsync repo very simple-- just copy
everything over. (Well, that messes up the repository metadata, but
it's the best I can come up with right now.)
--
Wendy
Staging repository
Posted by Reinhard Poetz <re...@apache.org>.
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.
>
> At the moment we (Cocoon) decided to 'stage' our release to
> people.a.o:~jheymans/staging-repo. After testing we 'mv' the files to
> ibiblio-rsync. Not an ideal situation but i guess there aren't really
> any alternatives.
>
>> (I'm not sure how your project is handling releases
though it's an important reason for us because we want to vote on the artifacts
that are available in the staging repository.
>>, 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.
that's definitly another good argument for a staging repo.
- o -
So what about setting up a directory
/x1/www/people.apache.org/repo/m2-staging-repository at people.apache.org?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Sync Request: Apache MINA 1.0.1
Posted by Jorg Heymans <jh...@apache.org>.
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.
At the moment we (Cocoon) decided to 'stage' our release to
people.a.o:~jheymans/staging-repo. After testing we 'mv' the files to
ibiblio-rsync. Not an ideal situation but i guess there aren't really
any alternatives.
> (I'm not sure how your project is handling releases, 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.
Regards
Jorg
Re: Sync Request: Apache MINA 1.0.1
Posted by Wendy Smoak <ws...@gmail.com>.
On 12/5/06, Jorg Heymans <jh...@apache.org> wrote:
> I don't know if this came up before, but is it documented somewhere at
> which times this automatic sync occurs? It would help projects to avoid
> releasing during a sync.
It's not formalized yet, but opinion is leaning towards "projects
shouldn't release directly to the rsync repos".
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.
(I'm not sure how your project is handling releases, 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.)
--
Wendy
Re: Sync Request: Apache MINA 1.0.1
Posted by Jorg Heymans <jh...@apache.org>.
Carlos Sanchez wrote:
> now it's automatic
I don't know if this came up before, but is it documented somewhere at
which times this automatic sync occurs? It would help projects to avoid
releasing during a sync.
Jorg
Re: Sync Request: Apache MINA 1.0.1
Posted by Carlos Sanchez <ca...@apache.org>.
now it's automatic
On 12/4/06, Trustin Lee <tr...@gmail.com> wrote:
> Hello,
>
> Please sync the latest release of Apache MINA to the mirrors. The groupId
> is org.apache.mina.
>
> Thank you in advance,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride