Re: The future of the release team

[Mikael Hallendal <micke imendio com>]

Mark McLoughlin wrote:

Hi,

Sorry for late reply, last week has been quite hectic.

> 	Right now, the release team can be defined by a small set[1]
> of responsibilities:
>
>   1) Drawing up a schedule
>
>   2) Ensuring release notes get written
>
>   3) Defining the contents of each release set
>
>   4) Reminding maintainers that tarballs are due, gathering those
>      together for each release, sanity checking and announcing
>
>   5) Reviewing requests to break feature/API/ABI/code freezes

First of all, being a former member of the release team I think this is 
a good idea. As mentioned in other mails in this thread I'm a bit 
worried about point 5 but I guess that can be solved.

The thing that worries me is if people making the calls doesn't have the 
hacking respect of the maintainers. Then people will start questioning 
the calls which will be really bad.

I think that this can be solved pretty easily by the way Mark mentioned, 
having a pretty strict document declaring the guidelines in case of a 
freeze break. My guess is that the current release team already follows 
such guidelines, we just need to get them on paper so that the people 
making the calls can point at that document as an explation to why a 
certain patch was allowed/rejected.

I agree that this should better be on a separate list since it can 
generate quite a lot of traffic. And people interested can just join the 
list.

The increase insight ini the release process would be great. Both for 
peoples understanding of the release process and everyone understanding 
that there isn't any "secret club" making all the decisions.

So, in short, this proposal gets my "vote".

Best Regards,
  Mikael Hallendal

--
Imendio HB, http://www.imendio.com/