The license plugin itself verifies the source headers. This is done during a run of most maven commands like test. I'm not sure we need to manually verify also, except maybe see that the plugin ran. That plugin is its only job :) For example, there's another plugin "rat" which checks library dependencies. Presence of that plugin means we don't need to re-validate the dependency tree by hand. I think transitively, we can use this logic to remove a manual step of verifying license headers. wdyt?
On Tue, Feb 12, 2019 at 4:45 AM Zoltán Nagy <[email protected]> wrote: > > 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 ;) > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
