Re: Release change proposal

[Piñeiro <apinheiro igalia com>]

On 08/03/2013 11:22 AM, Benjamin Tissoires wrote:
> Hi,

Hi,

> after the Q&A with the board of this morning session, I discussed with
> Spider, and we thought that instead of having _one_ person in charge
> of aggregating all the changes once the release is done, we could
> spread this work among all of us.

AFAIK, there one person doing the final aggregation, but doesn't need to
be the one getting all the individual pieces. For example, on the case
of the accessibility team, Juanjo Marin get all the news related with
that field, he writes the piece about accessibility, and then it sends
it in order to be integrated on the final document.

> So, here is the formal proposal we wrote:
>
>
> Change proposal:
>     The basic idea is that we shouldn't overload maintainers, but we
> should also not require a heroic effort by single person.
>     Effort needs to be spread out amongst many people, and the work
> needs to be integrated in our normal release practices.

As I said, AFAIK, right now the process is not about getting a heroic
effort by a single person. But it seems that I could be wrong. Could you
describe what is happening right now?

>     * All module maintainers should  ( in the release cycle ) be clear
> about what features are added as new and removed.
>         This can involve rationale for the change ( Why did we remove
> transparency from the terminal? ) but that is not a must. The
> Marketing team can always ask the maintainers for details.

AFAIU, what you are proposing is that the features pages [1] should
include not only new features, but also "to be deprecated" features. Right?

>     * It is the Release Teams responsibility to ensure that all
> modules _do_ these "feature changes", but it is the module owners
> responsibility to _write_ them or make someone write it for them.

Well, this was one of the rationales behing the feature proposal and
writing them down on the feature page. Now and then the release team
meet and review the status of those features. If we don't have a clue
about the status, we ping the maintainers, usually as simple as a IRC
"maintainerXX ping: could you update the status of the feature at the
wiki?".

>     * Marketing team should follow these changes and work from them to
> avoid major user hostility that may be caused by missing features.

Anyone can subscribe to each feature page at the wiki, so they could be
notified each time is updated. Or do you mean something more elaborated?

>     * Marketing should work on this to inform users/ slowly drip
> "changes" to public attention _before_ the code drops as "stable".

Yes, probably it would be good to have some early drops of the status of
the cycle. Something similar to what Mathias Clasen is doing, writing
posts with the status of some features. Specifically, this one [1] is at
the halfway mark, so I guess that is similar to what you are proposed.

BR

[1] https://wiki.gnome.org/ThreePointNine/Features
[2]
https://blogs.gnome.org/mclasen/2013/01/25/gnome-3-7-at-the-halfway-mark/

-- 
Alejandro Piñeiro Iglesias