Re: Nautilus hard code freeze break request

["Matthias Clasen" <matthias clasen gmail com>]

On Wed, Sep 17, 2008 at 11:14 AM, Vincent Untz <vuntz gnome org> wrote:
> Le mercredi 17 septembre 2008, à 14:37 +0200, Christian Neumair a écrit :
>> Am Mittwoch, den 17.09.2008, 14:13 +0200 schrieb Vincent Untz:
>> > I'm mixed on this one -- it's minor, but the patch is simple. I'm
>> > giving a small first approval.
>>
>> I wonder why there is such a strict policy. Minor fixes are fixes as
>> well, especially for applications that are frequently used and seen by
>> the end users.
>>
>> Isn't the purpose of the hard code freeze to review all changes such
>> that no new scary last-minute bugs are introduced? Instead, it seems
>> that just "major" fixes are considered, i.e. fixes for crashers - which
>> fortunately have not been an issue for Nautilus for some time.
>>
>> The result in the Nautilus case is that the user-perceived quality of
>> the 2.24.0 release will suffer, and once hard code freeze is over, we
>> will see lots of postponed commits on my behalf to the stable branch.
>> I.e. we are essentially supporting the "X.0 releases do have many
>> glitches - let's wait for X.1" prejudice.
>
> Even having a review from two release team doesn't guarantee that the
> patch is good. The thing is that not a lot of people will test what you
> commit now. So everything we do at this point is risky, and that's why
> we usually prefer to live with minor annoyances. It certainly has
> happened in the past to have a regression in .0 compared to the .92
> release, and we want to avoid this.
>
> If a bug is a regression compared to the previous stable release, then
> please state so: it will certainly be taken into account. But else, it's
> not related to the X.0/X.1 prejudice -- that's just a result of our fast
> development schedule.

Just to clarify. I disagree somewhat with this stance. Certainly the
maintainer is
in a much better position to judge whether a patch is correct or risky
or what, than
release team members can ever be. Having the hard code freeze and
break request process is useful to slow down the process and make
people think harder about what needs fixing now, but I don't think it
is useful if we shoot down minor bug fixes like this.

Matthias