The future of the release team

[Mark McLoughlin <markmc redhat com>]

Hey,
	The release process has served GNOME well in terms of our
desire to have a predictable release cycle, a development line which
receives plenty of testing and regular, continuous expansion of the
feature set.

	As the release process has become so ingrained in GNOME, the
release team itself has become much less important to the success to
the process. Coupled with that, the release team rarely actually works
as a team, fails to communicate well amongst the team and with the
wider community.

	We all agree that there needs to be some change, and I think
we all have varying ideas on what changes are best. Below is my
attempt at explaining my point of view and I think Jeff is going to
post his ideas. Having two different proposals should be a great way
to kick off a healthy discussion. I hope people take the time to think
about this stuff and reply - it's important.


	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

	However, I think there's a broad misunderstanding that the
release team is something more than this. A think-tank for future
GNOME releases, an arbitrator of tough decisions or a go-between with
other projects? That's not us. I think that perception is a very
dangerous one - it takes away the feeling of responsibility the entire
community should feel for such issues.

	In reality, I think release team members occasionally find
themselves with the time and motivation to tackle issues outside of
that small set of responsibilities and, as a member of the release
team, feel empowered to do so. I'd like every single member of our
community to feel empowered to tackle any issues they feel strongly
about.

	I suggest we could move forward roughly as follows:

  a) Disband the release team and the release-team mailing list

  b) On a web page, create a table of release responsibilities[2],
     look for volunteers and put people against each
     responsibility. Some of them will have a number of people
     handling them and I'd certainly imagine existing release team
     members would be heavily involved.

     At the start of each release cycle, we'd call for volunteers so
     as to allow new people to get involved and people who no longer
     have the time to drop back again.

  c) Encourage open discussion about release progress on d-d-l

  d) Create a separate, open mailing list where the freeze break
     approvers can process requests

	There's a number of reasons why I'd like a model like this:

  - Everything is open and explicit. Everybody is aware of what's
    going and can see how things are done.

  - Individuals are responsible for given tasks, so its very easy to
    know who to ask, who to help out and the individuals themselves
    would be more inclined to either ensure the task gets completed or
    ask someone for help.

  - Its very easy for new blood to get involved.

  - Experienced volunteers who no longer have time for a given
    responsibility don't have to be as worried about giving up that
    responsibility - they can easily see how the new volunteers are
    doing and give advice

  - Its obvious to everyone which issues are being tackled and which
    aren't. It should be obvious that its the community at large that
    has responsibility for the issues which aren't being tackled.

  - The entire community is more involved in the excitement of getting
    the release out.

	I think its worthwhile giving something like this a try. The worst that
could happen is that 2.10 would be slightly disorganised and we decide
we need a release team back. We could re-form the team from a clean
slate and re-think what our role is. On the other hand, we could find
the release to be even more organised, bang on time, with lots of
community involvement and excitement. We could see the process evolving
to be even better. We could rock. Seriously, we could.

Cheers,
Mark.

[1] - thanks to Elijah for the list

[2] - e.g.

     What?                    |    Who?
  ----------------------------+------------
                              |
  Draw up schedule            |
                              |
  Start new module discussion |
  and encorage consensus      |
                              |
  Gather and push tarballs    |
                              |
  Release announcements       |
                              |
  Release web pages           |
                              |
  Freeze break approvals      |