activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <clebert.suco...@gmail.com>
Subject Re: [DISCUSS] release process improvements
Date Wed, 13 Sep 2017 12:21:24 GMT
That's why I asked you the intention.  I had the impression it would be
something to double work what nexus already does on checksums.


Let me see how that works.... and I will put my feedback here.

On Wed, Sep 13, 2017 at 5: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
>
-- 
Clebert Suconic

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message