activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: [DISCUSS] release process improvements
Date Wed, 13 Sep 2017 13:21:42 GMT
This was less about time, though there is some benefit in that regard,
with how much depending on how particular people actually verify the
checksums I guess. That said, regardless of how much time difference
there actually was, given there is no real cost to doing it (adding
line[s] to an existing script), making things easier for testers and
more importantly end users eventually downloading the release to use
the checksum files for verifying their downloads seems worthwhile to
me.

A perhaps more important element is about removing a fragility in the
release process that doesn't need to be there. As you say its easy to
make mistakes, and using the dist dev repo makes it easier for us to
catch issues with the dist repo deployment while we are testing the
release, simply by moving some of the existing work a little earlier.

Also adopting the recommendation of the distribution policy seemed
beneficial to me, the checksums are there for a purpose and following
the recommendation to provide a SHA512 checksum improves their use at
no significant cost.

To be clear, there is no change around the use of Nexus itself, that
all stays the way it is, this is purely about basic changes to the
existing process of separately putting the official release bits in
the dist repo as used for the mirrors and download page etc.

Robbie

On 13 September 2017 at 13:30, Martyn Taylor <mtaylor@redhat.com> wrote:
> I don't think the responses were negative.  I don't think the benefit was
> made clear and people are questioning whether it's worth the effort.  How
> much time are we talking about saving here?  Seconds, minutes or hours?
> Would a reviewer script be helpful for some of this?
>
> IMO the Artemis release process seems to be working fine, there are quite a
> few steps to remember as a release manager and it's easy to make mistakes,
> so I would prefer not to change the process unless there's a clear benefit
> that warrants it.
>
> On Wed, Sep 13, 2017 at 10:42 AM, Robbie Gemmell <robbie.gemmell@gmail.com>
> wrote:
>
>> I'm a bit surprised by the negative responses if I'm honest.
>>
>> There isn't really any significant difference in the amount of work
>> for the release manager here. The suggestion mainly just moves the
>> step of populating the dist repo to before the vote rather than after,
>> using the dev area rather than release area. As part of that entirely
>> scriptable action, the checksums could be improved by running some
>> commands, simplifying their eventual use both for testers and for end
>> users to apply them toward the purpose they exist in verifying
>> releases downloaded from the mirrors. Using the dev repo lets folks
>> test what is actually going to be released to the dist mirrors later,
>> much like the nexus staging repo allows testing the precise maven
>> artifacts before they are promoted to release. After the vote there is
>> then less moving parts with the release manger (or someone else if
>> ever needed) just doing "svn cp <dev-url> <release-url>" to complete
>> things, much like clicking the release button in Nexus.
>>
>> For what its worth, I based the suggestions on having followed similar
>> process at Qpid for several years as either release manager or a
>> tester. I've release managed a roughly similar number of releases in
>> recent years as all the ActiveMQ components combined have had in that
>> time, and don't find the suggestions in any way a burden, if anything
>> I think they make life easier for everyone including me.
>>
>> Robbie
>>
>> On 12 September 2017 at 22:43, Michael André Pearce
>> <michael.andre.pearce@me.com> wrote:
>> > I'm -0 on this.
>> >
>> > I'm not against it if people want it, but also I don't see if it adds
>> that much to warrant the effort.
>> >
>> >  e.g. If I had to do the work I prob wouldn't want to have the extra
>> burden. At most I would just update the checksum (though I don't think this
>> is end of the world right now either, I know plenty of org/projects still
>> using md5 hash only still)
>> >
>> > As someone who's been active since the new year and tested now a few
>> releases it hasn't been difficult getting binaries or artifacts and
>> validating them.
>> >
>> >
>> > Cheers
>> > Mike
>> >
>> >
>> >
>> >
>> >
>> > Sent from my iPhone
>> >
>> >> On 12 Sep 2017, at 22:03, Clebert Suconic <clebert.suconic@gmail.com>
>> wrote:
>> >>
>> >> What is the point on adding extra steps on verifying signatures and
>> hashes?
>> >> Nexus won't let us deploy anything if it has a bad hash?
>> >>
>> >> It seems additional burecractics that could be automated in Nexus. Or
>> >> whatever ever replaces it if you are concerned about the future.
>> >>
>> >> I have been following other projects and their processes are even leaner
>> >> than ours.
>> >>
>> >> On Tue, Sep 12, 2017 at 4:41 PM Clebert Suconic <
>> clebert.suconic@gmail.com>
>> >> wrote:
>> >>
>> >>> -1 to change the process.
>> >>>
>> >>> +1 to add scripts to the reviewer.
>> >>>
>> >>> That is we improve the process of reviews. But I don't think we need
to
>> >>> change how this is released.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>> On Tue, Sep 12, 2017 at 12:36 PM Daniel Kulp <dkulp@apache.org>
>> wrote:
>> >>>>
>> >>>> Just to be clear…
>> >>>>
>> >>>> This proposal creates more work for the release manager prior to
>> starting
>> >>>> the vote but in hopes of reducing the work for the reviewers.  
It’s
>> a bit
>> >>>> more than a “mvn release:prepare ; man release:perform”.  Some
of the
>> extra
>> >>>> work can obviously be scripted, but it is still a bit more to do.
>> >>>>
>> >>>> That said,  script provided to the reviewer could accomplish the
same
>> >>>> things using the current staging location/setup.
>> >>>>
>> >>>> Anyway, I’m -0 to the idea.    Getting folks to actually be a
release
>> >>>> manager is hard enough, why make it even more work.    Since I
>> haven’t been
>> >>>> a release manager for an ActiveMQ release in a while, I certainly
>> wouldn’t
>> >>>> hold up the idea though.
>> >>>>
>> >>>> Dan
>> >>>>
>> >>>>
>> >>>>
>> >>>>> On Sep 12, 2017, at 9:49 AM, Robbie Gemmell <
>> robbie.gemmell@gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Hi folks,
>> >>>>>
>> >>>>> I mentioned on the recent Artemis 2.3.0 vote that I had some
>> suggested
>> >>>>> changes for the release process improvements, not just for Artemis
>> but
>> >>>>> for other components too, and would send a mail later.
>> >>>>>
>> >>>>> The short version is there are three main things I'd like to
suggest
>> >>>>> as improvements, both for folks testing+voting, and end users
>> >>>>> downloading the release later:
>> >>>>> - Using the dist dev repo for publishing bits for folks to test
and
>> >>>> vote on.
>> >>>>> - Providing checksum files in the dist repo which verify more
easily
>> >>>>> with the related tools.
>> >>>>> - Use SHA512 rather than SHA1 for checksums in the dist repo.
>> >>>>>
>> >>>>> # Dist dev repo for votes
>> >>>>>
>> >>>>> Currently the ActiveMQ votes for the Java components tend to
link to
>> >>>>> the artifacts in the nexus staging repo. I think using the dist
dev
>> >>>>> repo (https://dist.apache.org/repos/dist/dev/activemq/) to publish
>> the
>> >>>>> bits under vote would be an improvement. Its easy for folks
to grab
>> >>>>> all the files at once, helps ensure that what people test is
actually
>> >>>>> what will end up in the dist release repo later, and it simplifies
>> the
>> >>>>> eventual release step to a single svn remote copy command.
>> >>>>>
>> >>>>> # Provide more easily verifiable checksum files in dist release
repo
>> >>>>>
>> >>>>> Currently, the checksum files provides in the dist release repo
are
>> >>>>> just the ones from nexus. These lack filename information and
so you
>> >>>>> cant verify them as easily with tools. Files which contain the
>> >>>>> filename detail can be verified quickly and even grouped in
a single
>> >>>>> shot with the checksum tools, e.g "md5sum -c *.md5". For the
MD5 and
>> >>>>> SHA1 cases they could be prepared either by manipulating the
existing
>> >>>>> files taken from nexus to add the names, or simply generating
the
>> >>>>> checksums again with the tools and manually verifying them the
same
>> >>>>> way everyone currently needs to.
>> >>>>>
>> >>>>> # Provide SHA512 checksum files in the dist repo
>> >>>>>
>> >>>>> The release distribution policy has suggested using SHA512 for
some
>> >>>>> time now, I think it would be good to make the switch for the
files
>> >>>>> provided in the dist repo.
>> >>>>> http://www.apache.org/dev/release-distribution.html#sigs-and-sums
>> >>>>>
>> >>>>> Robbie
>> >>>>
>> >>>> --
>> >>>> Daniel Kulp
>> >>>> dkulp@apache.org - http://dankulp.com/blog
>> >>>> Talend Community Coder - http://coders.talend.com
>> >>>>
>> >>>> --
>> >>> Clebert Suconic
>> >>>
>> >> --
>> >> Clebert Suconic
>>

Mime
View raw message