corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: Do we have/want a check list for releases?
Date Mon, 24 Aug 2015 10:31:07 GMT
Hi

I have added text to the wiki page, while I still have it fresh in mind. A
couple of comments (before somebody start
tossing procedures):
- I added a link to the official release guide (thanks to Andrea)
- The 18 steps reflect what I just did + the changes suggested by IPMC

Disclaimer, this is our version of release management, it follows the
rules, but e.g. the PRE-VOTE is a extra
step, which Peter suggested and that turned out to be very useful.

Feel free to correct the text, but please do not reduce it to "what the
rulebook says", that will not help us.

rgds
jan i.


On 24 August 2015 at 06:40, Dennis E. Hamilton <dennis.hamilton@acm.org>
wrote:

> A nice collection.  I don't know of anything better.
>
> If you want to see how it goes for other projects, especially podlings,
> subscribe to general@incubator.apache.org and there will be plenty of
> discussion.
>
>  - Dennis
>
> -----Original Message-----
> From: Gabriela Gibson [mailto:gabriela.gibson@gmail.com]
> Sent: Sunday, August 23, 2015 19:57
> To: dev@corinthia.incubator.apache.org
> Subject: Re: Do we have/want a check list for releases?
>
> 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 <dave2wave@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.gibson@gmail.com> wrote:
> >>
> >> On Sun, Aug 23, 2015 at 8:18 PM, Andrea Pescetti <pescetti@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/
>
>

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