Re: Release change proposal

[Sriram Ramkrishna <sri ramkrishna me>]

Hey guys, thanks for doing this!  We do need to make changes to how we release software.  Let me make some comments below.

On Sat, Aug 3, 2013 at 2:22 AM, Benjamin Tissoires <benjamin tissoires gmail com> wrote:

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.

So, here is the formal proposal we wrote:

Will you ratify this with the rest of the release team?
 

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.

Yes, this is a good idea.  Having a group would definitely help.  Do you have people in mind to do this?

 

    Just because you are maintainer, doesn't mean you must do it, you
only have to make sure someone does it. It could be required to be
documented as part of patch submitting or code review, the way tests,
documentation and other things are related to a feature.

That's cool, I especially feel that this information must also be shared with the documentation team.  Kat was telling me that they would know about new features after the fact.  Documentation is especially important for me and I would like to make sure that we are making sure that this information especially user visible visual changes are properly communicated by the release team.
 

    * 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.

What means do we have to challenge a feature removal?  While I respect a maintainer's decision, I'm interested in keeping good relations with our community.  Sometimes there are things removed that would be very challenging to defend.
 

    * The major changes should be documented between alpha and beta? (
but always before UI freeze ), thus giving us ~3 months before "proper
release" to do user interaction and communication on forums, slashdot
and other things.

Sounds good.
 

    * 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.

If they do not..  what would be the consequences?  Do we delay release?
 

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

 Sounds good.
 

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

We should provide suggestions as well.
 

    ( Note that just because this is documented, the code doesn't need
to be removed at this time, but the _intention_ should be very clear.
)
    It's free software, we do change our minds at times.
        The bikeshed should be green.

Sure. 

I see that you've put some thought into this and I thank you for that! 

I do have some other changes that i think would help.  We are contantly criticized when extensions break.  I would like ot make sure that we have an image available for people to download and try out.  There should be at least a week of user testing.  We should make sure that things work for the most part.

sri

Cheers,
Benjamin & Spider
--
https://mail.gnome.org/mailman/listinfo/board-list

>From time to time confidential and sensitive information will be discussed
on this mailing list. Please take care to mark confidential information as
confidential, and do not redistribute this information without permission.