Re: The future of the release team



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/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]