Revision as of 15:52, 25 June 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-06-25

• review of draft of new cws policies (latest version on http://ooo.services.openoffice.org/~mh93703/cws-policies-2007_06_25.html )

• meeting in Barcelona ( http://marketing.openoffice.org/ooocon2007/programme/tuesday.html )

open agenda items

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

Minutes

2007-06-11

participants: Thorsten Ziehm, Mathias Bauer, Xiuzhi Cheng, Martin Hollmichel, Caolan McNamara, Michael Meeks, Pavel Janik, Nils Fuhrmann

Finding QA for workspaces

• thorsten: new way to locate a qa person, qa.openoffice.org reorganized to have "Responsibilities" section for each major component, find your qa person there.
• mmeeks: How about qa doing the builds, externally provided ones don't fit qa requirements
• all: build bots would solve this
• what do we need to get them working
• Nesshof: action item, more info on the status of windows buildbot
• Nesshof: who owns the linux ones
• mmeeks: configmgr refactor, loads of work, startup performance improvement. Who to set as qa owner, and how to get it qa-ed. No unit tests exist for it, and no way to add some
• thorsten: normally we'd just run the qa integration tests
• mba: there is some additional uno testing infrastructure available that attempts to use api-coverage of the uno components. Will provide some info offline
•  ???: are we happy to remove the extra unused configmgr stuff
• mba: sure, it's redundant to requirements now

User Experience

Old patches and features stuck on User Experience input

• lutz: We did a review and there are lots of them, the team has shrunk so big backlog
• lutz: Have handled a lot of the backlog, for the future team leads to be enabled to make their own decisions by defining what sort of issues need UE input.
• lutz: Currently working on these guidelines to try and also bring external people into the fold to involve more people in the process.
• Nesshof: new cws policies part of this process revision.
• mmeeks: do we even need specs and qe input into features, just do it, and back it out if QE notes problems
• lutz: in the pre-spec days when we did this, feature confusion, a lot of ping-ponging rolling back and forward developer introduced features
• lutz: but do want to move into more of an adviser role, rather than a feature gatekeeper rule
• mmeeks: reasonable, but means that some issues are ones that are features which can go ahead, and some are ones which are problematic
• lutz: sure, UE will be working to give a *much* faster feedback for less than two weeks
• meeks: can we get a timeout, if greater than two weeks means not a problematic blocker feature
• lutz: yeah, we're agreeable to that

• mmeeks: sometimes developer suggests a little feature, and sometimes then gets asked to extend things to refactor loads of related things.
• lutz: there is that temptation for UE to request a rework of loads of stuff when they think they have a captive developer, but yes we accept it is a snowball thing, we should just go with the original improvement, and then consider separately if we have the resources to do a full rework.
• mba: though sometimes if we're already working on a rework of an area, then adding features that affects that area is a problem
• mmeeks: sure, not a problem

• mmeeks: of course developers do little test features to see if this project is the type that'll take patches and features, and if the little one works out then they will consider bigger ones. So being asked to do mega features straight away is a blocker for them.

• Nesshof: conclusion is that lutz will provide the new document of guidelines.

Regular review of long-term road-blocked patches

double click to rename sheet

• mmeeks: So ignored, comments indicate a requirement for a thousand yard vision of consistency across apps before acceptance. But that's such a minor issue considered against the benefits it gives. Really should have just been integrated immediately. Anyone disagree ?
• lutz: An example where this breaks consistency in our own apps to conform to MS Office refugees. If we follow this road too long then we risk fragmentation of the user's experience. I worry about that.
• mmeeks: In this case the consistency of double clicking on the tab isn't really all that sensible, is it the case that for this issue it is an excuse to get rid of the issue

'thoughtful moment'

trivial warning fix

• mba: patch for code that isn't used anymore
• mmeeks: but blocks compiling as it breaks our build system
• mba; yeah, there's no reason to integrate it

trivial warning fix

• same as before *
• meeks: we could just take care of them in a cws, but so much process
• Nesshof: we'll be bringing in a faster system for this type of developer only impact bug type

-dontstrip installer option

• mba: but it is marked as integrated, what is the problem
• mmeeks: some confusion in this issue, will refile to get this clarified.

2007-05-28

participants: Mathias Bauer, Xiuzhi Cheng, Martin Hollmichel, Caolan McNamara, Michael Meeks, Volker Quetschke,

Problems of build creation / provision for QA

• Nesshof: chicken & egg problem - not used much so not that reliable.
• cmc: Tried to use Sun-Win1 once, but took a whole day to build, and not reliable. Need ability to patch out known bugs in the master.
• Nesshof: poke ChristianL / the tinderbox mailing list, we need a common effort to make it work.
• cmc: the Mac tinderboxes work really well, well maintained, great to see.
• mmeeks: what does 'we' mean wrt. common effort.
• Nesshof: mainly ChristianL
• mmeeks: it is the Sun requirement for 2 platforms that kills lots of incoming CWS' though
• Nesshof: ause maintains Sun-Win1, xp-1-3 are ex. Intel & dead.
• cmc: while can make Win32 builds with LCC etc. now - huge effort & when Vista arrives - ~impossible.
• vq: can volunteer to do CWS builds for individuals occasionally
• mmeeks: best to have a repeatable, automated process: why does Sun have a totally separate, internal process so they don't share the pain / testing / benefits ?
• mba: there are shared developer machines inside Sun for CWS building - but highly loaded, not using build-bot, and building with the StarOffice pieces.
• Nesshof: new win32 build machine coming, perhaps can get one more from OO.o Ev. - 2 should do perhaps.
• mmeeks: would be good if Sun people could use it too; to share the fun.

Finding QA for workspaces

• cmc: how do you find the right QA engineer for a workspace ?
• mmeeks: the canonical page is: DomainDeveloper
• cmc: but surely these guys don't just want these to drop out of the blue ?
• Nesshof: postpone until next time for Nils.
• mmeeks: anything else ? RCS discussion ?
• Nesshof: postpone RCS discussion until ready.

regular review of long-term road-blocked patches

fpicker problems

• cmc: the process required a build on 2 Unix's including Solaris - the build-bot wouldn't work, gave up in disgust / deleted the CWS many months ago. It would be nice to have a policy change - if a change affects only Unix - we need only build it on one Unix platform: not Win32 too.
• mba/mmeeks: rant elided.
• mba: It's clear (to a developer) no Win32 code touched here at all, Unix/Gtk+ only fpicker change < later mmeeks note: the multi-selection fix, also touched core code ... >
• cmc: not doing the work again here; simply not touching this.
• mba: need to ask Nils: getting an exception from dual-platform builds for this case: seems acceptable to me.
• mmeeks: interesting that the experience here turned a friendly, rational, balanced person against touching this again: consider if cmc was not paid to work with OO.o.

calc: improved formula entry

• mba: as before, pushed to user-experience, has specification, no action for 6 months, type changed so doesn't show in statistics. As we discussed before having a time-out for user-experience seems to make sense. User experience very busy, lots of scattered incoming requests, need chasing sometimes.
• mmeeks: we should get Lutz to the next meeting to discuss. Having said that, do you really believe that the calc team are unaware of the likelihood of getting a response from UE ?

autofilter options

• mba: awaiting user-experience input again - now nearly 1/2 of bugs we've seen in this state.

password dialog itch

mba: re-assigned to 'requirements' - 'requirements' is a nonsense. cmc: requirements is a useful dumping ground for crack-smoking bugs: someone else gets to let the people down. mba: in writer, I review all of the 'requirements' bugs myself carefully. Easy to fix though - I'll re-assign to someone I know can take this, trivial patch anyway.

auto-correction fix

• mmeeks: 2+ years waiting for user-experience feedback. A very common problem: almost ~all users of calc (or impress) will face & fight this. Punt discussion until we have Lutz.

2007-05-14

participants: Mathias Bauer, Xiuzhi Cheng, Martin Hollmichel, Pavel Janik, Caolan McNamara, Michael Meeks, Nils Fuhrmann, Volker Quetschke,

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 until now also 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: it's the goal but we can't guarantee an integration in a defined time frame; we also have to fight against the backlog (the issues discussed here mostly belong to it)
• 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, some modules may have no assigned maintainer that knows the code as well as the original developers. Code reviews alone don't guarantee fast integration of patches. Mozilla is a project with excessive use of code reviews. It is notorious to be slow at responding to patches. Not all Open Source projects have a clear maintainership structure. OO.o can't be compared with anything else, mainly due to its history, but also because of its 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: Writer developers of CH2000 mostly doing bug fixes and new feature bits in writer core and layout. We will discuss all work done together with them on the dev mailing list of the sw project.
• xiuzhi: to avoid the confilt with other volunteers again,I will give a list of new features we will submit to OOo.

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 ?