Re: Holes in the GNOME 3 process - meet in 45 minutes

[Matthias Clasen <matthias clasen gmail com>]

Some notes from the meeting:

1) How do we mark blocker issues in bugzilla ?

The '3.0 blocker summaries' on the product overview pages (eg
http://bugzilla.gnome.org/browse.cgi?product=gtk%2B ) are based on the
'Gnome target' field. It turns out this field is only shown for
certain products, and we need to review our bugzilla categories and
make sure they line up with the new modulesets.

ACTION: send out semiregular blocker bug summaries (andre, kmaraas)
ACTION: review bz category <> moduleset mapping (bkor)
ACTION: ensure that we have bz products for all modules  (bkor)

2) What is the central place on the wiki for 3.0 planning

After reviewing a number of pages on the wiki:
  http://live.gnome.org/ThreePointZero
  http://live.gnome.org/GNOME3
  http://live.gnome.org/TwoPointNinetyone
  http://live.gnome.org/Design/SystemSettings/ToDo30
we concluded that the ThreePointZero page is the most uptodate and
relevant one, so we should add a link from there to the 'standard'
TwoPintNinetyOne release team page, and add relevant content to that
page (eg some of the content of this mail). The GNOME3 page is not
publicly accessible and outdated, and should probably be moved
somewhere else, so that we can make GNOME3 point at the ThreePointZero
page.

ACTION: Add link to ThreePointZero page, add content to
TwoPointNinetyOne, look at moving GNOME3 (mclasen)

3) How do we track outstanding design questions ?

We've had some inconclusive discussion around the state of the HIG,
giving guidance to application authors about GNOME3 integration, and
about tracking outstanding design issues for 3.0. For the
control-center, http://live.gnome.org/Design/SystemSettings/ToDo30
seems to be the place where design progress is tracked. Jon pointed
out that he has written pages about dialog compatibility (
http://live.gnome.org/GnomeShell/Design/Whiteboards/SystemDialogs/Compatibility)
and about status icons
(http://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Compatibility
), and the recent hackfest also produced some tutorial material.

ACTION: Start a wiki page that collects hints for application authors wrt GNOME3

4) Tracking releases and porting issues

ACTION: Send updates on the completion status of various Gnome Goals
about migration (gsettings, gtk3, etc), and about modules that need
2.91.x releases after the next GNOME development releases. (release
team)

5) Who is watching build.gnome.org ?

Some discussion around setting up some additional build slaves. This
is very easy now that a static IP is on longer required. There was
some sentiment that it is good to have some variation in architectures
and OSes, but on the other hand, it doesn't make much sense to have
platforms in the build systems where 'everything is red' unless we
have people who actively work on supporting that platform. It would
certainly be useful to have an Ubuntu system represented.

Some more discussion around ways to make build.gnome.org more useful,
e.g. have email notification about build failures, and try to make
people pay attention to build results.

ACTION: Investigate setting up mail notification (bkor, api)
ACTION: Send regular summaries of build status (mclasen)

6) Can we do something like nightly spins ?

We used to have isos that were produced by rpath at torrent.gnome.org,
but that system is not functional anymore. Ideally, we'd have a way to
use jhbuild to 'build onto an iso'. Unfortunately, we have nobody who
can look into setting this up and keeping it working.

ACTION:  Send a mail that describes the task and asks for volunteers. (owen)