Difference between revisions of "ESC meeting minutes 20090309"
(→review of the ESC dashboard) |
|||
(4 intermediate revisions by 3 users not shown) | |||
Line 24: | Line 24: | ||
Heiner presented a evaluation of the DSCM [http://wiki.services.openoffice.org/w/images/c/c0/Esc_dscm_evaluation.odp], [http://wiki.services.openoffice.org/w/images/a/a8/DSCM_evaluation_2009_03.odt] | Heiner presented a evaluation of the DSCM [http://wiki.services.openoffice.org/w/images/c/c0/Esc_dscm_evaluation.odp], [http://wiki.services.openoffice.org/w/images/a/a8/DSCM_evaluation_2009_03.odt] | ||
− | Thorsten Behrens: - git is used broadest, large community, - git learning curve might a little bit steeper, | + | 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 | 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 | Jan: - no addtional tooling for cws with git is required. Heiner: but for milestone information. Jan: prefers git | ||
Line 31: | Line 31: | ||
Rene: preference is git | 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. | 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, | + | 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 | Frank: offers one member of the documentation team for the pilot | ||
− | Nils: agrees to Mathias B., what is our target group, mozilla already desktop | + | 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 | 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 | 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. | + | 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 K.: will look if Canonical can also support hardware if needed. | ||
Mathias H.: do we have success criteria ? | 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. | all: a pilot should last a least two months, we should have a pilot for at least both: git and mercurial. | ||
− | Frank: we need | + | 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 | Nils: mercurial pilot will be sponsored by Hamburg RE | ||
− | Thorsten/ | + | Thorsten/kendy: will sponsor a git pilot |
Matthias K. bzr pilot to be sponsored by bzr team | 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 | Heiner: incremental updated repositories are a prerequisite for a prototype, patches from the pilots will be applied via patchset into subversion | ||
Line 68: | Line 68: | ||
=== review of the ESC dashboard === | === review of the ESC dashboard === | ||
− | <nowiki>(see updates within <</nowiki>[http://wiki.services.openoffice. | + | <nowiki>(see updates within <</nowiki>[http://wiki.services.openoffice.org/wiki/ESC_dashboard http://wiki.services.openoffice.org/wiki/ESC_dashboard]>) |
− | + | ||
=== kick off discussion about changes to published UNO API === | === kick off discussion about changes to published UNO API === | ||
Line 79: | Line 78: | ||
* Stefan: to set up and drive DSCM survey | * 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 | * Martin: make [[FixesOnMaster]] from the ESC Dashboard happen | ||
− | * Thorsten: finalize proposal for deprecating | + | * Thorsten: finalize proposal for deprecating APIs |
+ | |||
+ | [[Category:ESC]] |
Latest revision as of 00:17, 7 April 2009
ESC meeting minutes March 9/10th – 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)
Contents
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