Minutes for Foundation IRC Meeting of September 12th, 2012
Meeting Log
Log available here: 2012-09-12-irc-meeting-log.txt
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://people.gnome.org/~ebassi/01-release-team.pdf - slides deck from the AGM
- Clarification of the release rules and scope
- 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