You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2011/03/25 02:39:49 UTC
[VOTE] Release Apache Commons Codec 1.5-RC1
[VOTE] Release Apache Commons Codec 1.5-RC1
Tag:
https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
Site:
http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
Binaries:
https://repository.apache.org/content/repositories/orgapachecommons-041/
[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Mar 26, 2011 at 12:06 PM, Oliver Heger <oliver.heger@oliver-heger.de
> wrote:
> Artifacts and site look good. Maven build works fine on JDK 1.5 and 1.6
> under windows 7.
>
> I had a problem with the ant build: ant test gave me compile errors in some
> test classes which is probably an encoding issue. I don't think this is
> blocking.
>
Yes, some source files are in UTF-8 to account for German characters in
Javadoc comments and test sources. Fixed in SVN.
> So +1.
>
Roger that!
Gary
>
> Oliver
>
> Am 25.03.2011 02:39, schrieb Gary Gregory:
>
> [VOTE] Release Apache Commons Codec 1.5-RC1
>>
>> Tag:
>>
>>
>> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
>>
>> Site:
>>
>> http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
>>
>> Binaries:
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-041/
>>
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because
>>
>> Thank you,
>> Gary
>>
>> http://garygregory.wordpress.com/
>> http://garygregory.com/
>> http://people.apache.org/~ggregory/
>> http://twitter.com/GaryGregory
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Oliver Heger <ol...@oliver-heger.de>.
Artifacts and site look good. Maven build works fine on JDK 1.5 and 1.6
under windows 7.
I had a problem with the ant build: ant test gave me compile errors in
some test classes which is probably an encoding issue. I don't think
this is blocking.
So +1.
Oliver
Am 25.03.2011 02:39, schrieb Gary Gregory:
> [VOTE] Release Apache Commons Codec 1.5-RC1
>
> Tag:
>
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
>
> Site:
>
> http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
>
> Binaries:
>
> https://repository.apache.org/content/repositories/orgapachecommons-041/
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because
>
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Mar 28, 2011 at 9:17 PM, sebb <se...@gmail.com> wrote:
> On 29 March 2011 00:49, Gary Gregory <ga...@gmail.com> wrote:
> > I am having a heck of a time pushing the release out.
> >
> > I cannot seem to be able to create the sym links per the instructions in
> > http://wiki.apache.org/commons/UsingNexus
>
> I don't think the symlinks are necessary.
>
> I personally don't like them, because:
> - they easily get out of date
> - they don't work on mirrors (if they appear, they do so as copies, not
> links)
> - they are confusing when they appear in the archive site
>
> But anyway, the links should not be created until the vote has passed
> and the artifacts uploaded.
>
The vote has passed and I am following the step by step instructions from
http://wiki.apache.org/commons/UsingNexus
I'll skip the symlinks.sh step then (for now)
Gary
>
> > I cannot get the symlinks.sh script working. I copied it to my home bin
> > directory. When I invoke it, it is not found. Just running it from my
> home
> > bin w/o args does give me the usage I get:
> >
> >> symlinks.sh
> > symlinks.sh: Command not found.
> >
> >> sh symlinks.sh
> > symlinks.sh: 46: Syntax error: word unexpected
> >
> > I need some UNIX help ;)
>
> Not yet - see above.
>
> > Thank you,
> > Gary
> >
> > On Thu, Mar 24, 2011 at 9:39 PM, Gary Gregory <garydgregory@gmail.com
> >wrote:
> >
> >> [VOTE] Release Apache Commons Codec 1.5-RC1
> >>
> >> Tag:
> >>
> >>
> >>
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
> >>
> >> Site:
> >>
> >> http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
> >>
> >> Binaries:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-041/
> >>
> >> [ ] +1 release it
> >> [ ] +0 go ahead I don't care
> >> [ ] -1 no, do not release it because
> >>
> >> Thank you,
> >> Gary
> >>
> >> http://garygregory.wordpress.com/
> >> http://garygregory.com/
> >> http://people.apache.org/~ggregory/
> >> http://twitter.com/GaryGregory
> >>
> >
> >
> >
> > --
> > Thank you,
> > Gary
> >
> > http://garygregory.wordpress.com/
> > http://garygregory.com/
> > http://people.apache.org/~ggregory/
> > http://twitter.com/GaryGregory
> >
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by sebb <se...@gmail.com>.
On 29 March 2011 00:49, Gary Gregory <ga...@gmail.com> wrote:
> I am having a heck of a time pushing the release out.
>
> I cannot seem to be able to create the sym links per the instructions in
> http://wiki.apache.org/commons/UsingNexus
I don't think the symlinks are necessary.
I personally don't like them, because:
- they easily get out of date
- they don't work on mirrors (if they appear, they do so as copies, not links)
- they are confusing when they appear in the archive site
But anyway, the links should not be created until the vote has passed
and the artifacts uploaded.
> I cannot get the symlinks.sh script working. I copied it to my home bin
> directory. When I invoke it, it is not found. Just running it from my home
> bin w/o args does give me the usage I get:
>
>> symlinks.sh
> symlinks.sh: Command not found.
>
>> sh symlinks.sh
> symlinks.sh: 46: Syntax error: word unexpected
>
> I need some UNIX help ;)
Not yet - see above.
> Thank you,
> Gary
>
> On Thu, Mar 24, 2011 at 9:39 PM, Gary Gregory <ga...@gmail.com>wrote:
>
>> [VOTE] Release Apache Commons Codec 1.5-RC1
>>
>> Tag:
>>
>>
>> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
>>
>> Site:
>>
>> http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
>>
>> Binaries:
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-041/
>>
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because
>>
>> Thank you,
>> Gary
>>
>> http://garygregory.wordpress.com/
>> http://garygregory.com/
>> http://people.apache.org/~ggregory/
>> http://twitter.com/GaryGregory
>>
>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Tue, Apr 5, 2011 at 10:22 AM, Henri Yandell <fl...@gmail.com> wrote:
> Very late, but I've been a tad busy in the new-parent department.
You didn't publish a POM yet, did you? ;-)
> What I do care about is releasing often. Which is farcical given how
> few times I've released. I want to release every month. Every week if
> possible. With minimal effort as I don't have the time to waste
> building releases for code that is fine enough.
I wouldn't want to do that without Maven and the release-plugin
anymore. At work, we've got a project where we do exactly that. And a
release includes publication to Nexus, a web site and a lot of other
stuff, everything with relatively generic pom's. Compared to the
almost unmaintainable Ant scripts with their thousands of lines that
we used in the past, it is a lot better.
In the special case of Apache, there are unfortunately some minor
glitches. One is caused by the fact that we europeans are redirected
to the european SVN mirror, rather than the original in the US. There
is a workaround and I tend to forget it all the time. (I also do
Apache releases rarely.) Another problem is the use of https URL's,
although that should be handled in the parent POM nowadays, for both
Maven 2 and 3.
> [Side note; this is insane:
> http://maven.apache.org/guides/mini/guide-encryption.html - I vomit
> every time it's implied I should put passwords in the Maven settings
> file]
Totally agreed!
Jochen
--
I Am What I Am And That's All What I Yam (Popeye)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Henri Yandell <fl...@gmail.com>.
Very late, but I've been a tad busy in the new-parent department.
Generally I agree with Phil's email. I don't really care though - I
recognize that my main pain with Nexus is a) the experience to know
not to trust magical systems & b) not being full of energy to follow
yet another build system change. I'm sure Maven 3.0 will be coming and
I'll have to find the time to look into that.
I've a bunch of JIRA plugins that are basically dead now because
Atlassian moved to OpenSocial and I don't have the time/interest to
read up on OpenSocial. This is the same - major shifts are costly and
I'm now in the 'can't keep up'. My time is worth more to me than the
novelty of the features :) Sucks to be me.
What I do care about is releasing often. Which is farcical given how
few times I've released. I want to release every month. Every week if
possible. With minimal effort as I don't have the time to waste
building releases for code that is fine enough. If that means pressing
some magic button and Nexus takes care of things; fine. I'm loathe to
read the 7 pages of "How to Release updated for Nexus", but I
recognize that a lot of that is my own lacking. That said 97% of it is
boring as it's really How to Release [the Nexus version] and not the
10 line page that its title implies it should be).
[Side note; this is insane:
http://maven.apache.org/guides/mini/guide-encryption.html - I vomit
every time it's implied I should put passwords in the Maven settings
file]
End of opinion :)
Hen
On Tue, Mar 29, 2011 at 7:50 AM, Phil Steitz <ph...@gmail.com> wrote:
> After another nightmare by an RM who has not cut a release in a
> while, I think we need to do something. The documentation on the
> Commons web pages describes a process that works. I suggest that we
> standardize on that process, adding some simple automation scripts
> that RMs can choose to use or not to use for the manual steps and
> stop fussing with Nexus or the maven release plugin. I cut an RC
> last night in 25 minutes (about 15 of which were spent waiting for
> the [pool] tests to complete) and will likely spend about that same
> amount of time deploying the artifacts to dist/ and what remains of
> our simple, file-and-directory-based replication infrastructure to
> get maven artifacts pushed to the maven repos. I do use a simple
> shell script to manage invoking the maven commands and copying files
> around to reduce the required time from, say an hour, to 25
> minutes. The script is in svn.
>
> I prefer the "manual" approach for the following reasons:
>
> 1. I know what it does. Exactly, every time. I know that exactly
> the binaries that we vote on get deployed to dist/ and exactly the
> committed tag is used to build everything. The process includes
> local generation of artifacts that I can inspect and test locally
> and verify sigs. I know at each step exactly what is being pushed
> where.
>
> 2. I know that it works. Every time. No pom-tweaking,
> plugin-munging or other half-success management required.
>
> 3. It has no commercial / proprietary dependencies. The scripts
> are optional and are in any case, ASF-licensed, committed to svn.
>
> I know others have different opinions on this. It could be we need
> to support both ways of cutting releases. I would ask, however,
> that those arguing for the "automagical" approach take a hard look
> at how many volunteer hours are being spent trying to get
> maven/nexus to be a release manager and how comparatively little
> time those of us who take the "manual" approach spend getting our
> releases built and deployed. While I certainly can't claim to
> produce perfect artifacts (much less code :), I will also point out
> that the only major release quality problem that we have had
> recently was the inadvertent release of a [net] version while
> fiddling with the release plugin. I don't at all buy the argument
> that the manual approach is "error-prone" as it allows more and
> better opportunities for inspection by the RM and community at each
> stage.
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Niall Pemberton <ni...@gmail.com>.
On Tue, Mar 29, 2011 at 10:23 PM, sebb <se...@gmail.com> wrote:
> On 29 March 2011 20:56, Niall Pemberton <ni...@gmail.com> wrote:
>> On Tue, Mar 29, 2011 at 8:08 PM, sebb <se...@gmail.com> wrote:
>>> On 29 March 2011 18:33, Niall Pemberton <ni...@gmail.com> wrote:
>>>> On Tue, Mar 29, 2011 at 5:18 PM, sebb <se...@gmail.com> wrote:
>>>>> On 29 March 2011 16:52, Phil Steitz <ph...@gmail.com> wrote:
>>>>>> On 3/29/11 8:33 AM, sebb wrote:
>>>>>>> On 29 March 2011 16:20, Matt Benson <gu...@gmail.com> wrote:
>>>>>>>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>>>>>>> After another nightmare by an RM who has not cut a release in a
>>>>>>>>>>> while, I think we need to do something. The documentation on the
>>>>>>>>>>> Commons web pages describes a process that works. I suggest that we
>>>>>>>>>>> standardize on that process, adding some simple automation scripts
>>>>>>>>>>> that RMs can choose to use or not to use for the manual steps and
>>>>>>>>>>> stop fussing with Nexus or the maven release plugin. I cut an RC
>>>>>>>>> We need to keep Nexus, but I agree about the release plugin - see below.
>>>>>>>>>
>>>>>>>>>>> last night in 25 minutes (about 15 of which were spent waiting for
>>>>>>>>>>> the [pool] tests to complete) and will likely spend about that same
>>>>>>>>>>> amount of time deploying the artifacts to dist/ and what remains of
>>>>>>>>>>> our simple, file-and-directory-based replication infrastructure to
>>>>>>>>>>> get maven artifacts pushed to the maven repos. I do use a simple
>>>>>>>>>>> shell script to manage invoking the maven commands and copying files
>>>>>>>>>>> around to reduce the required time from, say an hour, to 25
>>>>>>>>>>> minutes. The script is in svn.
>>>>>>>>>>>
>>>>>>>>>>> I prefer the "manual" approach for the following reasons:
>>>>>>>>>>>
>>>>>>>>>>> 1. I know what it does. Exactly, every time. I know that exactly
>>>>>>>>>>> the binaries that we vote on get deployed to dist/ and exactly the
>>>>>>>>>>> committed tag is used to build everything. The process includes
>>>>>>>>>>> local generation of artifacts that I can inspect and test locally
>>>>>>>>>>> and verify sigs. I know at each step exactly what is being pushed
>>>>>>>>>>> where.
>>>>>>>>>>>
>>>>>>>>>>> 2. I know that it works. Every time. No pom-tweaking,
>>>>>>>>>>> plugin-munging or other half-success management required.
>>>>>>>>>>>
>>>>>>>>>>> 3. It has no commercial / proprietary dependencies. The scripts
>>>>>>>>>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>>>>>>>>>
>>>>>>>>>>> I know others have different opinions on this. It could be we need
>>>>>>>>>>> to support both ways of cutting releases.
>>>>>>>>>> AIUI then the deployment to the maven repository is either by dropping
>>>>>>>>>> the artifacts manually in
>>>>>>>>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>>>>>>>>>> Nexus. I think once a component switches to Nexus, then the manual
>>>>>>>>>> process doesn't work.
>>>>>>>>> Yes, that is true.
>>>>>>>>>
>>>>>>>>> Also, had the [net] release been using Nexus, it would have required 2
>>>>>>>>> additional manual stages to close and then release the Maven
>>>>>>>>> artifacts.
>>>>>>>>> It is impossible to accidentally release Maven artifacts using Maven
>>>>>>>>> command-line when using a staging manager such as Nexus.
>>>>>>>>>
>>>>>>>>> But I agree that using manual processes up to that point is better
>>>>>>>>> than trying to use the Maven release plugin.
>>>>>>>> My assumption is that the Nexus stuff is supposed to work and make
>>>>>>>> life easier. If it doesn't, I suppose we shouldn't use it. Is it a
>>>>>>>> training issue, such that none of us simply knows exactly what it is
>>>>>>>> we ought to expect the process to do, and how it will do it? This
>>>>>>>> type of thing is my chief complaint about Maven in general: it's hard
>>>>>>>> to understand what's going on once you get a level or two of parent
>>>>>>>> POMs in there. If it's just a matter of "we haven't discovered the
>>>>>>>> precise incantations that make the release plugin + Nexus instance do
>>>>>>>> what we mean with no fuss," perhaps we could cajole Brian Fox into
>>>>>>>> walking one of us (who solemnly vows to document the entire experience
>>>>>>>> in full detail) through the entire lifecycle.
>>>>>>> Nexus is effectively a proxy, and has little bearing on how Maven
>>>>>>> deploy or release work.
>>>>>>> The artifacts end up in Nexus rather than in a directory that is
>>>>>>> auto-synched to Maven Central.
>>>>>>>
>>>>>>> This makes it easy to review the actual artifacts that will be
>>>>>>> deployed, as well as ensuring that artifacts cannot be accidentally
>>>>>>> deployed.
>>>>>
>>>>> Sorry, I was referring to the Maven artifacts, which is what went
>>>>> wrong with Net.
>>>>>
>>>>>> I disagree with this. The most important artifacts are the
>>>>>> zips/tars that go to dist/. These *are* the ASF release. Nexus
>>>>>> makes it *harder* IMO to maintain provenance of these artifacts.
>>>>>
>>>>> AIUI the ASF release is the *source*, which is normally also released to Maven.
>>>>
>>>> IMO I don't quite agree with what either you or Phil said. The release
>>>> is whatever artefacts that we put out there for users to download. ASF
>>>> requires that we do a source release and anything else is a
>>>> convenience - but those other things are part of the release.
>>>
>>> Yes, I agree they are part of what we in Commons consider a release,
>>> but AIUI that is not the strict ASF position.
>>
>> No, thats what the ASF considers
>>
>>> My point was that it was not only the dist/ artifacts that matter.
>>
>> No, all parts matter.
>>
>> See http://www.apache.org/dev/release.html#what
>
> A while ago on a different project I complained that some binary
> packages were not part of the vote, and I was firmly told that it was
> only source that mattered.
We are required to release source and people often say the binaries
are only a "convenience" or that the "real" release is the source.
While those things are true, the mistake is then to say that anything
other than the source is not the release. It seems like a logical step
but its not.
The PMC is responsible for what this project *distributes* to people
as releases. Just because its a *binary* convenience artefact doesn't
mean that it isn't subject to the ASF's release policies. Take the
scenario, for example, where something was included in a binary
artefact that we didn't have the rights to distribute - that is why
those artefacts need to only be distributed as a release with the
approval of the PMC.
> When I re-read the documentation on the ASF site at the time, it did
> appear that such an interpretation was possible.
I don't know about that - but whats there now on the "Releases" page
is very clear and IMO makes that interpretation impossible.
> I may be able to find the e-mail thread, but it will take a while.
I don't think there is any point - why would that hold any weight over
what is on the ASF website, very clearly spelled out:
http://www.apache.org/dev/release.html
Niall
> I'm not saying that I think binary artifacts should not be included in
> release votes - just the opposite - but I was told otherwise.
>
>> Niall
>>
>>>>
>>>>> We don't have to use Nexus for non-Maven artifacts.
>>>>>
>>>>> IIRC, previously there was little or no visibility of what Maven
>>>>> artifacts would be released, and they were not always voted on.
>>>>
>>>> Rubbish. You make it sound like we only started checking maven
>>>> artifacts since Nexus.
>>>
>>> That was not my intention.
>>>
>>> I thought I had seen several votes where the Maven artifacts that were
>>> eventually released were not the exact ones voted on, because the
>>> release process that was used forced the RM to rebuild the jars in
>>> order to deploy them.
>>>
>>> But maybe I'm thinking of a different project.
>>>
>>> ==
>>>
>>> Nexus makes it easier to release Maven artifacts, as there is no need
>>> to mess with the maven-metadata.xml file [1]
>>>
>>> [1] http://commons.apache.org/releases/release.html#a3_Deploy_Maven_Artifacts
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by sebb <se...@gmail.com>.
On 29 March 2011 20:56, Niall Pemberton <ni...@gmail.com> wrote:
> On Tue, Mar 29, 2011 at 8:08 PM, sebb <se...@gmail.com> wrote:
>> On 29 March 2011 18:33, Niall Pemberton <ni...@gmail.com> wrote:
>>> On Tue, Mar 29, 2011 at 5:18 PM, sebb <se...@gmail.com> wrote:
>>>> On 29 March 2011 16:52, Phil Steitz <ph...@gmail.com> wrote:
>>>>> On 3/29/11 8:33 AM, sebb wrote:
>>>>>> On 29 March 2011 16:20, Matt Benson <gu...@gmail.com> wrote:
>>>>>>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
>>>>>>>> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>>>>>> After another nightmare by an RM who has not cut a release in a
>>>>>>>>>> while, I think we need to do something. The documentation on the
>>>>>>>>>> Commons web pages describes a process that works. I suggest that we
>>>>>>>>>> standardize on that process, adding some simple automation scripts
>>>>>>>>>> that RMs can choose to use or not to use for the manual steps and
>>>>>>>>>> stop fussing with Nexus or the maven release plugin. I cut an RC
>>>>>>>> We need to keep Nexus, but I agree about the release plugin - see below.
>>>>>>>>
>>>>>>>>>> last night in 25 minutes (about 15 of which were spent waiting for
>>>>>>>>>> the [pool] tests to complete) and will likely spend about that same
>>>>>>>>>> amount of time deploying the artifacts to dist/ and what remains of
>>>>>>>>>> our simple, file-and-directory-based replication infrastructure to
>>>>>>>>>> get maven artifacts pushed to the maven repos. I do use a simple
>>>>>>>>>> shell script to manage invoking the maven commands and copying files
>>>>>>>>>> around to reduce the required time from, say an hour, to 25
>>>>>>>>>> minutes. The script is in svn.
>>>>>>>>>>
>>>>>>>>>> I prefer the "manual" approach for the following reasons:
>>>>>>>>>>
>>>>>>>>>> 1. I know what it does. Exactly, every time. I know that exactly
>>>>>>>>>> the binaries that we vote on get deployed to dist/ and exactly the
>>>>>>>>>> committed tag is used to build everything. The process includes
>>>>>>>>>> local generation of artifacts that I can inspect and test locally
>>>>>>>>>> and verify sigs. I know at each step exactly what is being pushed
>>>>>>>>>> where.
>>>>>>>>>>
>>>>>>>>>> 2. I know that it works. Every time. No pom-tweaking,
>>>>>>>>>> plugin-munging or other half-success management required.
>>>>>>>>>>
>>>>>>>>>> 3. It has no commercial / proprietary dependencies. The scripts
>>>>>>>>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>>>>>>>>
>>>>>>>>>> I know others have different opinions on this. It could be we need
>>>>>>>>>> to support both ways of cutting releases.
>>>>>>>>> AIUI then the deployment to the maven repository is either by dropping
>>>>>>>>> the artifacts manually in
>>>>>>>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>>>>>>>>> Nexus. I think once a component switches to Nexus, then the manual
>>>>>>>>> process doesn't work.
>>>>>>>> Yes, that is true.
>>>>>>>>
>>>>>>>> Also, had the [net] release been using Nexus, it would have required 2
>>>>>>>> additional manual stages to close and then release the Maven
>>>>>>>> artifacts.
>>>>>>>> It is impossible to accidentally release Maven artifacts using Maven
>>>>>>>> command-line when using a staging manager such as Nexus.
>>>>>>>>
>>>>>>>> But I agree that using manual processes up to that point is better
>>>>>>>> than trying to use the Maven release plugin.
>>>>>>> My assumption is that the Nexus stuff is supposed to work and make
>>>>>>> life easier. If it doesn't, I suppose we shouldn't use it. Is it a
>>>>>>> training issue, such that none of us simply knows exactly what it is
>>>>>>> we ought to expect the process to do, and how it will do it? This
>>>>>>> type of thing is my chief complaint about Maven in general: it's hard
>>>>>>> to understand what's going on once you get a level or two of parent
>>>>>>> POMs in there. If it's just a matter of "we haven't discovered the
>>>>>>> precise incantations that make the release plugin + Nexus instance do
>>>>>>> what we mean with no fuss," perhaps we could cajole Brian Fox into
>>>>>>> walking one of us (who solemnly vows to document the entire experience
>>>>>>> in full detail) through the entire lifecycle.
>>>>>> Nexus is effectively a proxy, and has little bearing on how Maven
>>>>>> deploy or release work.
>>>>>> The artifacts end up in Nexus rather than in a directory that is
>>>>>> auto-synched to Maven Central.
>>>>>>
>>>>>> This makes it easy to review the actual artifacts that will be
>>>>>> deployed, as well as ensuring that artifacts cannot be accidentally
>>>>>> deployed.
>>>>
>>>> Sorry, I was referring to the Maven artifacts, which is what went
>>>> wrong with Net.
>>>>
>>>>> I disagree with this. The most important artifacts are the
>>>>> zips/tars that go to dist/. These *are* the ASF release. Nexus
>>>>> makes it *harder* IMO to maintain provenance of these artifacts.
>>>>
>>>> AIUI the ASF release is the *source*, which is normally also released to Maven.
>>>
>>> IMO I don't quite agree with what either you or Phil said. The release
>>> is whatever artefacts that we put out there for users to download. ASF
>>> requires that we do a source release and anything else is a
>>> convenience - but those other things are part of the release.
>>
>> Yes, I agree they are part of what we in Commons consider a release,
>> but AIUI that is not the strict ASF position.
>
> No, thats what the ASF considers
>
>> My point was that it was not only the dist/ artifacts that matter.
>
> No, all parts matter.
>
> See http://www.apache.org/dev/release.html#what
A while ago on a different project I complained that some binary
packages were not part of the vote, and I was firmly told that it was
only source that mattered.
When I re-read the documentation on the ASF site at the time, it did
appear that such an interpretation was possible.
I may be able to find the e-mail thread, but it will take a while.
I'm not saying that I think binary artifacts should not be included in
release votes - just the opposite - but I was told otherwise.
> Niall
>
>>>
>>>> We don't have to use Nexus for non-Maven artifacts.
>>>>
>>>> IIRC, previously there was little or no visibility of what Maven
>>>> artifacts would be released, and they were not always voted on.
>>>
>>> Rubbish. You make it sound like we only started checking maven
>>> artifacts since Nexus.
>>
>> That was not my intention.
>>
>> I thought I had seen several votes where the Maven artifacts that were
>> eventually released were not the exact ones voted on, because the
>> release process that was used forced the RM to rebuild the jars in
>> order to deploy them.
>>
>> But maybe I'm thinking of a different project.
>>
>> ==
>>
>> Nexus makes it easier to release Maven artifacts, as there is no need
>> to mess with the maven-metadata.xml file [1]
>>
>> [1] http://commons.apache.org/releases/release.html#a3_Deploy_Maven_Artifacts
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Niall Pemberton <ni...@gmail.com>.
On Tue, Mar 29, 2011 at 8:08 PM, sebb <se...@gmail.com> wrote:
> On 29 March 2011 18:33, Niall Pemberton <ni...@gmail.com> wrote:
>> On Tue, Mar 29, 2011 at 5:18 PM, sebb <se...@gmail.com> wrote:
>>> On 29 March 2011 16:52, Phil Steitz <ph...@gmail.com> wrote:
>>>> On 3/29/11 8:33 AM, sebb wrote:
>>>>> On 29 March 2011 16:20, Matt Benson <gu...@gmail.com> wrote:
>>>>>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
>>>>>>> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>>>>> After another nightmare by an RM who has not cut a release in a
>>>>>>>>> while, I think we need to do something. The documentation on the
>>>>>>>>> Commons web pages describes a process that works. I suggest that we
>>>>>>>>> standardize on that process, adding some simple automation scripts
>>>>>>>>> that RMs can choose to use or not to use for the manual steps and
>>>>>>>>> stop fussing with Nexus or the maven release plugin. I cut an RC
>>>>>>> We need to keep Nexus, but I agree about the release plugin - see below.
>>>>>>>
>>>>>>>>> last night in 25 minutes (about 15 of which were spent waiting for
>>>>>>>>> the [pool] tests to complete) and will likely spend about that same
>>>>>>>>> amount of time deploying the artifacts to dist/ and what remains of
>>>>>>>>> our simple, file-and-directory-based replication infrastructure to
>>>>>>>>> get maven artifacts pushed to the maven repos. I do use a simple
>>>>>>>>> shell script to manage invoking the maven commands and copying files
>>>>>>>>> around to reduce the required time from, say an hour, to 25
>>>>>>>>> minutes. The script is in svn.
>>>>>>>>>
>>>>>>>>> I prefer the "manual" approach for the following reasons:
>>>>>>>>>
>>>>>>>>> 1. I know what it does. Exactly, every time. I know that exactly
>>>>>>>>> the binaries that we vote on get deployed to dist/ and exactly the
>>>>>>>>> committed tag is used to build everything. The process includes
>>>>>>>>> local generation of artifacts that I can inspect and test locally
>>>>>>>>> and verify sigs. I know at each step exactly what is being pushed
>>>>>>>>> where.
>>>>>>>>>
>>>>>>>>> 2. I know that it works. Every time. No pom-tweaking,
>>>>>>>>> plugin-munging or other half-success management required.
>>>>>>>>>
>>>>>>>>> 3. It has no commercial / proprietary dependencies. The scripts
>>>>>>>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>>>>>>>
>>>>>>>>> I know others have different opinions on this. It could be we need
>>>>>>>>> to support both ways of cutting releases.
>>>>>>>> AIUI then the deployment to the maven repository is either by dropping
>>>>>>>> the artifacts manually in
>>>>>>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>>>>>>>> Nexus. I think once a component switches to Nexus, then the manual
>>>>>>>> process doesn't work.
>>>>>>> Yes, that is true.
>>>>>>>
>>>>>>> Also, had the [net] release been using Nexus, it would have required 2
>>>>>>> additional manual stages to close and then release the Maven
>>>>>>> artifacts.
>>>>>>> It is impossible to accidentally release Maven artifacts using Maven
>>>>>>> command-line when using a staging manager such as Nexus.
>>>>>>>
>>>>>>> But I agree that using manual processes up to that point is better
>>>>>>> than trying to use the Maven release plugin.
>>>>>> My assumption is that the Nexus stuff is supposed to work and make
>>>>>> life easier. If it doesn't, I suppose we shouldn't use it. Is it a
>>>>>> training issue, such that none of us simply knows exactly what it is
>>>>>> we ought to expect the process to do, and how it will do it? This
>>>>>> type of thing is my chief complaint about Maven in general: it's hard
>>>>>> to understand what's going on once you get a level or two of parent
>>>>>> POMs in there. If it's just a matter of "we haven't discovered the
>>>>>> precise incantations that make the release plugin + Nexus instance do
>>>>>> what we mean with no fuss," perhaps we could cajole Brian Fox into
>>>>>> walking one of us (who solemnly vows to document the entire experience
>>>>>> in full detail) through the entire lifecycle.
>>>>> Nexus is effectively a proxy, and has little bearing on how Maven
>>>>> deploy or release work.
>>>>> The artifacts end up in Nexus rather than in a directory that is
>>>>> auto-synched to Maven Central.
>>>>>
>>>>> This makes it easy to review the actual artifacts that will be
>>>>> deployed, as well as ensuring that artifacts cannot be accidentally
>>>>> deployed.
>>>
>>> Sorry, I was referring to the Maven artifacts, which is what went
>>> wrong with Net.
>>>
>>>> I disagree with this. The most important artifacts are the
>>>> zips/tars that go to dist/. These *are* the ASF release. Nexus
>>>> makes it *harder* IMO to maintain provenance of these artifacts.
>>>
>>> AIUI the ASF release is the *source*, which is normally also released to Maven.
>>
>> IMO I don't quite agree with what either you or Phil said. The release
>> is whatever artefacts that we put out there for users to download. ASF
>> requires that we do a source release and anything else is a
>> convenience - but those other things are part of the release.
>
> Yes, I agree they are part of what we in Commons consider a release,
> but AIUI that is not the strict ASF position.
No, thats what the ASF considers
> My point was that it was not only the dist/ artifacts that matter.
No, all parts matter.
See http://www.apache.org/dev/release.html#what
Niall
>>
>>> We don't have to use Nexus for non-Maven artifacts.
>>>
>>> IIRC, previously there was little or no visibility of what Maven
>>> artifacts would be released, and they were not always voted on.
>>
>> Rubbish. You make it sound like we only started checking maven
>> artifacts since Nexus.
>
> That was not my intention.
>
> I thought I had seen several votes where the Maven artifacts that were
> eventually released were not the exact ones voted on, because the
> release process that was used forced the RM to rebuild the jars in
> order to deploy them.
>
> But maybe I'm thinking of a different project.
>
> ==
>
> Nexus makes it easier to release Maven artifacts, as there is no need
> to mess with the maven-metadata.xml file [1]
>
> [1] http://commons.apache.org/releases/release.html#a3_Deploy_Maven_Artifacts
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by sebb <se...@gmail.com>.
On 29 March 2011 18:33, Niall Pemberton <ni...@gmail.com> wrote:
> On Tue, Mar 29, 2011 at 5:18 PM, sebb <se...@gmail.com> wrote:
>> On 29 March 2011 16:52, Phil Steitz <ph...@gmail.com> wrote:
>>> On 3/29/11 8:33 AM, sebb wrote:
>>>> On 29 March 2011 16:20, Matt Benson <gu...@gmail.com> wrote:
>>>>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
>>>>>> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>>>> After another nightmare by an RM who has not cut a release in a
>>>>>>>> while, I think we need to do something. The documentation on the
>>>>>>>> Commons web pages describes a process that works. I suggest that we
>>>>>>>> standardize on that process, adding some simple automation scripts
>>>>>>>> that RMs can choose to use or not to use for the manual steps and
>>>>>>>> stop fussing with Nexus or the maven release plugin. I cut an RC
>>>>>> We need to keep Nexus, but I agree about the release plugin - see below.
>>>>>>
>>>>>>>> last night in 25 minutes (about 15 of which were spent waiting for
>>>>>>>> the [pool] tests to complete) and will likely spend about that same
>>>>>>>> amount of time deploying the artifacts to dist/ and what remains of
>>>>>>>> our simple, file-and-directory-based replication infrastructure to
>>>>>>>> get maven artifacts pushed to the maven repos. I do use a simple
>>>>>>>> shell script to manage invoking the maven commands and copying files
>>>>>>>> around to reduce the required time from, say an hour, to 25
>>>>>>>> minutes. The script is in svn.
>>>>>>>>
>>>>>>>> I prefer the "manual" approach for the following reasons:
>>>>>>>>
>>>>>>>> 1. I know what it does. Exactly, every time. I know that exactly
>>>>>>>> the binaries that we vote on get deployed to dist/ and exactly the
>>>>>>>> committed tag is used to build everything. The process includes
>>>>>>>> local generation of artifacts that I can inspect and test locally
>>>>>>>> and verify sigs. I know at each step exactly what is being pushed
>>>>>>>> where.
>>>>>>>>
>>>>>>>> 2. I know that it works. Every time. No pom-tweaking,
>>>>>>>> plugin-munging or other half-success management required.
>>>>>>>>
>>>>>>>> 3. It has no commercial / proprietary dependencies. The scripts
>>>>>>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>>>>>>
>>>>>>>> I know others have different opinions on this. It could be we need
>>>>>>>> to support both ways of cutting releases.
>>>>>>> AIUI then the deployment to the maven repository is either by dropping
>>>>>>> the artifacts manually in
>>>>>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>>>>>>> Nexus. I think once a component switches to Nexus, then the manual
>>>>>>> process doesn't work.
>>>>>> Yes, that is true.
>>>>>>
>>>>>> Also, had the [net] release been using Nexus, it would have required 2
>>>>>> additional manual stages to close and then release the Maven
>>>>>> artifacts.
>>>>>> It is impossible to accidentally release Maven artifacts using Maven
>>>>>> command-line when using a staging manager such as Nexus.
>>>>>>
>>>>>> But I agree that using manual processes up to that point is better
>>>>>> than trying to use the Maven release plugin.
>>>>> My assumption is that the Nexus stuff is supposed to work and make
>>>>> life easier. If it doesn't, I suppose we shouldn't use it. Is it a
>>>>> training issue, such that none of us simply knows exactly what it is
>>>>> we ought to expect the process to do, and how it will do it? This
>>>>> type of thing is my chief complaint about Maven in general: it's hard
>>>>> to understand what's going on once you get a level or two of parent
>>>>> POMs in there. If it's just a matter of "we haven't discovered the
>>>>> precise incantations that make the release plugin + Nexus instance do
>>>>> what we mean with no fuss," perhaps we could cajole Brian Fox into
>>>>> walking one of us (who solemnly vows to document the entire experience
>>>>> in full detail) through the entire lifecycle.
>>>> Nexus is effectively a proxy, and has little bearing on how Maven
>>>> deploy or release work.
>>>> The artifacts end up in Nexus rather than in a directory that is
>>>> auto-synched to Maven Central.
>>>>
>>>> This makes it easy to review the actual artifacts that will be
>>>> deployed, as well as ensuring that artifacts cannot be accidentally
>>>> deployed.
>>
>> Sorry, I was referring to the Maven artifacts, which is what went
>> wrong with Net.
>>
>>> I disagree with this. The most important artifacts are the
>>> zips/tars that go to dist/. These *are* the ASF release. Nexus
>>> makes it *harder* IMO to maintain provenance of these artifacts.
>>
>> AIUI the ASF release is the *source*, which is normally also released to Maven.
>
> IMO I don't quite agree with what either you or Phil said. The release
> is whatever artefacts that we put out there for users to download. ASF
> requires that we do a source release and anything else is a
> convenience - but those other things are part of the release.
Yes, I agree they are part of what we in Commons consider a release,
but AIUI that is not the strict ASF position.
My point was that it was not only the dist/ artifacts that matter.
>
>> We don't have to use Nexus for non-Maven artifacts.
>>
>> IIRC, previously there was little or no visibility of what Maven
>> artifacts would be released, and they were not always voted on.
>
> Rubbish. You make it sound like we only started checking maven
> artifacts since Nexus.
That was not my intention.
I thought I had seen several votes where the Maven artifacts that were
eventually released were not the exact ones voted on, because the
release process that was used forced the RM to rebuild the jars in
order to deploy them.
But maybe I'm thinking of a different project.
==
Nexus makes it easier to release Maven artifacts, as there is no need
to mess with the maven-metadata.xml file [1]
[1] http://commons.apache.org/releases/release.html#a3_Deploy_Maven_Artifacts
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Niall Pemberton <ni...@gmail.com>.
On Tue, Mar 29, 2011 at 5:18 PM, sebb <se...@gmail.com> wrote:
> On 29 March 2011 16:52, Phil Steitz <ph...@gmail.com> wrote:
>> On 3/29/11 8:33 AM, sebb wrote:
>>> On 29 March 2011 16:20, Matt Benson <gu...@gmail.com> wrote:
>>>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
>>>>> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>>> After another nightmare by an RM who has not cut a release in a
>>>>>>> while, I think we need to do something. The documentation on the
>>>>>>> Commons web pages describes a process that works. I suggest that we
>>>>>>> standardize on that process, adding some simple automation scripts
>>>>>>> that RMs can choose to use or not to use for the manual steps and
>>>>>>> stop fussing with Nexus or the maven release plugin. I cut an RC
>>>>> We need to keep Nexus, but I agree about the release plugin - see below.
>>>>>
>>>>>>> last night in 25 minutes (about 15 of which were spent waiting for
>>>>>>> the [pool] tests to complete) and will likely spend about that same
>>>>>>> amount of time deploying the artifacts to dist/ and what remains of
>>>>>>> our simple, file-and-directory-based replication infrastructure to
>>>>>>> get maven artifacts pushed to the maven repos. I do use a simple
>>>>>>> shell script to manage invoking the maven commands and copying files
>>>>>>> around to reduce the required time from, say an hour, to 25
>>>>>>> minutes. The script is in svn.
>>>>>>>
>>>>>>> I prefer the "manual" approach for the following reasons:
>>>>>>>
>>>>>>> 1. I know what it does. Exactly, every time. I know that exactly
>>>>>>> the binaries that we vote on get deployed to dist/ and exactly the
>>>>>>> committed tag is used to build everything. The process includes
>>>>>>> local generation of artifacts that I can inspect and test locally
>>>>>>> and verify sigs. I know at each step exactly what is being pushed
>>>>>>> where.
>>>>>>>
>>>>>>> 2. I know that it works. Every time. No pom-tweaking,
>>>>>>> plugin-munging or other half-success management required.
>>>>>>>
>>>>>>> 3. It has no commercial / proprietary dependencies. The scripts
>>>>>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>>>>>
>>>>>>> I know others have different opinions on this. It could be we need
>>>>>>> to support both ways of cutting releases.
>>>>>> AIUI then the deployment to the maven repository is either by dropping
>>>>>> the artifacts manually in
>>>>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>>>>>> Nexus. I think once a component switches to Nexus, then the manual
>>>>>> process doesn't work.
>>>>> Yes, that is true.
>>>>>
>>>>> Also, had the [net] release been using Nexus, it would have required 2
>>>>> additional manual stages to close and then release the Maven
>>>>> artifacts.
>>>>> It is impossible to accidentally release Maven artifacts using Maven
>>>>> command-line when using a staging manager such as Nexus.
>>>>>
>>>>> But I agree that using manual processes up to that point is better
>>>>> than trying to use the Maven release plugin.
>>>> My assumption is that the Nexus stuff is supposed to work and make
>>>> life easier. If it doesn't, I suppose we shouldn't use it. Is it a
>>>> training issue, such that none of us simply knows exactly what it is
>>>> we ought to expect the process to do, and how it will do it? This
>>>> type of thing is my chief complaint about Maven in general: it's hard
>>>> to understand what's going on once you get a level or two of parent
>>>> POMs in there. If it's just a matter of "we haven't discovered the
>>>> precise incantations that make the release plugin + Nexus instance do
>>>> what we mean with no fuss," perhaps we could cajole Brian Fox into
>>>> walking one of us (who solemnly vows to document the entire experience
>>>> in full detail) through the entire lifecycle.
>>> Nexus is effectively a proxy, and has little bearing on how Maven
>>> deploy or release work.
>>> The artifacts end up in Nexus rather than in a directory that is
>>> auto-synched to Maven Central.
>>>
>>> This makes it easy to review the actual artifacts that will be
>>> deployed, as well as ensuring that artifacts cannot be accidentally
>>> deployed.
>
> Sorry, I was referring to the Maven artifacts, which is what went
> wrong with Net.
>
>> I disagree with this. The most important artifacts are the
>> zips/tars that go to dist/. These *are* the ASF release. Nexus
>> makes it *harder* IMO to maintain provenance of these artifacts.
>
> AIUI the ASF release is the *source*, which is normally also released to Maven.
IMO I don't quite agree with what either you or Phil said. The release
is whatever artefacts that we put out there for users to download. ASF
requires that we do a source release and anything else is a
convenience - but those other things are part of the release.
> We don't have to use Nexus for non-Maven artifacts.
>
> IIRC, previously there was little or no visibility of what Maven
> artifacts would be released, and they were not always voted on.
Rubbish. You make it sound like we only started checking maven
artifacts since Nexus.
Niall
>> I also don't see why we *must* rely on proprietary software to
>> manage replication. We have been replicating actual release
>> artifacts to hundreds - maybe thousands, by now - of Apache mirrors
>> for 10+ years now using rsynch. I don't buy the argument that we
>> need to control access better to ibiblio-rsynch, since the same
>> applies to dist/ which is vastly more important and we trust RMs to
>> manage carefully.
>
> Note that accidental dist releases can easily be removed by us (and
> they will automatically disappear from mirrors).
>
> Removing Maven releases is much harder, and is not in our direct control.
>
> I don't really care whether we use Ant or Maven or whatever.
> However, I do care that any releases are subject to proper voting
> controls, and by that I mean we should vote on all release artifacts.
>
> Nexus seems to me to be a useful part of that process.
> Without it there have been some errors, not only Net, but also
> commons-daemon:commons-daemon:1.0.3 was somehow released with groupId
> org.apache.commons, presumably because it was added to the wrong
> directory on people. There may be other examples.
>
>> Phil
>>> Nexus release process is described here:
>>>
>>> http://www.apache.org/dev/publishing-maven-artifacts.html
>>>
>>>> Matt
>>>>
>>>>>> Niall
>>>>>>
>>>>>>> I would ask, however,
>>>>>>> that those arguing for the "automagical" approach take a hard look
>>>>>>> at how many volunteer hours are being spent trying to get
>>>>>>> maven/nexus to be a release manager and how comparatively little
>>>>>>> time those of us who take the "manual" approach spend getting our
>>>>>>> releases built and deployed. While I certainly can't claim to
>>>>>>> produce perfect artifacts (much less code :), I will also point out
>>>>>>> that the only major release quality problem that we have had
>>>>>>> recently was the inadvertent release of a [net] version while
>>>>>>> fiddling with the release plugin. I don't at all buy the argument
>>>>>>> that the manual approach is "error-prone" as it allows more and
>>>>>>> better opportunities for inspection by the RM and community at each
>>>>>>> stage.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Phil
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by sebb <se...@gmail.com>.
On 29 March 2011 16:52, Phil Steitz <ph...@gmail.com> wrote:
> On 3/29/11 8:33 AM, sebb wrote:
>> On 29 March 2011 16:20, Matt Benson <gu...@gmail.com> wrote:
>>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
>>>> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>> After another nightmare by an RM who has not cut a release in a
>>>>>> while, I think we need to do something. The documentation on the
>>>>>> Commons web pages describes a process that works. I suggest that we
>>>>>> standardize on that process, adding some simple automation scripts
>>>>>> that RMs can choose to use or not to use for the manual steps and
>>>>>> stop fussing with Nexus or the maven release plugin. I cut an RC
>>>> We need to keep Nexus, but I agree about the release plugin - see below.
>>>>
>>>>>> last night in 25 minutes (about 15 of which were spent waiting for
>>>>>> the [pool] tests to complete) and will likely spend about that same
>>>>>> amount of time deploying the artifacts to dist/ and what remains of
>>>>>> our simple, file-and-directory-based replication infrastructure to
>>>>>> get maven artifacts pushed to the maven repos. I do use a simple
>>>>>> shell script to manage invoking the maven commands and copying files
>>>>>> around to reduce the required time from, say an hour, to 25
>>>>>> minutes. The script is in svn.
>>>>>>
>>>>>> I prefer the "manual" approach for the following reasons:
>>>>>>
>>>>>> 1. I know what it does. Exactly, every time. I know that exactly
>>>>>> the binaries that we vote on get deployed to dist/ and exactly the
>>>>>> committed tag is used to build everything. The process includes
>>>>>> local generation of artifacts that I can inspect and test locally
>>>>>> and verify sigs. I know at each step exactly what is being pushed
>>>>>> where.
>>>>>>
>>>>>> 2. I know that it works. Every time. No pom-tweaking,
>>>>>> plugin-munging or other half-success management required.
>>>>>>
>>>>>> 3. It has no commercial / proprietary dependencies. The scripts
>>>>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>>>>
>>>>>> I know others have different opinions on this. It could be we need
>>>>>> to support both ways of cutting releases.
>>>>> AIUI then the deployment to the maven repository is either by dropping
>>>>> the artifacts manually in
>>>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>>>>> Nexus. I think once a component switches to Nexus, then the manual
>>>>> process doesn't work.
>>>> Yes, that is true.
>>>>
>>>> Also, had the [net] release been using Nexus, it would have required 2
>>>> additional manual stages to close and then release the Maven
>>>> artifacts.
>>>> It is impossible to accidentally release Maven artifacts using Maven
>>>> command-line when using a staging manager such as Nexus.
>>>>
>>>> But I agree that using manual processes up to that point is better
>>>> than trying to use the Maven release plugin.
>>> My assumption is that the Nexus stuff is supposed to work and make
>>> life easier. If it doesn't, I suppose we shouldn't use it. Is it a
>>> training issue, such that none of us simply knows exactly what it is
>>> we ought to expect the process to do, and how it will do it? This
>>> type of thing is my chief complaint about Maven in general: it's hard
>>> to understand what's going on once you get a level or two of parent
>>> POMs in there. If it's just a matter of "we haven't discovered the
>>> precise incantations that make the release plugin + Nexus instance do
>>> what we mean with no fuss," perhaps we could cajole Brian Fox into
>>> walking one of us (who solemnly vows to document the entire experience
>>> in full detail) through the entire lifecycle.
>> Nexus is effectively a proxy, and has little bearing on how Maven
>> deploy or release work.
>> The artifacts end up in Nexus rather than in a directory that is
>> auto-synched to Maven Central.
>>
>> This makes it easy to review the actual artifacts that will be
>> deployed, as well as ensuring that artifacts cannot be accidentally
>> deployed.
Sorry, I was referring to the Maven artifacts, which is what went
wrong with Net.
> I disagree with this. The most important artifacts are the
> zips/tars that go to dist/. These *are* the ASF release. Nexus
> makes it *harder* IMO to maintain provenance of these artifacts.
AIUI the ASF release is the *source*, which is normally also released to Maven.
We don't have to use Nexus for non-Maven artifacts.
IIRC, previously there was little or no visibility of what Maven
artifacts would be released, and they were not always voted on.
> I also don't see why we *must* rely on proprietary software to
> manage replication. We have been replicating actual release
> artifacts to hundreds - maybe thousands, by now - of Apache mirrors
> for 10+ years now using rsynch. I don't buy the argument that we
> need to control access better to ibiblio-rsynch, since the same
> applies to dist/ which is vastly more important and we trust RMs to
> manage carefully.
Note that accidental dist releases can easily be removed by us (and
they will automatically disappear from mirrors).
Removing Maven releases is much harder, and is not in our direct control.
I don't really care whether we use Ant or Maven or whatever.
However, I do care that any releases are subject to proper voting
controls, and by that I mean we should vote on all release artifacts.
Nexus seems to me to be a useful part of that process.
Without it there have been some errors, not only Net, but also
commons-daemon:commons-daemon:1.0.3 was somehow released with groupId
org.apache.commons, presumably because it was added to the wrong
directory on people. There may be other examples.
> Phil
>> Nexus release process is described here:
>>
>> http://www.apache.org/dev/publishing-maven-artifacts.html
>>
>>> Matt
>>>
>>>>> Niall
>>>>>
>>>>>> I would ask, however,
>>>>>> that those arguing for the "automagical" approach take a hard look
>>>>>> at how many volunteer hours are being spent trying to get
>>>>>> maven/nexus to be a release manager and how comparatively little
>>>>>> time those of us who take the "manual" approach spend getting our
>>>>>> releases built and deployed. While I certainly can't claim to
>>>>>> produce perfect artifacts (much less code :), I will also point out
>>>>>> that the only major release quality problem that we have had
>>>>>> recently was the inadvertent release of a [net] version while
>>>>>> fiddling with the release plugin. I don't at all buy the argument
>>>>>> that the manual approach is "error-prone" as it allows more and
>>>>>> better opportunities for inspection by the RM and community at each
>>>>>> stage.
>>>>>
>>>>>
>>>>>
>>>>>> Phil
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Thu, Mar 31, 2011 at 5:46 PM, sebb <se...@gmail.com> wrote:
> If they are left in Nexus staging, AFAIK they end up in Maven Central
> when promoted.
And your point is?
--
I Am What I Am And That's All What I Yam (Popeye)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by sebb <se...@gmail.com>.
On 31 March 2011 12:05, Jochen Wiedmann <jo...@gmail.com> wrote:
> On Thu, Mar 31, 2011 at 1:36 AM, sebb <se...@gmail.com> wrote:
>
>> AFAIK, wget alone won't do, as the files also have to be deleted.
>
> Why? There's no problem with leaving them where they are.
If they are left in Nexus staging, AFAIK they end up in Maven Central
when promoted.
>
>> Also, it would be best if that part of the process could be done from
>> the users system, rather than having to login to people.a.o and run
>> commands there.
>>
>> If that could be automated, I would be happy, but would everyone else?
>
> Nothing wrong with that idea, because that area isn't covered by
> either Nexus nor the maven-release-plugin. The work that we spend here
> might even be adopted by other Apache projects. But that wasn't the
> initial point of the discussion, was it?
I thoought the point was to improve the release process.
Since we already use Nexus, I was exploring how the release of dist/
archives could be improved.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Thu, Mar 31, 2011 at 1:36 AM, sebb <se...@gmail.com> wrote:
> AFAIK, wget alone won't do, as the files also have to be deleted.
Why? There's no problem with leaving them where they are.
> Also, it would be best if that part of the process could be done from
> the users system, rather than having to login to people.a.o and run
> commands there.
>
> If that could be automated, I would be happy, but would everyone else?
Nothing wrong with that idea, because that area isn't covered by
either Nexus nor the maven-release-plugin. The work that we spend here
might even be adopted by other Apache projects. But that wasn't the
initial point of the discussion, was it?
--
I Am What I Am And That's All What I Yam (Popeye)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Ralph Goers <ra...@dslextreme.com>.
On Mar 31, 2011, at 8:49 AM, sebb wrote:
> On 31 March 2011 12:08, Jochen Wiedmann <jo...@gmail.com> wrote:
>> On Thu, Mar 31, 2011 at 2:38 AM, Phil Steitz <ph...@gmail.com> wrote:
>>
>>> And then you need to check the hashes and sigs again since you are
>>> now working with downloaded copies of the files that we voted on.
>>> Seems much easier and more correct to me to just scp the files to
>>> p.a.o., let people vote on them and *move* exactly those files to
>>> /dist.
>>
>> You don't get the point of Nexus and the maven-release-plugin, Phil.
>> The point is that these files (hashes and sigs) are already created,
>> ready to use and, indeed, will be simply moved to /dist, just as you
>> are suggesting.
>
> Does the release plugin move the files from the staging directory to /dist then?
>
> Or does it move the RM's copies of the files to /dist?
Although you said you don't like that the Nexus plugin allows manipulating the repo, I could see creating a maven project that does nothing but the required operations to promote the maven artifacts and move the non-maven artifacts to /dist. Of course, a Java program could also be used that invokes the Nexus APIs, etc.
Ralph
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by sebb <se...@gmail.com>.
On 31 March 2011 12:08, Jochen Wiedmann <jo...@gmail.com> wrote:
> On Thu, Mar 31, 2011 at 2:38 AM, Phil Steitz <ph...@gmail.com> wrote:
>
>> And then you need to check the hashes and sigs again since you are
>> now working with downloaded copies of the files that we voted on.
>> Seems much easier and more correct to me to just scp the files to
>> p.a.o., let people vote on them and *move* exactly those files to
>> /dist.
>
> You don't get the point of Nexus and the maven-release-plugin, Phil.
> The point is that these files (hashes and sigs) are already created,
> ready to use and, indeed, will be simply moved to /dist, just as you
> are suggesting.
Does the release plugin move the files from the staging directory to /dist then?
Or does it move the RM's copies of the files to /dist?
>
>> Sorry, I don't buy that. The tars and zips need to "live" in
>> /dist. The maven artifacts need to make their way to the maven
>> mirrors. Having a "staging" repo where we can inspect the maven
>> bits before they get pushed out is great (though I think our homes
>> on p.a.o are fine for this). Why can't we just push files directly
>> there using scp or Ant tasks and then "promote" them to the rsynch
>> repo using a little script including commands like those in step 3
>> of http://commons.apache.org/releases/release.html?
>
> As I said: Your "little script" would simply be duplicating the
> maven-release-plugin. Which is in no way "little".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Thu, Mar 31, 2011 at 2:38 AM, Phil Steitz <ph...@gmail.com> wrote:
> And then you need to check the hashes and sigs again since you are
> now working with downloaded copies of the files that we voted on.
> Seems much easier and more correct to me to just scp the files to
> p.a.o., let people vote on them and *move* exactly those files to
> /dist.
You don't get the point of Nexus and the maven-release-plugin, Phil.
The point is that these files (hashes and sigs) are already created,
ready to use and, indeed, will be simply moved to /dist, just as you
are suggesting.
> Sorry, I don't buy that. The tars and zips need to "live" in
> /dist. The maven artifacts need to make their way to the maven
> mirrors. Having a "staging" repo where we can inspect the maven
> bits before they get pushed out is great (though I think our homes
> on p.a.o are fine for this). Why can't we just push files directly
> there using scp or Ant tasks and then "promote" them to the rsynch
> repo using a little script including commands like those in step 3
> of http://commons.apache.org/releases/release.html?
As I said: Your "little script" would simply be duplicating the
maven-release-plugin. Which is in no way "little".
--
I Am What I Am And That's All What I Yam (Popeye)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by sebb <se...@gmail.com>.
On 31 March 2011 04:00, Phil Steitz <ph...@gmail.com> wrote:
> On 3/30/11 6:57 PM, sebb wrote:
>> On 31 March 2011 01:38, Phil Steitz <ph...@gmail.com> wrote:
>>> On 3/30/11 4:22 PM, Jochen Wiedmann wrote:
>>>> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>
>>>>> I disagree with this. The most important artifacts are the
>>>>> zips/tars that go to dist/. These *are* the ASF release. Nexus
>>>>> makes it *harder* IMO to maintain provenance of these artifacts.
>>>> These artifacts are present in Nexus. Pulling them to a temporary
>>>> directory is quite easy with wget.
>>> And then you need to check the hashes and sigs again since you are
>>> now working with downloaded copies of the files that we voted on.
>> Huh?
>>
>> If we create a script to move the files directly from Nexus staging to
>> dist/, surely there's no chance that the cp+rm will somehow mangle the
>> files?
> mv is no problem. wget via http means you get a copy with the
> network between. That is what I was referring to. In that case,
> just like we tell the users, the RM should check hashes and sigs to
> make sure that what actually ends up in dist/ is identical to what
> we voted on.
I was assuming that we would use scp to copy the files between staging
and dist, not wget.
But if wget can cause problems, I've not seen any, and I use wget to
download all the files when voting.
[I have seen problems with Fx downloads; sometimes it silently truncates files]
>>> Seems much easier and more correct to me to just scp the files to
>>> p.a.o., let people vote on them and *move* exactly those files to
>>> /dist.
>> Which is much what happens with Nexus now, apart from the dist/ move
>> phase which is not yet automated.
>>
> So the nexus staging repo lives on p.a.o? Does not look like it
> from the IPs, unless there is some aliasing going on. If dist/ is
> itself mirrored on r.a.o, then mv is possible; otherwise the files
> have to be copied across the network, rather than moved. That
> requires a recheck of the hashes.
Huh? How do mirrors survive then?
> Phil
>>>> At which point I can see no
>>>> difference between your proposed solution and this one. And there's
>>>> nothing to do for all the other files that live in Nexus (and must
>>>> live, because Maven is just too important, whether we like it or not).
>>> Sorry, I don't buy that. The tars and zips need to "live" in
>>> /dist. The maven artifacts need to make their way to the maven
>>> mirrors. Having a "staging" repo where we can inspect the maven
>>> bits before they get pushed out is great (though I think our homes
>>> on p.a.o are fine for this). Why can't we just push files directly
>>> there using scp or Ant tasks and then "promote" them to the rsynch
>>> repo using a little script including commands like those in step 3
>>> of http://commons.apache.org/releases/release.html?
>>>>> I also don't see why we *must* rely on proprietary software to
>>>>> manage replication.
>>>> I'm mostly with you on that. I strongly opposed choosing Nexus in
>>>> favour of Archiva for that very reason. But we have Nexus now and I
>>>> wouldn't want to have Commons a swimmer against the rest of the Apache
>>>> tide.
>>> Based on Mark's response, I don't think we are the only ones :)
>>>
>>> Phil
>>>> Jochen
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Phil Steitz <ph...@gmail.com>.
On 3/30/11 6:57 PM, sebb wrote:
> On 31 March 2011 01:38, Phil Steitz <ph...@gmail.com> wrote:
>> On 3/30/11 4:22 PM, Jochen Wiedmann wrote:
>>> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>
>>>> I disagree with this. The most important artifacts are the
>>>> zips/tars that go to dist/. These *are* the ASF release. Nexus
>>>> makes it *harder* IMO to maintain provenance of these artifacts.
>>> These artifacts are present in Nexus. Pulling them to a temporary
>>> directory is quite easy with wget.
>> And then you need to check the hashes and sigs again since you are
>> now working with downloaded copies of the files that we voted on.
> Huh?
>
> If we create a script to move the files directly from Nexus staging to
> dist/, surely there's no chance that the cp+rm will somehow mangle the
> files?
mv is no problem. wget via http means you get a copy with the
network between. That is what I was referring to. In that case,
just like we tell the users, the RM should check hashes and sigs to
make sure that what actually ends up in dist/ is identical to what
we voted on.
>> Seems much easier and more correct to me to just scp the files to
>> p.a.o., let people vote on them and *move* exactly those files to
>> /dist.
> Which is much what happens with Nexus now, apart from the dist/ move
> phase which is not yet automated.
>
So the nexus staging repo lives on p.a.o? Does not look like it
from the IPs, unless there is some aliasing going on. If dist/ is
itself mirrored on r.a.o, then mv is possible; otherwise the files
have to be copied across the network, rather than moved. That
requires a recheck of the hashes.
Phil
>>> At which point I can see no
>>> difference between your proposed solution and this one. And there's
>>> nothing to do for all the other files that live in Nexus (and must
>>> live, because Maven is just too important, whether we like it or not).
>> Sorry, I don't buy that. The tars and zips need to "live" in
>> /dist. The maven artifacts need to make their way to the maven
>> mirrors. Having a "staging" repo where we can inspect the maven
>> bits before they get pushed out is great (though I think our homes
>> on p.a.o are fine for this). Why can't we just push files directly
>> there using scp or Ant tasks and then "promote" them to the rsynch
>> repo using a little script including commands like those in step 3
>> of http://commons.apache.org/releases/release.html?
>>>> I also don't see why we *must* rely on proprietary software to
>>>> manage replication.
>>> I'm mostly with you on that. I strongly opposed choosing Nexus in
>>> favour of Archiva for that very reason. But we have Nexus now and I
>>> wouldn't want to have Commons a swimmer against the rest of the Apache
>>> tide.
>> Based on Mark's response, I don't think we are the only ones :)
>>
>> Phil
>>> Jochen
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Phil Steitz <ph...@gmail.com>.
On 3/30/11 7:07 PM, Ralph Goers wrote:
> I'm seeing a lot of complaining on these threads but no actual proposal.
I started the thread with a proposal, which was to standardize on
the process documented on the web site. I know you don't like that
process and I am not going to insist that we force everyone to use
the same process. That is obviously not going to be possible, since
several of us will -1 forcing everyone to use either Nexus or the
maven release plugin.
An improvement of the process on the web site has been suggested,
basically replacing step 3 with an Ant script that pushes maven
artifacts generated by the build automatically. I will get a
prototype for that working when I cut my next release.
Phil
> If the proposal is to move away from Maven/Nexus for a release for all of commons I'll vote -1. OTOH, If some release managers want to do the release some other way I'm not going to force them to use Maven/Nexus.
>
> Ralph
>
>
> On Mar 30, 2011, at 6:57 PM, sebb wrote:
>
>> On 31 March 2011 01:38, Phil Steitz <ph...@gmail.com> wrote:
>>> On 3/30/11 4:22 PM, Jochen Wiedmann wrote:
>>>> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>
>>>>> I disagree with this. The most important artifacts are the
>>>>> zips/tars that go to dist/. These *are* the ASF release. Nexus
>>>>> makes it *harder* IMO to maintain provenance of these artifacts.
>>>> These artifacts are present in Nexus. Pulling them to a temporary
>>>> directory is quite easy with wget.
>>> And then you need to check the hashes and sigs again since you are
>>> now working with downloaded copies of the files that we voted on.
>> Huh?
>>
>> If we create a script to move the files directly from Nexus staging to
>> dist/, surely there's no chance that the cp+rm will somehow mangle the
>> files?
>>
>>> Seems much easier and more correct to me to just scp the files to
>>> p.a.o., let people vote on them and *move* exactly those files to
>>> /dist.
>> Which is much what happens with Nexus now, apart from the dist/ move
>> phase which is not yet automated.
>>
>>>> At which point I can see no
>>>> difference between your proposed solution and this one. And there's
>>>> nothing to do for all the other files that live in Nexus (and must
>>>> live, because Maven is just too important, whether we like it or not).
>>> Sorry, I don't buy that. The tars and zips need to "live" in
>>> /dist. The maven artifacts need to make their way to the maven
>>> mirrors. Having a "staging" repo where we can inspect the maven
>>> bits before they get pushed out is great (though I think our homes
>>> on p.a.o are fine for this). Why can't we just push files directly
>>> there using scp or Ant tasks and then "promote" them to the rsynch
>>> repo using a little script including commands like those in step 3
>>> of http://commons.apache.org/releases/release.html?
>>>>> I also don't see why we *must* rely on proprietary software to
>>>>> manage replication.
>>>> I'm mostly with you on that. I strongly opposed choosing Nexus in
>>>> favour of Archiva for that very reason. But we have Nexus now and I
>>>> wouldn't want to have Commons a swimmer against the rest of the Apache
>>>> tide.
>>> Based on Mark's response, I don't think we are the only ones :)
>>>
>>> Phil
>>>> Jochen
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Ralph Goers <ra...@dslextreme.com>.
I'm seeing a lot of complaining on these threads but no actual proposal. If the proposal is to move away from Maven/Nexus for a release for all of commons I'll vote -1. OTOH, If some release managers want to do the release some other way I'm not going to force them to use Maven/Nexus.
Ralph
On Mar 30, 2011, at 6:57 PM, sebb wrote:
> On 31 March 2011 01:38, Phil Steitz <ph...@gmail.com> wrote:
>> On 3/30/11 4:22 PM, Jochen Wiedmann wrote:
>>> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>
>>>> I disagree with this. The most important artifacts are the
>>>> zips/tars that go to dist/. These *are* the ASF release. Nexus
>>>> makes it *harder* IMO to maintain provenance of these artifacts.
>>> These artifacts are present in Nexus. Pulling them to a temporary
>>> directory is quite easy with wget.
>> And then you need to check the hashes and sigs again since you are
>> now working with downloaded copies of the files that we voted on.
>
> Huh?
>
> If we create a script to move the files directly from Nexus staging to
> dist/, surely there's no chance that the cp+rm will somehow mangle the
> files?
>
>> Seems much easier and more correct to me to just scp the files to
>> p.a.o., let people vote on them and *move* exactly those files to
>> /dist.
>
> Which is much what happens with Nexus now, apart from the dist/ move
> phase which is not yet automated.
>
>>> At which point I can see no
>>> difference between your proposed solution and this one. And there's
>>> nothing to do for all the other files that live in Nexus (and must
>>> live, because Maven is just too important, whether we like it or not).
>> Sorry, I don't buy that. The tars and zips need to "live" in
>> /dist. The maven artifacts need to make their way to the maven
>> mirrors. Having a "staging" repo where we can inspect the maven
>> bits before they get pushed out is great (though I think our homes
>> on p.a.o are fine for this). Why can't we just push files directly
>> there using scp or Ant tasks and then "promote" them to the rsynch
>> repo using a little script including commands like those in step 3
>> of http://commons.apache.org/releases/release.html?
>>>> I also don't see why we *must* rely on proprietary software to
>>>> manage replication.
>>> I'm mostly with you on that. I strongly opposed choosing Nexus in
>>> favour of Archiva for that very reason. But we have Nexus now and I
>>> wouldn't want to have Commons a swimmer against the rest of the Apache
>>> tide.
>> Based on Mark's response, I don't think we are the only ones :)
>>
>> Phil
>>> Jochen
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by sebb <se...@gmail.com>.
On 31 March 2011 01:38, Phil Steitz <ph...@gmail.com> wrote:
> On 3/30/11 4:22 PM, Jochen Wiedmann wrote:
>> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz <ph...@gmail.com> wrote:
>>
>>> I disagree with this. The most important artifacts are the
>>> zips/tars that go to dist/. These *are* the ASF release. Nexus
>>> makes it *harder* IMO to maintain provenance of these artifacts.
>> These artifacts are present in Nexus. Pulling them to a temporary
>> directory is quite easy with wget.
> And then you need to check the hashes and sigs again since you are
> now working with downloaded copies of the files that we voted on.
Huh?
If we create a script to move the files directly from Nexus staging to
dist/, surely there's no chance that the cp+rm will somehow mangle the
files?
> Seems much easier and more correct to me to just scp the files to
> p.a.o., let people vote on them and *move* exactly those files to
> /dist.
Which is much what happens with Nexus now, apart from the dist/ move
phase which is not yet automated.
>> At which point I can see no
>> difference between your proposed solution and this one. And there's
>> nothing to do for all the other files that live in Nexus (and must
>> live, because Maven is just too important, whether we like it or not).
> Sorry, I don't buy that. The tars and zips need to "live" in
> /dist. The maven artifacts need to make their way to the maven
> mirrors. Having a "staging" repo where we can inspect the maven
> bits before they get pushed out is great (though I think our homes
> on p.a.o are fine for this). Why can't we just push files directly
> there using scp or Ant tasks and then "promote" them to the rsynch
> repo using a little script including commands like those in step 3
> of http://commons.apache.org/releases/release.html?
>>> I also don't see why we *must* rely on proprietary software to
>>> manage replication.
>> I'm mostly with you on that. I strongly opposed choosing Nexus in
>> favour of Archiva for that very reason. But we have Nexus now and I
>> wouldn't want to have Commons a swimmer against the rest of the Apache
>> tide.
> Based on Mark's response, I don't think we are the only ones :)
>
> Phil
>> Jochen
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by sebb <se...@gmail.com>.
On 31 March 2011 00:22, Jochen Wiedmann <jo...@gmail.com> wrote:
> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> I disagree with this. The most important artifacts are the
>> zips/tars that go to dist/. These *are* the ASF release. Nexus
>> makes it *harder* IMO to maintain provenance of these artifacts.
>
> These artifacts are present in Nexus. Pulling them to a temporary
> directory is quite easy with wget. At which point I can see no
> difference between your proposed solution and this one. And there's
> nothing to do for all the other files that live in Nexus (and must
> live, because Maven is just too important, whether we like it or not).
IMO, moving the non-Maven files out of Nexus is the main irritation
with the way it works at present.
AFAIK, wget alone won't do, as the files also have to be deleted.
Also, it would be best if that part of the process could be done from
the users system, rather than having to login to people.a.o and run
commands there.
If that could be automated, I would be happy, but would everyone else?
>
>> I also don't see why we *must* rely on proprietary software to
>> manage replication.
>
> I'm mostly with you on that. I strongly opposed choosing Nexus in
> favour of Archiva for that very reason. But we have Nexus now and I
> wouldn't want to have Commons a swimmer against the rest of the Apache
> tide.
AIUI Archive does not currently support staging.
> Jochen
>
>
> --
> I Am What I Am And That's All What I Yam (Popeye)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Phil Steitz <ph...@gmail.com>.
On 3/30/11 4:22 PM, Jochen Wiedmann wrote:
> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> I disagree with this. The most important artifacts are the
>> zips/tars that go to dist/. These *are* the ASF release. Nexus
>> makes it *harder* IMO to maintain provenance of these artifacts.
> These artifacts are present in Nexus. Pulling them to a temporary
> directory is quite easy with wget.
And then you need to check the hashes and sigs again since you are
now working with downloaded copies of the files that we voted on.
Seems much easier and more correct to me to just scp the files to
p.a.o., let people vote on them and *move* exactly those files to
/dist.
> At which point I can see no
> difference between your proposed solution and this one. And there's
> nothing to do for all the other files that live in Nexus (and must
> live, because Maven is just too important, whether we like it or not).
Sorry, I don't buy that. The tars and zips need to "live" in
/dist. The maven artifacts need to make their way to the maven
mirrors. Having a "staging" repo where we can inspect the maven
bits before they get pushed out is great (though I think our homes
on p.a.o are fine for this). Why can't we just push files directly
there using scp or Ant tasks and then "promote" them to the rsynch
repo using a little script including commands like those in step 3
of http://commons.apache.org/releases/release.html?
>> I also don't see why we *must* rely on proprietary software to
>> manage replication.
> I'm mostly with you on that. I strongly opposed choosing Nexus in
> favour of Archiva for that very reason. But we have Nexus now and I
> wouldn't want to have Commons a swimmer against the rest of the Apache
> tide.
Based on Mark's response, I don't think we are the only ones :)
Phil
> Jochen
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Phil Steitz <ph...@gmail.com>.
On 3/29/11 8:33 AM, sebb wrote:
> On 29 March 2011 16:20, Matt Benson <gu...@gmail.com> wrote:
>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
>>> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>> After another nightmare by an RM who has not cut a release in a
>>>>> while, I think we need to do something. The documentation on the
>>>>> Commons web pages describes a process that works. I suggest that we
>>>>> standardize on that process, adding some simple automation scripts
>>>>> that RMs can choose to use or not to use for the manual steps and
>>>>> stop fussing with Nexus or the maven release plugin. I cut an RC
>>> We need to keep Nexus, but I agree about the release plugin - see below.
>>>
>>>>> last night in 25 minutes (about 15 of which were spent waiting for
>>>>> the [pool] tests to complete) and will likely spend about that same
>>>>> amount of time deploying the artifacts to dist/ and what remains of
>>>>> our simple, file-and-directory-based replication infrastructure to
>>>>> get maven artifacts pushed to the maven repos. I do use a simple
>>>>> shell script to manage invoking the maven commands and copying files
>>>>> around to reduce the required time from, say an hour, to 25
>>>>> minutes. The script is in svn.
>>>>>
>>>>> I prefer the "manual" approach for the following reasons:
>>>>>
>>>>> 1. I know what it does. Exactly, every time. I know that exactly
>>>>> the binaries that we vote on get deployed to dist/ and exactly the
>>>>> committed tag is used to build everything. The process includes
>>>>> local generation of artifacts that I can inspect and test locally
>>>>> and verify sigs. I know at each step exactly what is being pushed
>>>>> where.
>>>>>
>>>>> 2. I know that it works. Every time. No pom-tweaking,
>>>>> plugin-munging or other half-success management required.
>>>>>
>>>>> 3. It has no commercial / proprietary dependencies. The scripts
>>>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>>>
>>>>> I know others have different opinions on this. It could be we need
>>>>> to support both ways of cutting releases.
>>>> AIUI then the deployment to the maven repository is either by dropping
>>>> the artifacts manually in
>>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>>>> Nexus. I think once a component switches to Nexus, then the manual
>>>> process doesn't work.
>>> Yes, that is true.
>>>
>>> Also, had the [net] release been using Nexus, it would have required 2
>>> additional manual stages to close and then release the Maven
>>> artifacts.
>>> It is impossible to accidentally release Maven artifacts using Maven
>>> command-line when using a staging manager such as Nexus.
>>>
>>> But I agree that using manual processes up to that point is better
>>> than trying to use the Maven release plugin.
>> My assumption is that the Nexus stuff is supposed to work and make
>> life easier. If it doesn't, I suppose we shouldn't use it. Is it a
>> training issue, such that none of us simply knows exactly what it is
>> we ought to expect the process to do, and how it will do it? This
>> type of thing is my chief complaint about Maven in general: it's hard
>> to understand what's going on once you get a level or two of parent
>> POMs in there. If it's just a matter of "we haven't discovered the
>> precise incantations that make the release plugin + Nexus instance do
>> what we mean with no fuss," perhaps we could cajole Brian Fox into
>> walking one of us (who solemnly vows to document the entire experience
>> in full detail) through the entire lifecycle.
> Nexus is effectively a proxy, and has little bearing on how Maven
> deploy or release work.
> The artifacts end up in Nexus rather than in a directory that is
> auto-synched to Maven Central.
>
> This makes it easy to review the actual artifacts that will be
> deployed, as well as ensuring that artifacts cannot be accidentally
> deployed.
I disagree with this. The most important artifacts are the
zips/tars that go to dist/. These *are* the ASF release. Nexus
makes it *harder* IMO to maintain provenance of these artifacts.
I also don't see why we *must* rely on proprietary software to
manage replication. We have been replicating actual release
artifacts to hundreds - maybe thousands, by now - of Apache mirrors
for 10+ years now using rsynch. I don't buy the argument that we
need to control access better to ibiblio-rsynch, since the same
applies to dist/ which is vastly more important and we trust RMs to
manage carefully.
Phil
> Nexus release process is described here:
>
> http://www.apache.org/dev/publishing-maven-artifacts.html
>
>> Matt
>>
>>>> Niall
>>>>
>>>>> I would ask, however,
>>>>> that those arguing for the "automagical" approach take a hard look
>>>>> at how many volunteer hours are being spent trying to get
>>>>> maven/nexus to be a release manager and how comparatively little
>>>>> time those of us who take the "manual" approach spend getting our
>>>>> releases built and deployed. While I certainly can't claim to
>>>>> produce perfect artifacts (much less code :), I will also point out
>>>>> that the only major release quality problem that we have had
>>>>> recently was the inadvertent release of a [net] version while
>>>>> fiddling with the release plugin. I don't at all buy the argument
>>>>> that the manual approach is "error-prone" as it allows more and
>>>>> better opportunities for inspection by the RM and community at each
>>>>> stage.
>>>>
>>>>
>>>>
>>>>> Phil
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by sebb <se...@gmail.com>.
On 29 March 2011 16:20, Matt Benson <gu...@gmail.com> wrote:
> On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
>> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>> After another nightmare by an RM who has not cut a release in a
>>>> while, I think we need to do something. The documentation on the
>>>> Commons web pages describes a process that works. I suggest that we
>>>> standardize on that process, adding some simple automation scripts
>>>> that RMs can choose to use or not to use for the manual steps and
>>>> stop fussing with Nexus or the maven release plugin. I cut an RC
>>
>> We need to keep Nexus, but I agree about the release plugin - see below.
>>
>>>> last night in 25 minutes (about 15 of which were spent waiting for
>>>> the [pool] tests to complete) and will likely spend about that same
>>>> amount of time deploying the artifacts to dist/ and what remains of
>>>> our simple, file-and-directory-based replication infrastructure to
>>>> get maven artifacts pushed to the maven repos. I do use a simple
>>>> shell script to manage invoking the maven commands and copying files
>>>> around to reduce the required time from, say an hour, to 25
>>>> minutes. The script is in svn.
>>>>
>>>> I prefer the "manual" approach for the following reasons:
>>>>
>>>> 1. I know what it does. Exactly, every time. I know that exactly
>>>> the binaries that we vote on get deployed to dist/ and exactly the
>>>> committed tag is used to build everything. The process includes
>>>> local generation of artifacts that I can inspect and test locally
>>>> and verify sigs. I know at each step exactly what is being pushed
>>>> where.
>>>>
>>>> 2. I know that it works. Every time. No pom-tweaking,
>>>> plugin-munging or other half-success management required.
>>>>
>>>> 3. It has no commercial / proprietary dependencies. The scripts
>>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>>
>>>> I know others have different opinions on this. It could be we need
>>>> to support both ways of cutting releases.
>>>
>>> AIUI then the deployment to the maven repository is either by dropping
>>> the artifacts manually in
>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>>> Nexus. I think once a component switches to Nexus, then the manual
>>> process doesn't work.
>>
>> Yes, that is true.
>>
>> Also, had the [net] release been using Nexus, it would have required 2
>> additional manual stages to close and then release the Maven
>> artifacts.
>> It is impossible to accidentally release Maven artifacts using Maven
>> command-line when using a staging manager such as Nexus.
>>
>> But I agree that using manual processes up to that point is better
>> than trying to use the Maven release plugin.
>
> My assumption is that the Nexus stuff is supposed to work and make
> life easier. If it doesn't, I suppose we shouldn't use it. Is it a
> training issue, such that none of us simply knows exactly what it is
> we ought to expect the process to do, and how it will do it? This
> type of thing is my chief complaint about Maven in general: it's hard
> to understand what's going on once you get a level or two of parent
> POMs in there. If it's just a matter of "we haven't discovered the
> precise incantations that make the release plugin + Nexus instance do
> what we mean with no fuss," perhaps we could cajole Brian Fox into
> walking one of us (who solemnly vows to document the entire experience
> in full detail) through the entire lifecycle.
Nexus is effectively a proxy, and has little bearing on how Maven
deploy or release work.
The artifacts end up in Nexus rather than in a directory that is
auto-synched to Maven Central.
This makes it easy to review the actual artifacts that will be
deployed, as well as ensuring that artifacts cannot be accidentally
deployed.
Nexus release process is described here:
http://www.apache.org/dev/publishing-maven-artifacts.html
> Matt
>
>>
>>> Niall
>>>
>>>> I would ask, however,
>>>> that those arguing for the "automagical" approach take a hard look
>>>> at how many volunteer hours are being spent trying to get
>>>> maven/nexus to be a release manager and how comparatively little
>>>> time those of us who take the "manual" approach spend getting our
>>>> releases built and deployed. While I certainly can't claim to
>>>> produce perfect artifacts (much less code :), I will also point out
>>>> that the only major release quality problem that we have had
>>>> recently was the inadvertent release of a [net] version while
>>>> fiddling with the release plugin. I don't at all buy the argument
>>>> that the manual approach is "error-prone" as it allows more and
>>>> better opportunities for inspection by the RM and community at each
>>>> stage.
>>>
>>>
>>>
>>>
>>>> Phil
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Matt Benson <gu...@gmail.com>.
On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>> After another nightmare by an RM who has not cut a release in a
>>> while, I think we need to do something. The documentation on the
>>> Commons web pages describes a process that works. I suggest that we
>>> standardize on that process, adding some simple automation scripts
>>> that RMs can choose to use or not to use for the manual steps and
>>> stop fussing with Nexus or the maven release plugin. I cut an RC
>
> We need to keep Nexus, but I agree about the release plugin - see below.
>
>>> last night in 25 minutes (about 15 of which were spent waiting for
>>> the [pool] tests to complete) and will likely spend about that same
>>> amount of time deploying the artifacts to dist/ and what remains of
>>> our simple, file-and-directory-based replication infrastructure to
>>> get maven artifacts pushed to the maven repos. I do use a simple
>>> shell script to manage invoking the maven commands and copying files
>>> around to reduce the required time from, say an hour, to 25
>>> minutes. The script is in svn.
>>>
>>> I prefer the "manual" approach for the following reasons:
>>>
>>> 1. I know what it does. Exactly, every time. I know that exactly
>>> the binaries that we vote on get deployed to dist/ and exactly the
>>> committed tag is used to build everything. The process includes
>>> local generation of artifacts that I can inspect and test locally
>>> and verify sigs. I know at each step exactly what is being pushed
>>> where.
>>>
>>> 2. I know that it works. Every time. No pom-tweaking,
>>> plugin-munging or other half-success management required.
>>>
>>> 3. It has no commercial / proprietary dependencies. The scripts
>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>
>>> I know others have different opinions on this. It could be we need
>>> to support both ways of cutting releases.
>>
>> AIUI then the deployment to the maven repository is either by dropping
>> the artifacts manually in
>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>> Nexus. I think once a component switches to Nexus, then the manual
>> process doesn't work.
>
> Yes, that is true.
>
> Also, had the [net] release been using Nexus, it would have required 2
> additional manual stages to close and then release the Maven
> artifacts.
> It is impossible to accidentally release Maven artifacts using Maven
> command-line when using a staging manager such as Nexus.
>
> But I agree that using manual processes up to that point is better
> than trying to use the Maven release plugin.
My assumption is that the Nexus stuff is supposed to work and make
life easier. If it doesn't, I suppose we shouldn't use it. Is it a
training issue, such that none of us simply knows exactly what it is
we ought to expect the process to do, and how it will do it? This
type of thing is my chief complaint about Maven in general: it's hard
to understand what's going on once you get a level or two of parent
POMs in there. If it's just a matter of "we haven't discovered the
precise incantations that make the release plugin + Nexus instance do
what we mean with no fuss," perhaps we could cajole Brian Fox into
walking one of us (who solemnly vows to document the entire experience
in full detail) through the entire lifecycle.
Matt
>
>> Niall
>>
>>> I would ask, however,
>>> that those arguing for the "automagical" approach take a hard look
>>> at how many volunteer hours are being spent trying to get
>>> maven/nexus to be a release manager and how comparatively little
>>> time those of us who take the "manual" approach spend getting our
>>> releases built and deployed. While I certainly can't claim to
>>> produce perfect artifacts (much less code :), I will also point out
>>> that the only major release quality problem that we have had
>>> recently was the inadvertent release of a [net] version while
>>> fiddling with the release plugin. I don't at all buy the argument
>>> that the manual approach is "error-prone" as it allows more and
>>> better opportunities for inspection by the RM and community at each
>>> stage.
>>
>>
>>
>>
>>> Phil
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Ralph Goers <ra...@dslextreme.com>.
On Mar 29, 2011, at 8:08 AM, sebb wrote:
>>
>
> Yes, that is true.
>
> Also, had the [net] release been using Nexus, it would have required 2
> additional manual stages to close and then release the Maven
> artifacts.
> It is impossible to accidentally release Maven artifacts using Maven
> command-line when using a staging manager such as Nexus.
>
> But I agree that using manual processes up to that point is better
> than trying to use the Maven release plugin.
>
As you well know, I've been working on releasing vfs for what seems like forever. The build using the release plugin took quite a bit of work to get going but now that it works there is no way I'd switch to something more manual. The only problem I have at the moment is that I'm waiting for the SCM plugin vote to pass so I can push out a new release of the release plugin. That is so I can remove the release notes from svn after the tag is cut. Once I have that I will be a happy camper.
Ralph
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by sebb <se...@gmail.com>.
On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>> After another nightmare by an RM who has not cut a release in a
>> while, I think we need to do something. The documentation on the
>> Commons web pages describes a process that works. I suggest that we
>> standardize on that process, adding some simple automation scripts
>> that RMs can choose to use or not to use for the manual steps and
>> stop fussing with Nexus or the maven release plugin. I cut an RC
We need to keep Nexus, but I agree about the release plugin - see below.
>> last night in 25 minutes (about 15 of which were spent waiting for
>> the [pool] tests to complete) and will likely spend about that same
>> amount of time deploying the artifacts to dist/ and what remains of
>> our simple, file-and-directory-based replication infrastructure to
>> get maven artifacts pushed to the maven repos. I do use a simple
>> shell script to manage invoking the maven commands and copying files
>> around to reduce the required time from, say an hour, to 25
>> minutes. The script is in svn.
>>
>> I prefer the "manual" approach for the following reasons:
>>
>> 1. I know what it does. Exactly, every time. I know that exactly
>> the binaries that we vote on get deployed to dist/ and exactly the
>> committed tag is used to build everything. The process includes
>> local generation of artifacts that I can inspect and test locally
>> and verify sigs. I know at each step exactly what is being pushed
>> where.
>>
>> 2. I know that it works. Every time. No pom-tweaking,
>> plugin-munging or other half-success management required.
>>
>> 3. It has no commercial / proprietary dependencies. The scripts
>> are optional and are in any case, ASF-licensed, committed to svn.
>>
>> I know others have different opinions on this. It could be we need
>> to support both ways of cutting releases.
>
> AIUI then the deployment to the maven repository is either by dropping
> the artifacts manually in
> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
> Nexus. I think once a component switches to Nexus, then the manual
> process doesn't work.
Yes, that is true.
Also, had the [net] release been using Nexus, it would have required 2
additional manual stages to close and then release the Maven
artifacts.
It is impossible to accidentally release Maven artifacts using Maven
command-line when using a staging manager such as Nexus.
But I agree that using manual processes up to that point is better
than trying to use the Maven release plugin.
> Niall
>
>> I would ask, however,
>> that those arguing for the "automagical" approach take a hard look
>> at how many volunteer hours are being spent trying to get
>> maven/nexus to be a release manager and how comparatively little
>> time those of us who take the "manual" approach spend getting our
>> releases built and deployed. While I certainly can't claim to
>> produce perfect artifacts (much less code :), I will also point out
>> that the only major release quality problem that we have had
>> recently was the inadvertent release of a [net] version while
>> fiddling with the release plugin. I don't at all buy the argument
>> that the manual approach is "error-prone" as it allows more and
>> better opportunities for inspection by the RM and community at each
>> stage.
>
>
>
>
>> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Niall Pemberton <ni...@gmail.com>.
On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
> After another nightmare by an RM who has not cut a release in a
> while, I think we need to do something. The documentation on the
> Commons web pages describes a process that works. I suggest that we
> standardize on that process, adding some simple automation scripts
> that RMs can choose to use or not to use for the manual steps and
> stop fussing with Nexus or the maven release plugin. I cut an RC
> last night in 25 minutes (about 15 of which were spent waiting for
> the [pool] tests to complete) and will likely spend about that same
> amount of time deploying the artifacts to dist/ and what remains of
> our simple, file-and-directory-based replication infrastructure to
> get maven artifacts pushed to the maven repos. I do use a simple
> shell script to manage invoking the maven commands and copying files
> around to reduce the required time from, say an hour, to 25
> minutes. The script is in svn.
>
> I prefer the "manual" approach for the following reasons:
>
> 1. I know what it does. Exactly, every time. I know that exactly
> the binaries that we vote on get deployed to dist/ and exactly the
> committed tag is used to build everything. The process includes
> local generation of artifacts that I can inspect and test locally
> and verify sigs. I know at each step exactly what is being pushed
> where.
>
> 2. I know that it works. Every time. No pom-tweaking,
> plugin-munging or other half-success management required.
>
> 3. It has no commercial / proprietary dependencies. The scripts
> are optional and are in any case, ASF-licensed, committed to svn.
>
> I know others have different opinions on this. It could be we need
> to support both ways of cutting releases.
AIUI then the deployment to the maven repository is either by dropping
the artifacts manually in
http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
Nexus. I think once a component switches to Nexus, then the manual
process doesn't work.
Niall
> I would ask, however,
> that those arguing for the "automagical" approach take a hard look
> at how many volunteer hours are being spent trying to get
> maven/nexus to be a release manager and how comparatively little
> time those of us who take the "manual" approach spend getting our
> releases built and deployed. While I certainly can't claim to
> produce perfect artifacts (much less code :), I will also point out
> that the only major release quality problem that we have had
> recently was the inadvertent release of a [net] version while
> fiddling with the release plugin. I don't at all buy the argument
> that the manual approach is "error-prone" as it allows more and
> better opportunities for inspection by the RM and community at each
> stage.
> Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Phil Steitz <ph...@gmail.com>.
After another nightmare by an RM who has not cut a release in a
while, I think we need to do something. The documentation on the
Commons web pages describes a process that works. I suggest that we
standardize on that process, adding some simple automation scripts
that RMs can choose to use or not to use for the manual steps and
stop fussing with Nexus or the maven release plugin. I cut an RC
last night in 25 minutes (about 15 of which were spent waiting for
the [pool] tests to complete) and will likely spend about that same
amount of time deploying the artifacts to dist/ and what remains of
our simple, file-and-directory-based replication infrastructure to
get maven artifacts pushed to the maven repos. I do use a simple
shell script to manage invoking the maven commands and copying files
around to reduce the required time from, say an hour, to 25
minutes. The script is in svn.
I prefer the "manual" approach for the following reasons:
1. I know what it does. Exactly, every time. I know that exactly
the binaries that we vote on get deployed to dist/ and exactly the
committed tag is used to build everything. The process includes
local generation of artifacts that I can inspect and test locally
and verify sigs. I know at each step exactly what is being pushed
where.
2. I know that it works. Every time. No pom-tweaking,
plugin-munging or other half-success management required.
3. It has no commercial / proprietary dependencies. The scripts
are optional and are in any case, ASF-licensed, committed to svn.
I know others have different opinions on this. It could be we need
to support both ways of cutting releases. I would ask, however,
that those arguing for the "automagical" approach take a hard look
at how many volunteer hours are being spent trying to get
maven/nexus to be a release manager and how comparatively little
time those of us who take the "manual" approach spend getting our
releases built and deployed. While I certainly can't claim to
produce perfect artifacts (much less code :), I will also point out
that the only major release quality problem that we have had
recently was the inadvertent release of a [net] version while
fiddling with the release plugin. I don't at all buy the argument
that the manual approach is "error-prone" as it allows more and
better opportunities for inspection by the RM and community at each
stage.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by sebb <se...@gmail.com>.
On 29 March 2011 04:45, Gary Gregory <ga...@gmail.com> wrote:
> On Mon, Mar 28, 2011 at 11:21 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 3/28/11 4:49 PM, Gary Gregory wrote:
>> > I am having a heck of a time pushing the release out.
>> >
>> > I cannot seem to be able to create the sym links per the instructions in
>> > http://wiki.apache.org/commons/UsingNexus
>> >
>> > I cannot get the symlinks.sh script working. I copied it to my home bin
>> > directory. When I invoke it, it is not found. Just running it from my
>> home
>> > bin w/o args does give me the usage I get:
>> >
>> You need to run it from the dist directory where the links are going
>> to be created and you need to give it the release number. See steps
>> 1 and 2 here:
>> http://commons.apache.org/releases/release.html
>>
>> Step 2 assumes that the tars and zips have somehow made their way to
>> /www/www.apache.org/dist/commons/foo/
>>
>> Step 1 provides instructions on how to move things there. I think
>> Nexus tries to do this moving for you.
>>
>> To get the symlinks created properly, you need to invoke symlinks.sh
>> with the release number as its command line argument from
>> /www/www.apache.org/dist/commons/foo/
>>
>> For that to work, you have to have the script available and
>> executable. That should happen if you put it in your bin directory
>> and do chmod +x on it. Have a look at your .profile file (cat
>> ~/.profile). If it does not contain a line that looks something like
>>
>> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:$HOME/bin;
>> export PATH
>> then you need to add that line (maybe minus the games and X11R6
>> stuff) or just copy a new .profile. Let me know if you are having
>> problems with this and I will help.
>>
>> Sebb is right though that you should close the VOTE before moving
>> stuff to dist/
>>
>
> Thank you for the detailed instructions. I am going to go through those
> next.
>
> I must have misunderstood the voting process, which I thought was, if all
> goes well:
> - Send a [VOTE] email (this thread)
> - Wait 72 hours
> - Send a [VOTE][RESULT] email:
> http://mail-archives.apache.org/mod_mbox/commons-dev/201103.mbox/%3CAANLkTikgpm0Lo-aoi8WfKjXznOXzodtgza2CwJdcQ+F-@mail.gmail.com%3E
>
> Is there a [VOTE][CLOSE] email that needs to go out as well after 72 hours?
No, but for some reason I did not see the [RESULT] e-mail - sounds
like Phil did not either.
> I can see that I should have mentioned the vote timeline in the [VOTE] email
> as documented in http://commons.apache.org/releases/prepare.html
>
> But, I used the [VOTE] email template from
> http://wiki.apache.org/commons/UsingNexus which contains no such text.
>
> Sigh, the release process is so obtuse with the mixture of Maven, UNIX,
> Nexus, multiple instruction pages, and so on. It is quite discouraging and a
> barrier to progress :(
Patches welcome ...
> Gary
>
>>
>> Phil
>>
>>
>> >> symlinks.sh
>> > symlinks.sh: Command not found.
>> >
>> >> sh symlinks.sh
>> > symlinks.sh: 46: Syntax error: word unexpected
>> >
>> > I need some UNIX help ;)
>> >
>> > Thank you,
>> > Gary
>> >
>> > On Thu, Mar 24, 2011 at 9:39 PM, Gary Gregory <garydgregory@gmail.com
>> >wrote:
>> >
>> >> [VOTE] Release Apache Commons Codec 1.5-RC1
>> >>
>> >> Tag:
>> >>
>> >>
>> >>
>> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
>> >>
>> >> Site:
>> >>
>> >> http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
>> >>
>> >> Binaries:
>> >>
>> >>
>> https://repository.apache.org/content/repositories/orgapachecommons-041/
>> >>
>> >> [ ] +1 release it
>> >> [ ] +0 go ahead I don't care
>> >> [ ] -1 no, do not release it because
>> >>
>> >> Thank you,
>> >> Gary
>> >>
>> >> http://garygregory.wordpress.com/
>> >> http://garygregory.com/
>> >> http://people.apache.org/~ggregory/
>> >> http://twitter.com/GaryGregory
>> >>
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Mar 28, 2011 at 11:21 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 3/28/11 4:49 PM, Gary Gregory wrote:
> > I am having a heck of a time pushing the release out.
> >
> > I cannot seem to be able to create the sym links per the instructions in
> > http://wiki.apache.org/commons/UsingNexus
> >
> > I cannot get the symlinks.sh script working. I copied it to my home bin
> > directory. When I invoke it, it is not found. Just running it from my
> home
> > bin w/o args does give me the usage I get:
> >
> You need to run it from the dist directory where the links are going
> to be created and you need to give it the release number. See steps
> 1 and 2 here:
> http://commons.apache.org/releases/release.html
>
> Step 2 assumes that the tars and zips have somehow made their way to
> /www/www.apache.org/dist/commons/foo/
>
> Step 1 provides instructions on how to move things there. I think
> Nexus tries to do this moving for you.
>
> To get the symlinks created properly, you need to invoke symlinks.sh
> with the release number as its command line argument from
> /www/www.apache.org/dist/commons/foo/
>
> For that to work, you have to have the script available and
> executable. That should happen if you put it in your bin directory
> and do chmod +x on it. Have a look at your .profile file (cat
> ~/.profile). If it does not contain a line that looks something like
>
> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:$HOME/bin;
> export PATH
> then you need to add that line (maybe minus the games and X11R6
> stuff) or just copy a new .profile. Let me know if you are having
> problems with this and I will help.
>
> Sebb is right though that you should close the VOTE before moving
> stuff to dist/
>
Thank you for the detailed instructions. I am going to go through those
next.
I must have misunderstood the voting process, which I thought was, if all
goes well:
- Send a [VOTE] email (this thread)
- Wait 72 hours
- Send a [VOTE][RESULT] email:
http://mail-archives.apache.org/mod_mbox/commons-dev/201103.mbox/%3CAANLkTikgpm0Lo-aoi8WfKjXznOXzodtgza2CwJdcQ+F-@mail.gmail.com%3E
Is there a [VOTE][CLOSE] email that needs to go out as well after 72 hours?
I can see that I should have mentioned the vote timeline in the [VOTE] email
as documented in http://commons.apache.org/releases/prepare.html
But, I used the [VOTE] email template from
http://wiki.apache.org/commons/UsingNexus which contains no such text.
Sigh, the release process is so obtuse with the mixture of Maven, UNIX,
Nexus, multiple instruction pages, and so on. It is quite discouraging and a
barrier to progress :(
Gary
>
> Phil
>
>
> >> symlinks.sh
> > symlinks.sh: Command not found.
> >
> >> sh symlinks.sh
> > symlinks.sh: 46: Syntax error: word unexpected
> >
> > I need some UNIX help ;)
> >
> > Thank you,
> > Gary
> >
> > On Thu, Mar 24, 2011 at 9:39 PM, Gary Gregory <garydgregory@gmail.com
> >wrote:
> >
> >> [VOTE] Release Apache Commons Codec 1.5-RC1
> >>
> >> Tag:
> >>
> >>
> >>
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
> >>
> >> Site:
> >>
> >> http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
> >>
> >> Binaries:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-041/
> >>
> >> [ ] +1 release it
> >> [ ] +0 go ahead I don't care
> >> [ ] -1 no, do not release it because
> >>
> >> Thank you,
> >> Gary
> >>
> >> http://garygregory.wordpress.com/
> >> http://garygregory.com/
> >> http://people.apache.org/~ggregory/
> >> http://twitter.com/GaryGregory
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by sebb <se...@gmail.com>.
On 29 March 2011 04:21, Phil Steitz <ph...@gmail.com> wrote:
> On 3/28/11 4:49 PM, Gary Gregory wrote:
>> I am having a heck of a time pushing the release out.
>>
>> I cannot seem to be able to create the sym links per the instructions in
>> http://wiki.apache.org/commons/UsingNexus
>>
>> I cannot get the symlinks.sh script working. I copied it to my home bin
>> directory. When I invoke it, it is not found. Just running it from my home
>> bin w/o args does give me the usage I get:
>>
> You need to run it from the dist directory where the links are going
> to be created and you need to give it the release number. See steps
> 1 and 2 here:
> http://commons.apache.org/releases/release.html
>
> Step 2 assumes that the tars and zips have somehow made their way to
> /www/www.apache.org/dist/commons/foo/
>
> Step 1 provides instructions on how to move things there. I think
> Nexus tries to do this moving for you.
No, Nexus does not handle non-Maven artifacts.
> To get the symlinks created properly, you need to invoke symlinks.sh
> with the release number as its command line argument from
> /www/www.apache.org/dist/commons/foo/
>
> For that to work, you have to have the script available and
> executable. That should happen if you put it in your bin directory
> and do chmod +x on it. Have a look at your .profile file (cat
> ~/.profile). If it does not contain a line that looks something like
> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:$HOME/bin;
> export PATH
> then you need to add that line (maybe minus the games and X11R6
> stuff) or just copy a new .profile. Let me know if you are having
> problems with this and I will help.
>
> Sebb is right though that you should close the VOTE before moving
> stuff to dist/
>
> Phil
>
>
>>> symlinks.sh
>> symlinks.sh: Command not found.
>>
>>> sh symlinks.sh
>> symlinks.sh: 46: Syntax error: word unexpected
>>
>> I need some UNIX help ;)
>>
>> Thank you,
>> Gary
>>
>> On Thu, Mar 24, 2011 at 9:39 PM, Gary Gregory <ga...@gmail.com>wrote:
>>
>>> [VOTE] Release Apache Commons Codec 1.5-RC1
>>>
>>> Tag:
>>>
>>>
>>> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
>>>
>>> Site:
>>>
>>> http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
>>>
>>> Binaries:
>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-041/
>>>
>>> [ ] +1 release it
>>> [ ] +0 go ahead I don't care
>>> [ ] -1 no, do not release it because
>>>
>>> Thank you,
>>> Gary
>>>
>>> http://garygregory.wordpress.com/
>>> http://garygregory.com/
>>> http://people.apache.org/~ggregory/
>>> http://twitter.com/GaryGregory
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by sebb <se...@gmail.com>.
On 29 March 2011 04:55, Gary Gregory <ga...@gmail.com> wrote:
> On Mon, Mar 28, 2011 at 11:21 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 3/28/11 4:49 PM, Gary Gregory wrote:
>> > I am having a heck of a time pushing the release out.
>> >
>> > I cannot seem to be able to create the sym links per the instructions in
>> > http://wiki.apache.org/commons/UsingNexus
>> >
>> > I cannot get the symlinks.sh script working. I copied it to my home bin
>> > directory. When I invoke it, it is not found. Just running it from my
>> home
>> > bin w/o args does give me the usage I get:
>> >
>> You need to run it from the dist directory where the links are going
>> to be created and you need to give it the release number. See steps
>> 1 and 2 here:
>> http://commons.apache.org/releases/release.html
>>
>> Step 2 assumes that the tars and zips have somehow made their way to
>> /www/www.apache.org/dist/commons/foo/
>>
>> Step 1 provides instructions on how to move things there. I think
>> Nexus tries to do this moving for you.
>>
>> To get the symlinks created properly, you need to invoke symlinks.sh
>> with the release number as its command line argument from
>> /www/www.apache.org/dist/commons/foo/
>>
>> For that to work, you have to have the script available and
>> executable. That should happen if you put it in your bin directory
>> and do chmod +x on it. Have a look at your .profile file (cat
>> ~/.profile). If it does not contain a line that looks something like
>>
>> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:$HOME/bin;
>> export PATH
>> then you need to add that line (maybe minus the games and X11R6
>> stuff) or just copy a new .profile. Let me know if you are having
>> problems with this and I will help.
>>
>
> Yes, please.
>
> Here is my profile:
>
>> cat .profile
> # $FreeBSD: src/share/skel/dot.profile,v 1.19.2.2 2002/07/13 16:29:10 mp Exp
> $
> #
> # .profile - Bourne Shell startup script for login shells
> #
> # see also sh(1), environ(7).
> #
>
> # remove /usr/games and /usr/X11R6/bin if you want
> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:$HOME/bin;
> export PATH
>
> # Setting TERM is normally done through /etc/ttys. Do only override
> # if you're sure that you'll never log in via telnet or xterm or a
> # serial line.
> # Use cons25l1 for iso-* fonts
> # TERM=cons25; export TERM
>
> BLOCKSIZE=K; export BLOCKSIZE
> EDITOR=vi; export EDITOR
> PAGER=more; export PAGER
>
> # set ENV to a file invoked each time sh is started for interactive use.
> ENV=$HOME/.shrc; export ENV
>
> [ -x /usr/games/fortune ] && /usr/games/fortune freebsd-tips
>
> Here is my bin:
>
>> ls -l $HOME/bin
> total 3
> -rwxrwxr-x 1 ggregory commons 1775 Mar 28 22:12 symlinks.sh
>
> When I try to run it from $HOME, just for fun, I get:
>
>> symlinks.sh
> symlinks.sh: Command not found.
Try logging out an in again; sometimes that's needed to pick up path changes.
Which shell are you using? They use different files to initialise themselves.
Try "echo $PATH" to check.
> Then a couple of experiments:
>
>> cd bin
>> symlinks.sh
> symlinks.sh: Command not found.
Not being found on the path.
>> sh symlinks.sh
> symlinks.sh: 46: Syntax error: word unexpected
You did not provide a parameter.
How does the script know what to link?
> I am stuck.
> Gary
>
>
>>
>> Sebb is right though that you should close the VOTE before moving
>> stuff to dist/
>>
>> Phil
>>
>>
>> >> symlinks.sh
>> > symlinks.sh: Command not found.
>> >
>> >> sh symlinks.sh
>> > symlinks.sh: 46: Syntax error: word unexpected
>> >
>> > I need some UNIX help ;)
>> >
>> > Thank you,
>> > Gary
>> >
>> > On Thu, Mar 24, 2011 at 9:39 PM, Gary Gregory <garydgregory@gmail.com
>> >wrote:
>> >
>> >> [VOTE] Release Apache Commons Codec 1.5-RC1
>> >>
>> >> Tag:
>> >>
>> >>
>> >>
>> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
>> >>
>> >> Site:
>> >>
>> >> http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
>> >>
>> >> Binaries:
>> >>
>> >>
>> https://repository.apache.org/content/repositories/orgapachecommons-041/
>> >>
>> >> [ ] +1 release it
>> >> [ ] +0 go ahead I don't care
>> >> [ ] -1 no, do not release it because
>> >>
>> >> Thank you,
>> >> Gary
>> >>
>> >> http://garygregory.wordpress.com/
>> >> http://garygregory.com/
>> >> http://people.apache.org/~ggregory/
>> >> http://twitter.com/GaryGregory
>> >>
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Mar 28, 2011 at 11:21 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 3/28/11 4:49 PM, Gary Gregory wrote:
> > I am having a heck of a time pushing the release out.
> >
> > I cannot seem to be able to create the sym links per the instructions in
> > http://wiki.apache.org/commons/UsingNexus
> >
> > I cannot get the symlinks.sh script working. I copied it to my home bin
> > directory. When I invoke it, it is not found. Just running it from my
> home
> > bin w/o args does give me the usage I get:
> >
> You need to run it from the dist directory where the links are going
> to be created and you need to give it the release number. See steps
> 1 and 2 here:
> http://commons.apache.org/releases/release.html
>
> Step 2 assumes that the tars and zips have somehow made their way to
> /www/www.apache.org/dist/commons/foo/
>
> Step 1 provides instructions on how to move things there. I think
> Nexus tries to do this moving for you.
>
> To get the symlinks created properly, you need to invoke symlinks.sh
> with the release number as its command line argument from
> /www/www.apache.org/dist/commons/foo/
>
> For that to work, you have to have the script available and
> executable. That should happen if you put it in your bin directory
> and do chmod +x on it. Have a look at your .profile file (cat
> ~/.profile). If it does not contain a line that looks something like
>
> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:$HOME/bin;
> export PATH
> then you need to add that line (maybe minus the games and X11R6
> stuff) or just copy a new .profile. Let me know if you are having
> problems with this and I will help.
>
Yes, please.
Here is my profile:
> cat .profile
# $FreeBSD: src/share/skel/dot.profile,v 1.19.2.2 2002/07/13 16:29:10 mp Exp
$
#
# .profile - Bourne Shell startup script for login shells
#
# see also sh(1), environ(7).
#
# remove /usr/games and /usr/X11R6/bin if you want
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:$HOME/bin;
export PATH
# Setting TERM is normally done through /etc/ttys. Do only override
# if you're sure that you'll never log in via telnet or xterm or a
# serial line.
# Use cons25l1 for iso-* fonts
# TERM=cons25; export TERM
BLOCKSIZE=K; export BLOCKSIZE
EDITOR=vi; export EDITOR
PAGER=more; export PAGER
# set ENV to a file invoked each time sh is started for interactive use.
ENV=$HOME/.shrc; export ENV
[ -x /usr/games/fortune ] && /usr/games/fortune freebsd-tips
Here is my bin:
> ls -l $HOME/bin
total 3
-rwxrwxr-x 1 ggregory commons 1775 Mar 28 22:12 symlinks.sh
When I try to run it from $HOME, just for fun, I get:
> symlinks.sh
symlinks.sh: Command not found.
Then a couple of experiments:
> cd bin
> symlinks.sh
symlinks.sh: Command not found.
> sh symlinks.sh
symlinks.sh: 46: Syntax error: word unexpected
I am stuck.
Gary
>
> Sebb is right though that you should close the VOTE before moving
> stuff to dist/
>
> Phil
>
>
> >> symlinks.sh
> > symlinks.sh: Command not found.
> >
> >> sh symlinks.sh
> > symlinks.sh: 46: Syntax error: word unexpected
> >
> > I need some UNIX help ;)
> >
> > Thank you,
> > Gary
> >
> > On Thu, Mar 24, 2011 at 9:39 PM, Gary Gregory <garydgregory@gmail.com
> >wrote:
> >
> >> [VOTE] Release Apache Commons Codec 1.5-RC1
> >>
> >> Tag:
> >>
> >>
> >>
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
> >>
> >> Site:
> >>
> >> http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
> >>
> >> Binaries:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-041/
> >>
> >> [ ] +1 release it
> >> [ ] +0 go ahead I don't care
> >> [ ] -1 no, do not release it because
> >>
> >> Thank you,
> >> Gary
> >>
> >> http://garygregory.wordpress.com/
> >> http://garygregory.com/
> >> http://people.apache.org/~ggregory/
> >> http://twitter.com/GaryGregory
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Phil Steitz <ph...@gmail.com>.
On 3/28/11 4:49 PM, Gary Gregory wrote:
> I am having a heck of a time pushing the release out.
>
> I cannot seem to be able to create the sym links per the instructions in
> http://wiki.apache.org/commons/UsingNexus
>
> I cannot get the symlinks.sh script working. I copied it to my home bin
> directory. When I invoke it, it is not found. Just running it from my home
> bin w/o args does give me the usage I get:
>
You need to run it from the dist directory where the links are going
to be created and you need to give it the release number. See steps
1 and 2 here:
http://commons.apache.org/releases/release.html
Step 2 assumes that the tars and zips have somehow made their way to
/www/www.apache.org/dist/commons/foo/
Step 1 provides instructions on how to move things there. I think
Nexus tries to do this moving for you.
To get the symlinks created properly, you need to invoke symlinks.sh
with the release number as its command line argument from
/www/www.apache.org/dist/commons/foo/
For that to work, you have to have the script available and
executable. That should happen if you put it in your bin directory
and do chmod +x on it. Have a look at your .profile file (cat
~/.profile). If it does not contain a line that looks something like
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:$HOME/bin;
export PATH
then you need to add that line (maybe minus the games and X11R6
stuff) or just copy a new .profile. Let me know if you are having
problems with this and I will help.
Sebb is right though that you should close the VOTE before moving
stuff to dist/
Phil
>> symlinks.sh
> symlinks.sh: Command not found.
>
>> sh symlinks.sh
> symlinks.sh: 46: Syntax error: word unexpected
>
> I need some UNIX help ;)
>
> Thank you,
> Gary
>
> On Thu, Mar 24, 2011 at 9:39 PM, Gary Gregory <ga...@gmail.com>wrote:
>
>> [VOTE] Release Apache Commons Codec 1.5-RC1
>>
>> Tag:
>>
>>
>> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
>>
>> Site:
>>
>> http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
>>
>> Binaries:
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-041/
>>
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because
>>
>> Thank you,
>> Gary
>>
>> http://garygregory.wordpress.com/
>> http://garygregory.com/
>> http://people.apache.org/~ggregory/
>> http://twitter.com/GaryGregory
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Gary Gregory <ga...@gmail.com>.
I am having a heck of a time pushing the release out.
I cannot seem to be able to create the sym links per the instructions in
http://wiki.apache.org/commons/UsingNexus
I cannot get the symlinks.sh script working. I copied it to my home bin
directory. When I invoke it, it is not found. Just running it from my home
bin w/o args does give me the usage I get:
> symlinks.sh
symlinks.sh: Command not found.
> sh symlinks.sh
symlinks.sh: 46: Syntax error: word unexpected
I need some UNIX help ;)
Thank you,
Gary
On Thu, Mar 24, 2011 at 9:39 PM, Gary Gregory <ga...@gmail.com>wrote:
> [VOTE] Release Apache Commons Codec 1.5-RC1
>
> Tag:
>
>
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
>
> Site:
>
> http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
>
> Binaries:
>
> https://repository.apache.org/content/repositories/orgapachecommons-041/
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because
>
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Mar 28, 2011 at 2:12 PM, Gary Gregory <ga...@gmail.com>wrote:
> On Sat, Mar 26, 2011 at 2:53 PM, Jörg Schaible <jo...@gmx.de>wrote:
>
>> Hi Gary,
>>
>> fails for me with latest IBM JDK for 1.5:
>>
>> =================================== %< ===================================
>> $ java -version
>> java version "1.5.0"
>> Java(TM) 2 Runtime Environment, Standard Edition (build
>> pxa64devifx-20110224
>> (SR12 FP4 ))
>> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux amd64-64
>> j9vmxa6423ifx-20110203 (JIT enabled)
>> J9VM - 20110202_74536_LHdSMr
>> JIT - 20100623_16197ifx3_r8
>> GC - 20100211_AA)
>> JCL - 20110224
>>
>>
>> -------------------------------------------------------------------------------
>> Test set: org.apache.commons.codec.binary.Base64InputStreamTest
>>
>> -------------------------------------------------------------------------------
>> Tests run: 12, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.134 sec
>> <<< FAILURE!
>>
>> testInputStreamReader(org.apache.commons.codec.binary.Base64InputStreamTest)
>> Time elapsed: 0.003 sec <<< ERROR!
>> sun.io.MalformedInputException
>> at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:310)
>> at
>> sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:316)
>> at
>> sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:366)
>> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:252)
>> at java.io.InputStreamReader.read(InputStreamReader.java:212)
>> at java.io.BufferedReader.fill(BufferedReader.java:157)
>> at java.io.BufferedReader.readLine(BufferedReader.java:320)
>> at java.io.BufferedReader.readLine(BufferedReader.java:383)
>> at
>>
>> org.apache.commons.codec.binary.Base64InputStreamTest.testInputStreamReader(Base64InputStreamTest.java:105)
>> =================================== %< ===================================
>>
>> Might be a JDK bug though.
>>
>> Runs fine for IBM JDK 1.6, OpenJDK 1.6, Sun JDK 1.5, 1.6, 1.7 and a build
>> with the java-1.4 profile using blackdown 1.4.2 was also successful.
>>
>>
> I just tried to install the IBM 1.5.0 JDK I found here:
> http://download.lenovo.com/ibmdl/pub/pc/pccbbs/thinkvantage_en/ibm-java2-ibmpc-jre-50-win-i386.exe
>
> The installer told me I was not running on an IBM system and quit. I am on
> a Lenovo laptop running Windows 7.
>
> I'm not sure what to do about this expect to deal with it to post release
> unless you can point me to something I can install.
>
> Thank you,
> Gary
>
>
FYI: And I get the same error message with the 1.4.2 version from the same
IBM web page.
Gary
>
>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Jörg Schaible <jo...@gmx.de>.
Phil Steitz wrote:
> On 3/28/11 2:42 PM, Jörg Schaible wrote:
>> Gary Gregory wrote:
>>> I just tried to install the IBM 1.5.0 JDK I found here:
>>> http://download.lenovo.com/ibmdl/pub/pc/pccbbs/thinkvantage_en/ibm-
java2-
>> ibmpc-jre-50-win-i386.exe
>>
>> The Linux version is not crippled.
>>
>>> The installer told me I was not running on an IBM system and quit. I am
>>> on a Lenovo laptop running Windows 7.
>>>
>>> I'm not sure what to do about this expect to deal with it to post
>>> release unless you can point me to something I can install.
> That would be Linux ;)
>
> Just kidding. I wonder if anyone here has connections in IBM who
> could help us get hold of these "endangered species" JDKs for
> testing so Jorg does not have to start a captive breeding program :)
Actually I don't get the point of such stupid policies, when developers
cannot even test their software to create either fixes for their own stuff
or report bugs for the vendor's stuff.
All you can say now is: Apache Commons Codec is incompatible with IBM JDK
1.5 due to unknown JDK errors. Perfect marketing strategy.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Phil Steitz <ph...@gmail.com>.
On 3/28/11 2:42 PM, Jörg Schaible wrote:
> Gary Gregory wrote:
>> I just tried to install the IBM 1.5.0 JDK I found here:
>> http://download.lenovo.com/ibmdl/pub/pc/pccbbs/thinkvantage_en/ibm-java2-
> ibmpc-jre-50-win-i386.exe
>
> The Linux version is not crippled.
>
>> The installer told me I was not running on an IBM system and quit. I am on
>> a Lenovo laptop running Windows 7.
>>
>> I'm not sure what to do about this expect to deal with it to post release
>> unless you can point me to something I can install.
That would be Linux ;)
Just kidding. I wonder if anyone here has connections in IBM who
could help us get hold of these "endangered species" JDKs for
testing so Jorg does not have to start a captive breeding program :)
Phil
> :-/
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Jörg Schaible <jo...@gmx.de>.
Gary Gregory wrote:
> I just tried to install the IBM 1.5.0 JDK I found here:
> http://download.lenovo.com/ibmdl/pub/pc/pccbbs/thinkvantage_en/ibm-java2-
ibmpc-jre-50-win-i386.exe
The Linux version is not crippled.
> The installer told me I was not running on an IBM system and quit. I am on
> a Lenovo laptop running Windows 7.
>
> I'm not sure what to do about this expect to deal with it to post release
> unless you can point me to something I can install.
:-/
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Mar 26, 2011 at 2:53 PM, Jörg Schaible <jo...@gmx.de>wrote:
> Hi Gary,
>
> fails for me with latest IBM JDK for 1.5:
>
> =================================== %< ===================================
> $ java -version
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build
> pxa64devifx-20110224
> (SR12 FP4 ))
> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux amd64-64
> j9vmxa6423ifx-20110203 (JIT enabled)
> J9VM - 20110202_74536_LHdSMr
> JIT - 20100623_16197ifx3_r8
> GC - 20100211_AA)
> JCL - 20110224
>
>
> -------------------------------------------------------------------------------
> Test set: org.apache.commons.codec.binary.Base64InputStreamTest
>
> -------------------------------------------------------------------------------
> Tests run: 12, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.134 sec
> <<< FAILURE!
>
> testInputStreamReader(org.apache.commons.codec.binary.Base64InputStreamTest)
> Time elapsed: 0.003 sec <<< ERROR!
> sun.io.MalformedInputException
> at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:310)
> at
> sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:316)
> at
> sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:366)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:252)
> at java.io.InputStreamReader.read(InputStreamReader.java:212)
> at java.io.BufferedReader.fill(BufferedReader.java:157)
> at java.io.BufferedReader.readLine(BufferedReader.java:320)
> at java.io.BufferedReader.readLine(BufferedReader.java:383)
> at
>
> org.apache.commons.codec.binary.Base64InputStreamTest.testInputStreamReader(Base64InputStreamTest.java:105)
> =================================== %< ===================================
>
> Might be a JDK bug though.
>
> Runs fine for IBM JDK 1.6, OpenJDK 1.6, Sun JDK 1.5, 1.6, 1.7 and a build
> with the java-1.4 profile using blackdown 1.4.2 was also successful.
>
>
I just tried to install the IBM 1.5.0 JDK I found here:
http://download.lenovo.com/ibmdl/pub/pc/pccbbs/thinkvantage_en/ibm-java2-ibmpc-jre-50-win-i386.exe
The installer told me I was not running on an IBM system and quit. I am on a
Lenovo laptop running Windows 7.
I'm not sure what to do about this expect to deal with it to post release
unless you can point me to something I can install.
Thank you,
Gary
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Gary,
fails for me with latest IBM JDK for 1.5:
=================================== %< ===================================
$ java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pxa64devifx-20110224
(SR12 FP4 ))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux amd64-64
j9vmxa6423ifx-20110203 (JIT enabled)
J9VM - 20110202_74536_LHdSMr
JIT - 20100623_16197ifx3_r8
GC - 20100211_AA)
JCL - 20110224
-------------------------------------------------------------------------------
Test set: org.apache.commons.codec.binary.Base64InputStreamTest
-------------------------------------------------------------------------------
Tests run: 12, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.134 sec
<<< FAILURE!
testInputStreamReader(org.apache.commons.codec.binary.Base64InputStreamTest)
Time elapsed: 0.003 sec <<< ERROR!
sun.io.MalformedInputException
at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:310)
at
sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:316)
at
sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:366)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:252)
at java.io.InputStreamReader.read(InputStreamReader.java:212)
at java.io.BufferedReader.fill(BufferedReader.java:157)
at java.io.BufferedReader.readLine(BufferedReader.java:320)
at java.io.BufferedReader.readLine(BufferedReader.java:383)
at
org.apache.commons.codec.binary.Base64InputStreamTest.testInputStreamReader(Base64InputStreamTest.java:105)
=================================== %< ===================================
Might be a JDK bug though.
Runs fine for IBM JDK 1.6, OpenJDK 1.6, Sun JDK 1.5, 1.6, 1.7 and a build
with the java-1.4 profile using blackdown 1.4.2 was also successful.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Mar 24, 2011 at 10:18 PM, sebb <se...@gmail.com> wrote:
> On 25 March 2011 01:39, Gary Gregory <ga...@gmail.com> wrote:
> > [VOTE] Release Apache Commons Codec 1.5-RC1
> >
> > Tag:
> >
> >
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
> >
> > Site:
> >
> > http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
>
> AIUI from the branding perspective:
>
> Ideally there should be a TM after the first use of Commons Codec, and
> it should be used as an adjective, e.g.
>
> Apache Commons Coded tm software is ...
>
> but these are not blockers, and can be fixed later.
>
> > Binaries:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-041/
>
> Cannot find the signing key in the KEYS file:.
> http://www.apache.org/dist/commons/KEYS
>
> That must be fixed before release.
>
Thank you for the quick feedback.
I had updated the KEYS file in
https://svn.apache.org/repos/asf/commons/trunks-proper/ but not copied it to
people.apache.org:/www/www.apache.org/dist/commons which I now see mentioned
here http://commons.apache.org/releases/prepare.html
I used:
scp KEYS people.apache.org:/www/www.apache.org/dist/commons
but I do not see this reflected on the web yet. A cat of /x1/www/
www.apache.org/content/dist/commons/KEYS shows me that my update is there.
Otherwise seems OK
>
> [I deleted the .asc.md5 and .asc.sha1 files]
>
I thought Nexus did that for you when you promote a release?
Gary
>
> >
> > [ ] +1 release it
> > [ ] +0 go ahead I don't care
> > [ ] -1 no, do not release it because
> >
> > Thank you,
> > Gary
> >
> > http://garygregory.wordpress.com/
> > http://garygregory.com/
> > http://people.apache.org/~ggregory/
> > http://twitter.com/GaryGregory
> >
>
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by sebb <se...@gmail.com>.
On 25 March 2011 01:39, Gary Gregory <ga...@gmail.com> wrote:
> [VOTE] Release Apache Commons Codec 1.5-RC1
>
> Tag:
>
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
>
> Site:
>
> http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
AIUI from the branding perspective:
Ideally there should be a TM after the first use of Commons Codec, and
it should be used as an adjective, e.g.
Apache Commons Coded tm software is ...
but these are not blockers, and can be fixed later.
> Binaries:
>
> https://repository.apache.org/content/repositories/orgapachecommons-041/
Cannot find the signing key in the KEYS file:.
http://www.apache.org/dist/commons/KEYS
That must be fixed before release.
Otherwise seems OK
[I deleted the .asc.md5 and .asc.sha1 files]
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because
>
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Mar 26, 2011 at 4:51 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 3/24/11 6:39 PM, Gary Gregory wrote:
> > [VOTE] Release Apache Commons Codec 1.5-RC1
> >
> > Tag:
> >
> >
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
> >
> > Site:
> >
> > http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
> >
> > Binaries:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-041/
> >
> > [X] +1 release it
> > [ ] +0 go ahead I don't care
> > [ ] -1 no, do not release it because
> >
> > Thank you,
> > Gary
> >
> > http://garygregory.wordpress.com/
> > http://garygregory.com/
> > http://people.apache.org/~ggregory/
> > http://twitter.com/GaryGregory
> >
> I ran into the same test compilation failure that Oliver pointed out
> using Sun JDK 1.6.0_24 on Mac OSX. I did not get this failure
> testing the Ant build with Sun JDK 1.6.0_17, Sun JDK 1.5.0_22 or
> Jrockit 1.6.0_14 on Ubuntu.
>
Yes, this is an Ant configuration issue. Fixed in SVN.
>
> I assume that what we are actually voting on are the .gz and .zip
> files and these (along with sigs and hashes) are what will be
> deployed to /dist.
>
IMO, anything that is at the Binary URL is up for the vote. What matter most
to me is the end product: the jar file.
>
> I verified the sigs (using the Key I just grabbed from the web site)
> and hashes on these files and all look good.
>
> Nice work!
>
Thank you sir! :)
Gary
>
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Phil Steitz <ph...@gmail.com>.
On 3/24/11 6:39 PM, Gary Gregory wrote:
> [VOTE] Release Apache Commons Codec 1.5-RC1
>
> Tag:
>
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
>
> Site:
>
> http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
>
> Binaries:
>
> https://repository.apache.org/content/repositories/orgapachecommons-041/
>
> [X] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because
>
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
I ran into the same test compilation failure that Oliver pointed out
using Sun JDK 1.6.0_24 on Mac OSX. I did not get this failure
testing the Ant build with Sun JDK 1.6.0_17, Sun JDK 1.5.0_22 or
Jrockit 1.6.0_14 on Ubuntu.
I assume that what we are actually voting on are the .gz and .zip
files and these (along with sigs and hashes) are what will be
deployed to /dist.
I verified the sigs (using the Key I just grabbed from the web site)
and hashes on these files and all look good.
Nice work!
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Codec 1.5-RC1
Posted by Gary Gregory <ga...@gmail.com>.
And my +1.
Gary
On Thu, Mar 24, 2011 at 9:39 PM, Gary Gregory <ga...@gmail.com>wrote:
> [VOTE] Release Apache Commons Codec 1.5-RC1
>
> Tag:
>
>
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.5-RC1
>
> Site:
>
> http://people.apache.org/builds/commons/codec/1.5/RC1/site/index.html
>
> Binaries:
>
> https://repository.apache.org/content/repositories/orgapachecommons-041/
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because
>
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory