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 <[email protected]> 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 <[email protected]> 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 ;) > > >
