commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [all] Release preparation documentation
Date Mon, 05 Apr 2010 20:54:46 GMT
On 05/04/2010, Phil Steitz <> wrote:
> I have made my first attempt at updating the documentation here:
>  Given that the previous docs were so out of date as to be pretty
>  much worthless, I thought it best to push things along with CTR -
>  actually "PTR" (p = publish).  I am sure there are some errors that
>  I did not catch.  I would be most grateful to have those pointed out
>  or fixed directly.  The site is now generated from commons-site in
>  svn using m2 (no longer commons-build).
>  The process for creating artifacts and pushing them to the mirrors
>  uses the "manual" method (i.e., no release plugin) that Niall and I
>  use to cut releases. We can argue about whether or not that is the
>  right long-term direction, but I know this works and it is really
>  not that complicated.  I included some specifics, including scripts,
>  directory layouts, etc. that I use myself. I am certainly open to
>  changing any/all of this, as long as the result is a set of
>  instructions that are guaranteed to work.  I apologize for the fact
>  that the instructions are at this point unix only.  Once we have the
>  core content stabilized, it would be great to get either a Windows
>  version or interspersed Windows instructions produced.
>  One very important part that I have not really edited yet is the
>  section at the bottom of the "prepare" page laying out what to look
>  for in reviewing RCs.  It would be a *really good thing* if we could
>  lay out there all and only what we collectively deem to be mandatory
>  for RCs.  That would make it much easier for RMs and short-circuit
>  some discussions on what is a show-stopper and what is not during
>  release votes.  I am more than happy to document our consensus on
>  these things. Patches welcome!

I think it might be useful to add a note regarding consistency between
changes.xml, RELEASE-NOTES and JIRA.

For example, if JIRA FOO-1234 is fixed in release 1.2, then IMO it
should have a JIRA "fix" release of 1.2, and appear in the
changes/RelNotes for 1.2. Conversely, if FOO-1234 is not fixed in
release 1.2, then it should not have a JIRA fix of 1.2.

This is to make it easy for users/developers to find which release
contains the fix for a particular JIRA bug. It is not always so easy
to find this out from checking release notes.

It may be quite tedious to do the consistency check - and it may not
always be 100% accurate - but I would hope to get agreement that it's
worth documenting as a desirable goal.

>  Phil
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail:
>  For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message