ESC meeting minutes 20090309
ESC meeting minutes March 9/10th – Hamburg
- 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)
- 1 Monday
- 2 Tuesday
- 3 Action Items
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 . 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.
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 , it was agreed that this discussion is wanted and needed, Thorsten and Kay to work out some more details.
- 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