[general] Release process (was [result][vote]Declare r917296 as 6.0M1)

[Mark Hindess <ma...@googlemail.com>]

In message <4B...@gmail.com>, Tim Ellison writes:
>
> I appreciate sebb's review and comments.  It would have been good to
> hear them during the two week freeze leading up to the vote rather
> than after the vote was concluded :-)

This comment isn't entirely fair.  Sebb's initial review comments
were about the binaries which we only created after the release was
"completed".  This is one reason why I had more sympathy for his view
that the release should be cancelled.

I also appreciate sebb's comments.  So, while he could have made them
by building our source and reviewing the resulting binaries, perhaps we
should attempt to make this kind of review easier?

It is tricky to see how to do this while still placing the emphasis on
voting on source releases.

It would be more work but perhaps we should create "minimal" binaries
(one hdk bundle should be sufficient perhaps one windows and one linux)
at the start of the feature freeze period?

Any thoughts?

Regards,
 Mark.

Re: [general] Release process (was [result][vote]Declare r917296 as 6.0M1)

[sebb <se...@gmail.com>]

On 09/03/2010, Mark Hindess <ma...@googlemail.com> wrote:
>
>  In message <4B...@gmail.com>, Tim Ellison writes:
>  >
>  > I appreciate sebb's review and comments.  It would have been good to
>  > hear them during the two week freeze leading up to the vote rather
>  > than after the vote was concluded :-)
>
>  This comment isn't entirely fair.

Thanks!

In all other TLPs that I follow, the process is to create a full
release candidate with hashes and sigs etc. as well as a release tag.

The whole bundle can then be reviewed as an item, and any discrepancies noted.
[For example - the source archive does not match the tag]
Blocking problems are fixed, and the process repeated with a new
release candidate and tag. Other problems may or may not be fixed.

When the release candidate passes, the artifacts can be released, and
the SVN tag is renamed as the release tag.

Obviously, if problems are noticed earlier then they can be reported
earlier, but it is expected that release candidates will fail from
time to time.

I'd just add that fixing AL issues may be a bit of a pain initially,
but should be a one-off.

>  Sebb's initial review comments
>  were about the binaries which we only created after the release was
>  "completed".  This is one reason why I had more sympathy for his view
>  that the release should be cancelled.
>
>  I also appreciate sebb's comments.  So, while he could have made them
>  by building our source and reviewing the resulting binaries, perhaps we
>  should attempt to make this kind of review easier?
>
>  It is tricky to see how to do this while still placing the emphasis on
>  voting on source releases.
>
>  It would be more work but perhaps we should create "minimal" binaries
>  (one hdk bundle should be sufficient perhaps one windows and one linux)
>  at the start of the feature freeze period?
>
>  Any thoughts?
>
>  Regards,
>
>  Mark.
>
>
>

Re: [general] Release process (was [result][vote]Declare r917296 as 6.0M1)

[Mark Hindess <ma...@googlemail.com>]

In message <3b...@mail.gmail.com>, Natha
n Beyer writes:
>
> On Tue, Mar 9, 2010 at 9:38 AM, Mark Hindess
> <ma...@googlemail.com> wrote:
> >
> > In message <4B...@gmail.com>, Tim Ellison writes:
> >>
> >> I appreciate sebb's review and comments.  It would have been good
> >> to hear them during the two week freeze leading up to the vote
> >> rather than after the vote was concluded :-)
> >
> > This comment isn't entirely fair.  Sebb's initial review comments
> > were about the binaries which we only created after the release was
> > "completed".  This is one reason why I had more sympathy for his
> > view that the release should be cancelled.
> >
> > I also appreciate sebb's comments.  So, while he could have made them
> > by building our source and reviewing the resulting binaries, perhaps
> > we should attempt to make this kind of review easier?
>
> Don't we have binary builds coming out of Hudson periodically?

Indeed.  Though they are built from svn directly rather than from svn
via source artifacts, so I worry we'd miss something that would affect
the release.

-Mark.

Re: [general] Release process (was [result][vote]Declare r917296 as 6.0M1)

[Nathan Beyer <nd...@apache.org>]

On Tue, Mar 9, 2010 at 9:38 AM, Mark Hindess
<ma...@googlemail.com> wrote:
>
> In message <4B...@gmail.com>, Tim Ellison writes:
>>
>> I appreciate sebb's review and comments.  It would have been good to
>> hear them during the two week freeze leading up to the vote rather
>> than after the vote was concluded :-)
>
> This comment isn't entirely fair.  Sebb's initial review comments
> were about the binaries which we only created after the release was
> "completed".  This is one reason why I had more sympathy for his view
> that the release should be cancelled.
>
> I also appreciate sebb's comments.  So, while he could have made them
> by building our source and reviewing the resulting binaries, perhaps we
> should attempt to make this kind of review easier?

Don't we have binary builds coming out of Hudson periodically?

>
> It is tricky to see how to do this while still placing the emphasis on
> voting on source releases.
>
> It would be more work but perhaps we should create "minimal" binaries
> (one hdk bundle should be sufficient perhaps one windows and one linux)
> at the start of the feature freeze period?
>
> Any thoughts?
>
> Regards,
>  Mark.
>
>
>