zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zoltán Nagy <abe...@apache.org>
Subject Re: Release review script wish-list thread
Date Mon, 11 Feb 2019 20:44:49 GMT
Awesomeness! Looking forward to you sharing that script. Yeah, Docker seems
like a good way to make sure it's running in a known-good environment, and
doesn't mess up the users GPG keychain.

/me walks away, nothing to do here :P

On Mon, Feb 11, 2019 at 8:41 PM Brian Devins-Suresh <badevins@gmail.com>
wrote:

> 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
> other
> checks really should be done by hand, but I'm not opposed to a script
> dropping
> me into a less session and asking a question after about whether the
> contents
> of the file were ok
>
> On Mon, Feb 11, 2019 at 3:14 PM Zoltán Nagy <abesto@apache.org> 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 quickstart.sh, 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 ;)
> >
>

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