On Mar 1, 2009, at 10:08 AM, Greg Stein wrote:
> On Sun, Mar 1, 2009 at 16:25, Stefan Sperling <stsp_at_elego.de> wrote:
>> On Sun, Mar 01, 2009 at 01:49:48AM +0100, Greg Stein wrote:
>>> That applies to partial committers fixing "obvious" things outside
>>> their normal allowed area. It does not apply to merging changes
>>> onto a
>>> release branch. The description of change management for release
>>> branches even refers to obvious fixes when talking about *voting*
>>> for
>>> those types of changes.
>>
>> Where?
>
> #obvious-fixes is the section that covers "Obvious fixes" and it is
> only in reference to partial committers making "obvious fixes" outside
> of their normal area.
>
>> All I could find is that "Obvious fixes do not require '(rX only)'
>> to be mentioned".
>
> "... to be mentioned [IN THE VOTING]." It says nothing about "go ahead
> and commit whatever you think is obvious to the release branch."
>
>> I don't see a problem with invoking the obvious fix rule in this
>> case.
>
> I do. Very much so.
>
> The release branch is about *stabilization*, and that process is under
> the sole guidance of the Release Manager. That is *why* we have a
> release manager. We cannot allow people to simply commit whatever they
> feel is "obvious" to a branch that we are stabilizing for release. If
> it is obvious, then it will get voted on and merged.
>
>> Arfrever mentioned that he invoked the rule, making clear to everyone
>> what his reasoning for merging the change is. So the only thing worth
>> arguing is whether we all agree the commit was an obvious fix or not.
>
> Right. And that is why we have VOTING. The release branch is *closed*
> to all but the Release Manager. We vote to get changes merged. We
> don't simply declare it "obvious" and merge it.
>
>>> And (IMO) merging changes into a release should be deferred to the
>>> RM
>>> simply for politeness' sake.
>>
>> I have made merges into release branches before.
>> I'd say once there are enough votes, it does not matter who does the
>> merging. I see no issue of politeness.
>
> You're circumventing the Release Manager. I consider that impolite.
> You're basically saying, "I'm going to do this without your review,
> permission, or oversight. Your role does not matter to me."
>
> (note that Hyrum may not care, but I do; the RM's role is a social
> contract that is a Good Thing to honor)
Being the current RM, perhaps I should chime in here. :)
Back in the day, whoever approved the patch or patch group in STATUS
usually did the merge. It wasn't until I became the RM and started
paying close attention to STATUS and applying my OCD to it did the
Release Manager become the sole merger and guardian of the branch. It
wasn't a conscious decision on the part of the project, but rather
something that just happened.
That being said, I think it's a Good Thing to follow this convention.
Having a single person through whom all the patches go, makes sure
that the RM is aware of what's in the branch and what's not and just
the general state of things. Note that he isn't a gate-keeper and
doesn't decide what goes in and what doesn't (a la Linus), but rather
he's the person who just does the actual merging.
(And lest people think that I'm on some kind of power trip, as I've
looked at other project's release processes, this is the typical
strategy in the vast majority of instances. We're much more loose
when it comes to this type of thing.)
Now, regarding Arfrever's specific change: I know he did it mainly for
the translators, and in my anglo-centric world, I'm not particularly
sensitive to those issues. I've got no problem with the change going
in, but I do think it's not an obvious fix and it should go through
STATUS.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1256411
Received on 2009-03-02 14:50:56 CET