Difference between revisions of "ESC minutes"

From Apache OpenOffice Wiki
Jump to: navigation, search
(agenda for next meetings)
(to be continued ...)
Line 55: Line 55:
 
* Nesshof: can continue the rest via E-mail
 
* Nesshof: can continue the rest via E-mail
 
* mmeeks: not interested directly in solving the issues, but understanding them, and learning about process problems from them.
 
* mmeeks: not interested directly in solving the issues, but understanding them, and learning about process problems from them.
 +
* mba: Proposal for "lessons learned from the patches": developers sending patches to UEx/QA whatever should still be considered to be responsible. Developers asked for a code review should react more reliably. If developers feel overwhelmed by a patch they should make this clear.
  
 
=== coordinating the next feature releases ===
 
=== coordinating the next feature releases ===

Revision as of 19:47, 14 May 2007

Engineering Steering Committee Meetings Minutes

The Engineering Steering Committee meets every two weeks on Monday 4pm UTC (http://www.timeanddate.com/worldclock/meeting.html).

agenda for next meetings

2007-05-28

open agenda items

  • OpenOffice.org source control system (SCM): what is the roadmap for the future ?

Minutes

2007-05-14

regular review of long-term road-blocked patches

calc: persist csv import settings

  • mmeeks: walk through of the timeline
  • mba: something that the IRT/IIT metrics don't catch
  • mba: UE team don't track issues regularly & Falko left
  • mmeeks: It seems some people (UE) demand their say, but then don't say anything.
  • mba: didn't we suggest timeouts for non-controversial changes before ? here for User Experience ?
  • mmeeks: yes - but discarded by QA previously, as part of stymied new inclusion work-flow.
  • Nesshof: did you consider mailing dev@specs to ping them ?
  • mmeeks: no; we don't have the issue in our ooo-builds, why burn yet more time here ?

gsl: image shrink - ka009

  • mba: talked to KaiA today, for an explanation. Not a high priority for him, and a wide change, somehow always other higher priority tasks.
  • mmeeks: why such a huge problem for QA ? what would these guys do ?
  • nils: (after introduction) - depends on the change: run the test-tool over it, and poke on specifics identified by the developer. Looked at this CWS - it was resynched many times, but never marked 'Ready for QA'.
  • mmeeks: can we accelerate the QA process with tooling ?
  • mba: plenty of examples of internal Sun CWS' that just never made it, priorities changed etc. Surely Novell can do QA on it themselves ? (perhaps problems with multiple platforms) ?
  • mmeeks: we can do that, but we already ship it to our customers, we tested it ourselves etc. what more needs doing ? we filed up-stream for patch review: no response.
  • mba: patch review is not possible for all patches; huge backlog of them, and the burden is too high.
  • mmeeks: it is not a goal then to review all patches ?
  • mba: no, can't be done for all incoming patches.
  • mmeeks: I expect (from other projects) that there is a maintainer / gate-keeper for all code, that is ultimately responsible, and cares about that code and that has the final say for inclusion; is that not the case in OO.o ?
  • Nesshof: not totally true - project leads should be able to find people with some interest in a piece of code to do some review. The idea is everyone can change any code, there is no dedicated ownership.
  • mba: lots of old code, ~50% of modules may have no maintainer. Mozilla too is extremely slow at responding to patches. Not all Open Source projects have a clear maintainership structure. OO.o can't be compared with anything else, too many millions of lines.
  • mmeeks: well, it's really unusual (in my experience) not to have anyone responsible for each bit of code; it needs documenting.

to be continued ...

  • Nesshof: can continue the rest via E-mail
  • mmeeks: not interested directly in solving the issues, but understanding them, and learning about process problems from them.
  • mba: Proposal for "lessons learned from the patches": developers sending patches to UEx/QA whatever should still be considered to be responsible. Developers asked for a code review should react more reliably. If developers feel overwhelmed by a patch they should make this clear.

coordinating the next feature releases

Clarify what the important issues for the next releases are, who is doing what work, next major version of OpenOffice.org

  • Nesshof: Please update Features page with details.
  • Nesshof: we're looking to do a 3.0 release Q3 2008 (what would be 2.5) - what do people think ?
  • mmeeks: a marketing decision right ?
  • Nesshof: yes, we continue 6monthly releases until then.

coordination of new features

We just experience that two groups Novell and CH2000 are working on the same feature (text grid control)

  • mmeeks: This is an issue of CH2000 not doing their work in a public fashion, Novell consulted, blogged, and took this to the ODF TC.
  • mba: CH2000 mostly doing new feature bits in writer core - want to work on layout.
  • xiuzhi: to avoid the confilt with other voluteers again,I will give a list of new feature we will submited

2007-04-30

participants: cmc, mh, pjanik, vq

1. IRC, Telecon, Telecon/IRC, Skype meetings?

mh will provide dial in number until May 14th Idea: should we try using e.g. Skype?

2. Nils, Xiuzhi and Dieter will be added to the list.

3. AI: mmeeks will provide list of top 10 patches and we will try to cover first 2 - 3 in a meeting ?

Personal tools