ESC meeting minutes 20090309

ESC meeting minutes March 9/10^th – Hamburg

Attendees

• • Matthias Huetsch (Sun)
  • Xiuzhi Cheng (Redflag CH2000, via phone)
  • Dieter Loeschky (Sun, Monday only)
  • Stefan Taxhet (Sun)
  • Mathias Bauer (Sun)
  • Martin Hollmichel (Sun)
  • Eric (Yong Lin) Ma (IBM, Tuesday, via phone)
  • Frank Peters (Sun, Monday)
  • Matthias Klose (Canonical)
  • Nils Fuhrmann (Sun)
  • Thosten Behrens (Novell)
  • Rene Engelhard (Debian)
  • kendy (Novell, during DSCM discussion)
  • Heiner Rechtien (Sun, during DSCM discussion)
  • Kay Ramme (Sun, during API discussion)

Monday

DSCM discussion

Heiner presented a evaluation of the DSCM [1], [2]

Thorsten Behrens: - git is used broadest, large community, - git learning curve might a little bit steeper, but daily usage is easy, flexibility is great.
Matthias H/Thorsten B. big projects (e.g. mozilla, linux kernel, etc) are on both systems: hg and git
Jan: - no addtional tooling for cws with git is required. Heiner: but for milestone information. Jan: prefers git
Matthias K.: unfortunately the import of bzr did not finished yet, would like to see the prototype for all three systems
Stefan: has no preference, is interested in how the backend infrastructure can be managed, practical experience appreciated so running the pilots is interesting
Rene: preference is git
Mathias B.: - majority of Developers are Windows and Mac Users, so it is important to use best system available on these platforms and also including non-code developers in a prototype.
Dieter: let the experts decide, ease of rolling out is important to the project
Frank: offers one member of the documentation team for the pilot
Nils: agrees to Mathias B., what is our target group, mozilla is already desktop oriented application, and they use hg
Matthias H.: this is like a vi vs. emacs discussion, this can last endless
Martin: would like to see a pilot for the candidates before doing a decision
Nils: does it make sense to start the pilot with a reduced set of candidates? This is a matter of resources.
Mathias K.: will look if Canonical can also support hardware if needed.
Mathias H.: do we have success criteria ?
all: a pilot should last a least two months, we should have a pilot for at least both: git and mercurial.
Frank: we need to have a larger set of people doing the pilot to have satisfying data
Nils: mercurial pilot will be sponsored by Hamburg RE
Thorsten/kendy: will sponsor a git pilot
Matthias K. bzr pilot to be sponsored by bzr team
Heiner: incremental updated repositories are a prerequisite for a prototype, patches from the pilots will be applied via patchset into subversion
Martin: also integration back needs to be done natively on the DSCM within the pilot
all: negative success criteria: in case of failure the system is out
martin/kendy: it may be useful to ask contributors for their favorites. these should be educated votes, meaning only opinions based on practical experience should be taken into account
kendy: suggested educated vote of the member of the ESC (educated vote means: every voter need to do a cws in each pilot before give a vote)
nils: is supporting _one_ pilot by RE
majority (5 vs. 2) we will conduct a survey within 3 weeks (Stefan is driving this survey) to consult committers.  we will do an irc meeting on March 30th to decide on which DSCM to start the pilot.

proposal for unified ODF Document icons

Dieter proposed that for ODF unified Document icons should be used, meaning the various application using ODF should use the icons [3]. All agreed that this proposal is good, although some distributors may want to make slight modification to adopt them to their desktop theme.

vanilla OOO Environment set up vs. Hamburg set up (aka configure vs. setsolar) Hamburg needs to take care about autotools

after consultation with ause it was agreed that the configure script should be adopted to serve also the needs of the Hamburg envrionment. Ause and Rene will work on this adoption with the objective to use one set of settings for both setup so that the problem raised by Rene should vanish.

Tuesday

Define Criteria on when to bundle extensions

After short discussion all agreed the engineering is not the main stakeholder for making a proposal for bundling an extension with the product. It is common sense, the the default bundling should be done on exceptional basis and that there should be good compelling reasons to do such bundling. Martin to extract technical criteria/prerequisites from the proposal, so that marketing / User Experience groups can define own rules upon that. The release status meeting should finally the meeting where proposal for bundling should be raised and decided upon.

review of the ESC dashboard

(see updates within <http://wiki.services.openoffice.org/wiki/ESC_dashboard>)

kick off discussion about changes to published UNO API

see [4], it was agreed that this discussion is wanted and needed, Thorsten and Kay to work out some more details.

Action Items

• Stefan: to set up and drive DSCM survey
• Martin: work with marketing and User Experience group to define process on how to decide on bundling of extensions
• Martin: make FixesOnMaster from the ESC Dashboard happen
• Thorsten: finalize proposal for deprecating APIs