Re: New release processes

[Sriram Ramkrishna <sri ramkrishna me>]

Excellent minutes, thanks for doing this!

On Thu, Jul 31, 2014 at 10:58 AM, Allan Day <aday gnome org> wrote:
> Hi all,
>
> Here's my attempt to summarise the processes that we discussed in
> yesterday's meeting. I've had to fill in some gaps and make some
> guesses. It's very much a draft.
>
> One issue that we didn't agree on during the BoF - I've moved the
> governance (ie. when the Release Team has a formalised opportunity to
> say no) part of the process from feature proposes to moduleset
> changes. This is mainly because I don't feel that the Release Team is
> in a position to require a feature proposal in order for that feature
> to land.
>
> Looking forward to hearing your thoughts on this.
>
> Allan
>
> ---
>
> Planning process
>
>  * Major/interesting changes that are planned by modules are listed on
> the wiki for each release, in the same way as with the current feature
> process.
>  * Plans can include any initiative, whether it affects user
> experience or is purely technical in nature. Plans do not have to be
> specific to the current release cycle - they are a statement of intent
> and desire, rather than a concrete commitment to deliver a feature
> within a specific time period.
>  * Maintainers are encouraged to add their plans at the beginning of
> each cycle (within a 2 week planning phase). The Release Team sends
> reminders to d-d-l for this.
>  * The Release Team works with maintainers of priority modules during
> this period, in order to ensure that their plans are documented. It
> can also add any plans that it knows about on behalf of maintainers.
>  * Plans do not need to be approved by the Release Team, and there is
> no acceptance period. However, the Release Team can intervene if
> advertised plans are problematic or controversial.
>  * At the end of the planning phase, the Release Team reviews the
> plans that have been added to the wiki. At this point, the Release
> Team can intervene if necessary. The Release Team then sends a mail to
> d-d-l which summarises plans for the coming cycle.
>  * Plans can be added to the wiki after the planning phase, at any
> point during the release cycle. When this happens, it is the
> responsibility of the plan proposer to notify d-d-l by email.
>
> Roadmap process
>
>  * During the planning phase, the Release Team prompts maintainers to
> review their bugs and mark priority issues for the user experience.
> This is done using the target-milestone field in Bugzilla.
>  * At the end of the planning phase, the Release Team:
>  - Reviews the list of target-milestone bugs and marks issues that are
> important at a project-level. This is done with the gnome-target
> Bugzilla field.
>  - Add their own bugs to the gnome-target list. This is done with
> input from the Design Team.
>  - Discusses the list of gnome-target bugs with maintainers, to get a
> sense of whether the maintainer can commit to fixing them during the
> current cycle.
>  - Publishes the list of gnome-target bugs on d-d-l, putting emphasis
> on bugs which need help from outside the module.
>  * At regular intervals during the release cycle:
>  - New bugs can be proposed for the gnome-target. [How would this happen?]
>  - The Release Team reviews the in-progress gnome-target list.
>  - Sends an update to d-d-l.
>
> Moduleset change process
>
>  * Only the Release Team can change the JHBuild moduleset definitions.
>  * If the Release Team updates a moduleset, they send a notification to d-d-l.
>  * If a developer or maintainer wants to add/remove a dependency or
> module, they must send a request to the Release Team (via d-d-l?)
>  * New modules must adhere to documented standards (this would be an
> updated version of the old module inclusion guidelines). This will
> include adherence to the new version of the HIG.
>
> Post-release meetings
>
>  * One week after a release, the Release Team organises a debrief
> meeting with representatives of the GNOME project teams (documentaton,
> design, accessibility, QA, internationalisation, engagement).
> _______________________________________________
> release-team gnome org
> https://mail.gnome.org/mailman/listinfo/release-team
> Release-team lurker? Do NOT participate in discussions.