zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Devins-Suresh <>
Subject Re: Release review script wish-list thread
Date Mon, 11 Feb 2019 20:41:04 GMT
I actually started writing this myself too, I am creating a docker
container that
can run through the whole set of easy checks: GPG, sha512, repo/zip diff,
maven build, so I won't have to do these by hand in the future. I think
checks really should be done by hand, but I'm not opposed to a script
me into a less session and asking a question after about whether the
of the file were ok

On Mon, Feb 11, 2019 at 3:14 PM Zoltán Nagy <> wrote:

>  On "[VOTE] Release Apache Zipkin Brave Karaf (incubating) version 0.1.2"
> Adrian wrote:
> > maybe our king of scripts translation
> > into a script. For example, a curl |sh thing might do the trick and
> > avoid having to copy the script to every repo
> (Volume up, mild distortion) I've been summoned! (Volume down, distortion
> off)
> Yeah, automating the steps of reviewing a release (on the workstation of a
> PPMC) sounds like a good idea - it's one step up from a checklist. Some of
> the tough logic already exists in our, so don't need to start
> from scratch. It'll be interesting to explore what can and can't be
> automated; I foresee some "look at this file, it looks fine to me, what do
> your human eyes see?" prompts. Fair warning, I'll include a big disclaimer
> at the top of the output along the lines of "the script or its author(s)
> don't take over partial or full responsibility for the review of the
> release candidate, it's provided as a convenience helper only". I'm
> thinking an important feature will be printing a report at the end that's
> ready to paste into a mail.
> One point of such a script is to codify our shared understanding of release
> verification best practices, which will surely evolve over time. That said,
> if you already have some specific things you want or don't want to see in
> such a script, dump them here so I can include them in the initial design /
> implementation.
> This is also a great place for our mentors to say "no, automation like that
> is not in line with the Apache way, don't even start", even though, please
> don't say that ;)

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