BoF minutes

[Frederic Peters <fpeters gnome org>]

Here's the notes taken during our BoF [I should be back at work in
Brussels next week, I'll then start working on my items.]


        Fred


Release Team BOF - GUADEC 2014
==============================

Attendance:
 - RT: Fred, Andre, Javier, Olav, Matthias
 - (probably not complete) Dennis, Giovanni, Alexandre, Adrien, Elad, Pranav,
   Allan, Mathieu, Kalev

Welcome.

* Moduleset definitions - Core vs core-apps vs apps is confusing.
  Clean it up. Move apps in core to apps. Marketing apps is now done
  via Software. 

** We use/list modulesets/categories in git.gnome.org (browser view,
   needs cleanup), bugzilla.gnome.org, l10n.gnome.org

** @everyone: DO cleanup of categories (+aday)

** @olav: api.gnome.org needs update (api-web git module) - currently
   manual syncing between those infrastructure tools

** @olav: create pre-commit check on doap files (in sysadmin git module)

** Should display which module is part of which moduleset more
   visibly/human-readable, e.g. taking
    https://git.gnome.org/browse/releng/tree/tools/versions or
    http://ftp.gnome.org/pub/GNOME/teams/releng/3.13.4/versions

*** @fredp: publish the modulesets in a human-readable way

** what we expect from external dependencies; how to add new ones?  we
   should write about that. Document this in
   https://wiki.gnome.org/MaintainersCorner

* Feature proposal purpose and we didn't do it last time

** move the start of the period at the time of "The Freeze" (have to
   discuss that with aday)

** @olav: change wording of feature proposal period (heats up=> end of
   discussion, start of proposal => include discussion is open, 2
   deadlines, 1 = end of proposals, 1 = end of discussion)

** contingency plan (on feature pages, like it happens in Fedora)

** use tracker bugs to track feature proposal progress

* Define what release team commits to. E.g. blocker bug pushing

** expectations release team

*** try and tell up front if you don't have time

*** @andre: put regular r-t meetings into schedule. maybe invite
    others e.g. 1 from qa/design. figure out what makes sense (formal
    representation?)

*** @everyone: right now: write up what they do on the release team
    for the last 6 months in
    https://wiki.gnome.org/ReleasePlanning/ReleaseTeamGroup

*** @andre: .0 release meeting reflection: add agenda item to reflect
    on what r-t members did last cycle

*** at beginning of cycle, identify and communicate bug reports which
    we should focus on for the cycle

*** @andre: add regular r-t tasks to schedule. e.g. sending of blocker bugs

*** @andre: split schedule maybe into public and private?

*** @fredp: add deprecation check of existing modules as task

*** @fredp: check (and update)
    https://wiki.gnome.org/ReleasePlanning/MakingARelease

*** break down tasks in more detail so interested folks might be able
    to help or automate things? (e.g. @andre to finish
    https://wiki.gnome.org/AndreKlapper/ReleasePlanningTimeline )

** expectations design team

*** explain to not commit big ui changes just before the freeze

* @olav: Allow change of "gnome target" Bugzilla field by developers of that product

* @olav: change wiki schedule ui (isocalweek, day of week+day of month)

* A way to determine important bugs on bugzilla

* Built-in QA Tests and Automation (Shivani?); gnome-continuous and
  OSTree; working with QA team (cf. blocker bugs)

** @olav: discuss with gnome-continuous to change gnome git workflow.
   maybe have gnome-continuous tag known working versions. have jhbuild
   point to known working versions by default, then people working with
   jhbuild need to specify which modules you're actually working on, for
   the rest just take known working versions

* @fredp: automate mailing changes that happens in the modulesets (new deps...)