Minutes of the GNOME 2.0 Release Team Meeting - 2002/03/08

[hobbit aloss ukuu org uk]

Minutes of the GNOME 2.0 Release Team Meeting - 2002/03/08
==========================================================

Present:			Apologies:
========			==========

Calum Benson			Karl Gaffney
John Fleck 			Jeff Waugh
Jody Goldberg
Jamin Gray			Missing:
Greg Leblanc                    ========
Kjarten Maraas
Michael Meeks 			Seth Nickell
Sander Vesik			Maciej Stachowiak


Completed actions:
==================

  DONE: Michael or Louie to post Sherriffs proposal to hackers/desktop
	=> Michael posted this. 

Previous actions:
=================

  PENDING: Jeff + John to link documentation on dotplan.
        => Same status as last week: still more to go, but many of the docs 
	about API changes are linked on the site now.

  PENDING: Luis to sort out bug reports script for Fridays
	=> Luis away so same as last week: done, needs adding to cron.

  PENDING: Greg to talk to Jacob about merging packaging effort
	=> We (well, the packaging people) now have working specfiles 
	for several packages. They are mostly built and tested on RH but
	they are supposed to be distro-independent and should work on
	any rpm-based system.

  PENDING:  Sander to post module split proposal to hackers/desktop
	=> See discussion below.

  PENDING:  Jody to investigate possibilities and pitfalls associated with
        creating a docs-build module.
	=> Docs people generally in favour, but have not been explicit
	enough about what they'd want from it for work to start. Continued.

  PENDING: Jeff to inform gnome-hackers, desktop-devel-list and so on of
        => change to schedule.
	Jeff to post when he wakes up in his (Australian) tomorrow, which
	is today for the most of the rest of the world. (Saturday AEST, 
	Friday pm for US, Europe and Asia.)

New actions:

  NEW: Telsa to check "xxx to post" actions actually get posted. 

  NEW: Telsa to put out last week's minutes (hmm, quis custodiet?)

  NEW: Telsa to announce Jacob as build sheriff.

  NEW: Jody to email gnome-i18n about "positional arguments" and when
	to be careful with them.

  NEW: Kjarten to email gnome-i18n about new date for string freeze as
 	soon as Jeff has put out the schedule update. 

  NEW: John to write summary of documentation status.

  NEW: Luis to write summary of how bug days and bug-reporting are
	going.

Decisions and discussion:
=========================

* Jacob Berkman is to be build sheriff. Gold star badge to follow.

* Arising out of the matter of module splitting: there seem to be
a lot more unspoken "this is a bad idea: no-one should do this 
without warning" rules which people just assume everyone else
will automatically know. They're not written down anywhere. We 
should come up with a list of such scenarios. This will help 
(a) stop people doing it; and (b) give people an idea of the sort 
of things not to do without warning from which they can just extrapolate.

* string freeze: Kjarten thinks it would certainly take two weeks
to translate all strings for Gnome 2. This does not include docs.
(They are separate and massive.) From his perspective, the strings
within the programs are the critical ones. We can move the strings 
freeze to be one week before RC-1, but we can't safely move it any
further (for exaple, two weeks before the real final release would
be bad). This is because of something called "positional arguments" 
which translators can opt to use. These can break applications. The 
strings freeze does not mean "no more translations" though: it means 
"no more changing strings on translators".

* The "help breakage" thread (desktop-devel-list, gnome-doc-list and
probably more) was discussed. Hallski, jrb and others have an irc meeting 
scheduled for this weekend to thrash this out. John will catch up with 
them after this and find out the results of this. 

* Discussed how fascist we need to be wrt: 
  - new features slipping in: Well, we are in a feature freeze. We 
  are expecting people to be fixing bugs. Obviously one person's bug
  is one other person's feature (the help breakage thread discussion
  threw up one 'but the app can't do this currently' example). But 
  if people come up with what look suspiciously like 'neat features'
  that aren't necessary, then perhaps they should also come up with 
  test assertions. We expect this drastically to cut down on features :) 
  Seriously, the best things we can do are to be consistent and clear. 

  - constantly late packages: typically, 90% of the packages are
  ready for snapshots in good time, and there will be two or three
  we wait on. Can we improve this? No clear consensus. Will continue
  to discuss. 


Telsa