wiki: https://live.gnome.org/FoundationBoard/Minutes/IRC20120912
= Minutes for Foundation IRC Meeting of September 12th, 2012 = == Attendance == * For the board: * Emmanuele * Joanie * Tobi * Shaun * Andreas == Agenda == * Role and scope of the Release Team * Continuation of the discussion from the AGM at GUADEC 2012. * http://www.0d.be/2012/08/03/guadec-2012/ * http://people.gnome.org/~ebassi/01-release-team.pdf - slides deck from the AGM * Clarification of the release rules and scope * http://live.gnome.org/ReleasePlanning/WhatWeRelease * The discussion at the AGM had to be interrupted for time constraints * The community considers the release-team as being in a good position to ensure the cooperation between maintainers in order to release GNOME * Some members of the community also would like to have an "arbiter" to resolve eventual conflicts * The arbiter could be the board, the release team, or a new team * Examples of issues faced by the release team * Deferring the python3 dependency * Acting as support for modules, by promoting them to the official moduleset, and posting semi-regular updates on their status * Communication issues between maintainer * Example: Nautilus UI changes in 3.5 * Is it part of the release team remit to pester maintainers to communicate sweeping changes to a module in the release moduleset? * Another option: revert to a previous version until the regressions are fixed? * This already happens at the feature level (unmet features are pushed to the following cycle) and at the moduleset level (modules are pushed back or removed) * Examples: nautilus-cd-burner, gstreamer-1.0 * Is the release team also in charge of the project's direction? * It would mean having the input or the presence of the design team inside the release team decision making process * Traditionally, the release team's role was to capture consensus in the community * The community sets the direction, and the r-t resolves conflicts between modules * But what if the community thinks that the r-t sets the direction? * Proposal: use GUADEC to set the direction of the project * Every other GUADEC sets the roadmap for the following two years * Reflected also in the accepted talks * Issue: possible marginalization of the maintainers and community members that cannot attend * Prior art: MozCamp * The issue of the direction of the community should be resolved within the community, through high bandwidth communication channels (e.g. GUADEC); after a period of public RFC, the release team is in charge of ensuring that the direction is followed through. * The release team would be the "editor" of the project direction, in terms on maintaining the modulesets that define GNOME * We need a benchmark to verify that the process is followed and it's working * Example of a benchmark for the Testable initiative: in the next round of outreach programs, all students should be able to build GNOME without going through jhbuild pains * Venues of communication * Go back using desktop-devel-list as a development mailing list, and require maintainers to join * desktop-devel-list has been used for multiple communication issues * It is difficult to know who the maintainers are * We could use the DOAP files and publish the current maintainers * '''ACTION''': fredp to publish the list of maintainers extracted from the DOAP files on git.gnome.org * Proposal: use another mailing list for maintainers? * Issue: should it be public? * It should be up to the maintainers to decide * Issue: having yet another mailing list may not be well received * Enforcing the project's direction * The release team is already partly doing that by maintaining the moduleset * How to handle forks? * External forks are not under GNOME's purview * Internal forks should not happen * Maintainance releases from the old 2.x modulesets are not controversial and should not be considered forks * Case study: Nautilus in the 3.6 cycle * Definite lack of communication from the maintainers * Feature proposal period was not used * The rules were not clear for features involving a single project * Changes involved a set of feature removals * Proposal: the feature proposal period should also be used in case of changes involving a single project * Constraints: does it involve removing features? is the module part of core? is the module user visible? * The release team should exercise the option to punt the module out of the release moduleset until regressions are addressed or a sizeable discussion (determined by the release team) happened on the desktop-devel list * Some of the criteria could match the ones we use for the UI freeze requests, but the bar should be set higher * Inclusion of the Commit Digest on Planet GNOME * Requires amending the PGO policy * Not really controversial * Using a separate style to visually differentiate the feed on the Planet * '''ACTION''': Emmanuele to contact the PGO editor to add the commit digest to the Planet, using a slightly modified style == New Action Items == * '''ACTION''': fredp to publish the list of maintainers extracted from the DOAP files on git.gnome.org * '''ACTION''': Emmanuele to contact the PGO editor to add the commit digest to the Planet, using a slightly modified style -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ _______________________________________________ foundation-list mailing list foundation-list@gnome.org https://mail.gnome.org/mailman/listinfo/foundation-list
