Re: GNOME Shell Modal Dialog Tweakage

[Luc Pionchon <pionchon luc gmail com>]

Hi,

On Mon, Mar 12, 2012 at 12:40, Allan Day <allanpday gmail com> wrote:
> On Sun, Mar 11, 2012 at 1:02 AM, Shaun McCance <shaunm gnome org> wrote:
>> Replying to two in one, to save electrons.
>>
>> On Sat, 2012-03-10 at 13:03 -0500, Matthias Clasen wrote:
>>> On Sat, Mar 10, 2012 at 9:49 AM, Allan Day <allanpday gmail com> wrote:
>>> >>
>>> >> Now, if we want to define and write down an exact list of things we do
>>> >> not require approval for (but still require notification), I'm OK with
>>> >> that.
>>> >
>>> > I don't recall suggesting that you construct "an exact list of things
>>> > we do not require approval for". All I'm saying is that a single
>>> > sentence isn't a lot to go on. A few more details would be helpful.
>>
>> Allan:
>>
>> What I'm saying is that all the extra verbiage is what we would need
>> to have exceptions. The single sentence right now is very clear. It
>> doesn't mention exceptions, therefore there's no reason to assume any.
>>
>>> > It's clear that many people don't understand the rules the way you do.
>>
>> And that's why I engage developers when I think they're not following
>> the release process. I'm happy to have a more public discussion about
>> this. Our release process is always evolving, and I've always taken
>> part in those discussions.
>>
>>> I think it is important to not lose sight of the goal here.
>>>
>>> The freeze is not there so we in the release team or the documentation
>>> guys can feel empowered.  The goal is to ensure that we end up with a
>>> high-quality release and docs that match the actual product well
>>> enough to not confuse users.
>>
>> Matthias:
>>
>> I think one of the big benefits of the freezes is that they act as
>> a deterrent to making lots of small changes.
>>
>> One small discrepancy isn't a big deal. As you mentioned earlier,
>> very few people will likely even notice a discrepancy in the docs
>> with this particular change. (By the same token, though, very few
>> people will notice the change at all, and that makes it much less
>> urgent to get it into this release.)
>
> I wouldn't have pushed this change if I didn't think it was urgent. As
> you say below, details matter.
>
>> But if we don't discourage changes after the freezes, then it won't
>> be one small discrepancy. It will be 20 or 50 or 100. And then our
>> help and marketing materials and other stuff look unprofessional.
>> Yes, I care if our help looks professional. I care that it gives
>> the impression that it's current, because we're fighting a user
>> perception problem born out of a decade of useless and outdated
>> manuals. Details matter.
>>
>> Allan only sent a notification because another developer suggested
>> he should. And he apparently made some font size changes without
>> notification. That suggests to me that people are not deterred at
>> all from making post-freeze changes, and that potentially lots of
>> small changes are being made that I don't know about. It adds up.
>
> Well yes, one patch changed some text from 10.5pt to 11pt. I think
> there was another one that changed a text style from 9pt to 9pt bold
> (all part of a much larger theme cleanup, I might add). These are
> exactly the kinds of changes that shouldn't require freeze breaks, in
> my opinion.
>
>> That suggests to me that people are not deterred at
>> all from making post-freeze changes, and that potentially lots of
>> small changes are being made that I don't know about. It adds up.
>
> Personally speaking, there are two issues here.
>
> The first is the apparent lack of consensus. I was following what I
> understood to be good practice, and even went out if my way to be
> considerate towards the docs team. It's frustrating to then be told
> that I'm breaking the rules. I largely agree with Matthias's last
> message, but I also want some clarity.
>
> The second issue is what the policy should actually be. This is really
> up to the release and docs teams, but my personal opinion is that
> minor cosmetic changes that don't impact on the docs shouldn't require
> a break request. We're busy enough without having to jump through
> extraneous bureaucratic hoops.

So you are dedicated to improve a product and you are used to freely
bring your own stone to the building with a fair pride. But suddenly
you are told that you break a rule, and that you must first go through
the office to get an approval to put your stone (and there is a
potential threat to be rejected). I really understand the frustration.

But there is a reason. I try to bring some light from the organization
of software production point of view, as maybe some people are not
familiar with.

For organizations that cares about release quality, which means "of
good quality", but also "on time", the release management is a
critical process.

For the little story, I was part of the maemo crew, and more
specifically responsible for such critical elements like GTK+ and
glib: it means that one single crashing bug down inside at the wrong
place turns the device into a brick. In the context of mobile devices,
the consequences can be huge financially, because factories are
reserved for a certain period of time to produce the devices and they
need to flash an image at the end of the assembly line. An assembly
line costs a lot, really. Not even mentioning that if you delay your
product's assembly, you delay also the following products... OK it is
clear that a delay of a GNOME release is not as critical, but we still
all want to deliver good quality and on time, it is our pride.

Close to the release date, it is not a time for development anymore,
it is a time to stabilize the product without adding regressions. It
means that the organization must be super careful about what it brings
into the product. So before the release, the release team takes _full_
control on what gets in (and what doesn't). They are responsible for
what gets in. They are the ones who will have to take the decision
"this build is the release".

Ideally there are no issues: so we could release and restart
development right away.

In practice there are issues to fix, and there is a clear risk to make
things worst. Everybody wants the release to be a good quality, there
is no doubt. And everybody gives his best to fix issues. Everybody is
100% sure that his own change is minor and has no impact - but in fact
who knows 100%? In a complex piece of software, when you make many
changes without a careful control, one is never 100% that there will
not be one severe regression. Statistically, among 100 developers (for
example), there will be at least one who will introduce a severe
issue. To track down the issue can take several days (maybe weeks),
which means that we will not release on time, or release a product
with low quality. The release team is responsible for preventing this.

About Allan's change, everybody is sure that there is no regression.
But what about if... it uses a CSS keyword never used before in GNOME,
and that the new function in gtk+ that deals with that keyword calls a
glib function that triggers yet another bug which crashes the whole
system. How much time to track down the issue when 100s of people are
making changes independently? Who can tell?

That's why during release time we go through the office to announce
"Hey, I am planning to add this stone to the building, is that OK with
you?". And the office keeps under control what changes where and how
many changes are made. If it gets flooded by requests it has a chance
to scream Stop!

Is it a reduction of developer's freedom: yes
Is it a dictatorship: yes
Is it frustrating: possibly yes
Is it bad: no

The objectives justify the means: insure _zero_ breakage and release on time.

To come back to the GNOME process, one have to send an email to get
approvals before going further. (Correct? is it 2 from release and 1
from doc?). The answers are quick and usually positive, as far as I
know. So to be honest it is not what I would call a bureaucratic
process, I have to say that it is very light.

That's it.
I hope I brought some light on release management in general, the
responsibilities, the challenges, and the risks