Marvin, I applaud your efforts here. If we are going to take PPMC release votes as binding then we should be sure that these are up to standards. Even if we don't this is still very valuable.
One note I have is I don't think we should be teaching that some of release steps are "optional" when they are required. > Checklist (all items optional, mark only those personally verified): A big issue in podlings (and TLPs) is making sure that enough PPMC members actually do the following checks by understanding that they are required: > [ ] Checksums and PGP signatures are valid. > [ ] Each expanded source archive matches content in SCM beneath RC tag. > [ ] Incubation disclaimers correct and filenames include "incubating". > [ ] Top-level LICENSE and NOTICE correct for each distribution. > [ ] ASF copyright correct in each top-level NOTICE. > [ ] All source files have license headers where appropriate. The above should be checked. The following item ought to be checked by most of the PPMC as an indication of podling maturity. > [ ] I follow this project's commits list. The following are similar, but more tranisitional - for many podlings these are not issues or are easily resolved. For some podlings though these are more difficult and can require multiple releases to satisfy properly. > [ ] All dependencies have compatible licenses. > [ ] No compiled archives bundled in a source archive. Legally optional: > [ ] All tests pass. If we are using the checklist as a way to test and measure the podling for graduation then I would add the following checkboxes. [ ] Initial PPMC member. [ ] Added PPMC member. [ ] Podling Mentor. [ ] IPMC member. If a podling cannot get the proper 3 +1 votes from the future PMC then the IPMC should not recommend graduation to the Board. Regards, Dave > > On Dec 1, 2013, at 11:09 AM, Marvin Humphrey wrote: > On Fri, Nov 29, 2013 at 1:33 PM, sebb <seb...@gmail.com> wrote: >> Not sure I understand why the checklist needs to be specific. > > The checklist should include only items which might block the release of the > artifacts under review. Expanding it to include unrelated concerns imposes an > unnecessary cost each time someone goes through the checklist. > > Let's not make the release process any harder than it needs to be. > >> It does not necessarily need to be a separate check item. >> Just a reminder that the N&L files are specific to the distributed >> items (SCM or release artifact). > > I'm apprehensive that a single checklist which tries to be all things to all > projects will ultimately prove unworkable. The design pressure is building > and eventually, customization will be the only answer. > > Nevertheless, I've added a second draft to > http://wiki.apache.org/incubator/ReleaseChecklist which attempts to address > your concerns. Here are some of the changes: > > * Pluralize a few items to allow for the possibility that the release > candidate VOTE encompasses multiple archives -- accommodating both > projects which release multiple source archives simultaneously and > projects which make convenience binaries available. > * Require that LICENCE and NOTICE be "correct for each distribution". To my > mind this is superfluous because it was implied by "correct", but it's > certainly something that projects get wrong a lot. > * Simplify the testing checklist item to `[ ] All tests pass.` This is > weaker, in that it does not require building and testing of the *source* > archive, but it is more compatible with more configurations. The > checklist item shouldn't require that all tests pass for *all* archives, > because that doesn't work with platform-specific binaries; this language > was the best general compromise I could come up with. > * Change the "license headers" item to specify "source files", in order to > resolve an incidental ambiguity with regards to whether "files" meant > archive files or source files. > > Can you live with this second draft? > > Marvin Humphrey > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
