Re: About the role of the Release (again)

[Colin Walters <walters verbum org>]

On Mon, 2013-08-05 at 19:17 +0200, Piñeiro wrote:

> IMHO, the first thing to debate if we are willing to expand our role and
> scope, assuming that is what the Foundation members want us to do. If we
> are, then let's ask the community if that is what they want. If not, we
> should document with more detail what we are, what we do, and how far we
> will go on our duties. I mention "how far" because that was raised by
> Colin on our meeting here at GUADEC with the specific example of bluez
> migration.

Yeah...though I do think for that one our best bet is to highlight both
the benefits of the transition (and the drawbacks).

> "When there is a strong difference of opinion related to a change made
> within a core GNOME module, the Release Team has the authority to serve
> as mediator in the hopes of finding a solution which is agreeable to all
> parties. Failing that, the Release Team has the authority to veto the
> inclusion of the change in GNOME releases".

I think it's our role to *always* be involved to some degree.  Not that
anyone is full time, but I mean the job naturally involves mediation
since there are so many parts.

A lot hinges here on what "veto" means.  "git revert"?  Letting the
change stand in master and shipping an earlier branch?  I guess some
modules (mainly apps) could be dropped entirely.  And of course
ultimately, downstreams have their own veto.

How would we decide?  Would we vote?

I know that I mentioned at the meeting we should consider possibly
shipping earlier versions of things, but now that I consider it...there
are a lot of details.

Presently the release-team emits the modulesets with tarballs...so the
natural tendency would lead us to something like earlier releases in
there.  But if it's not a short term thing, then it's a fork, and that
leads us to the need for a git branch...but theoretically the
maintainers are in control of the git repository.