Thanks for the hint Dave, here are the links: http://incubator.apache.org/guides/releasemanagement.html
http://wiki.apache.org/incubator/ReleaseChecklist http://incubator.apache.org/guides/release.html http://wiki.apache.org/incubator/SigningReleases there are probably more, but I think this is a good start. I would suggest that everyone has a little bit of a read over the next two weeks and that we then combine ideas into a 'how to' for the next release and refine that as we gain more experience. G On Mon, Aug 24, 2015 at 2:52 AM, Dave Fisher <dave2w...@comcast.net> wrote: > Here are two ideas that other projects do. > > (1) Have a target in the build or a script that creates all the release > artifacts. > > (2) include Apache RAT to run license checks as part of the build. > > Look at the emails at the emails from IPMC members on what was done as part > of the vote. > > Corinthia will certainly have our own unique differences based what artifacts > we decide to create. > > I think there are probably three check lists. > > (1) Release Packaging - what is being released. > > (2) Release Manager - how to build, vote and distribute. POI has almost all > of this as Ant targets. This can make it easy to for anyone to be RM > > (3) Voter - how to check IP from both the ASF requirements and also the > project's. We can choose our own standards for quality. The ASF is not > concerned if the code works, but the project community does care. > > The incubator has wikis with policies and draft policies I would provide the > links but I am away from my computer. Perhaps Dennis can provide the links. > > Regards, > Dave > > Sent from my iPhone > >> On Aug 23, 2015, at 12:37 PM, Gabriela Gibson <gabriela.gib...@gmail.com> >> wrote: >> >> On Sun, Aug 23, 2015 at 8:18 PM, Andrea Pescetti <pesce...@apache.org> wrote: >> >> <snipped some complex procedural discussion> >> >>> It is not mandatory, but very useful (and I would >>> make a recommendation out of it) that when voting on a release one doesn't >>> simply cast a +1 as such. >>> >>> I mean, of course a -1 must always be explained, but a +1 should be >>> explained too, like this: >>> "+1 Built source on Windows, checked README files, checked ALv2 headers" >>> "+1 Did only a cursory review but I trust you guys on the code" >>> and so on. >>> >>> Remember, the PPMC is assumed (whether this is written somewhere or not) to >>> give a +1 based on (mainly) technical reasons; the IPMC will take this for >>> granted and (broadly speaking) mainly look for compliance issues. If from >>> the set of PPMC votes the Release Manager can understand, for example, that >>> no testing at all was done on Linux, he may decide to extend the VOTE until >>> Linux gets proper coverage; if the PPMC members do not supply this >>> information, we can't know what was tested and what not. >>> >>> So, Jan's question was not for me, but in terms of the "proper technical >>> review" it would help to see VOTE e-mails more informative than a simple +1, >>> so that one can be sure that all areas are covered. >>> >>> [Feel free to quote/forward this message in public] >>> >>> Regards, >>> Andrea. >> >> This makes me think that perhaps having an official check list to >> ensure that nothing gets forgotten and to make the splitting of the >> large task that a release is easy and focus resources more efficiently >> may be a very useful tool to have. >> >> What do other projects do in this regard? >> >> G >> -- >> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/ -- Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
