ESC minutes

From Apache OpenOffice Wiki
Jump to: navigation, search

Engineering Steering Committee Agenda and Meetings Minutes

The Engineering Steering Committee meets every two weeks on Monday 4pm UTC ( ,, #oooesc


agenda for next meetings

next meeting: February 2010, in Hamburg


Meeting: November 3th 2009 in Orvieto

time: 3 - 4.30 pm local time location: Orvieto, Centro Studi "Città di Orvieto", Room 2


  • Nils Fuhrmann
  • Martin Hollmichel
  • Matthias Huetsch
  • Dieter Loeschky
  • Rafaella Braconi
  • Michael Meeks
  • Thorsten Behrens
  • Dr. Jin
  • Mathias KLose
  • Rene Engelhard
  • Stefan Taxhet


Dr. Jin takes over the membership from Xuizhi Cheng for RedFlag

coordination on modularization and split build efforts

see,, ("split build patches")

review of the ESC dashboard (

Unified ODF Icons

follow-up to and . agreement is to connect the artists of the various teams (Gnome, KDE, StarOffice, etc.) to get a common look and feel for these icons and take care of the different themes and color schemes of the various desktops at the same time

status of the DSCM migration

Within the ESC the discussion about the pro's were done passionately, there were no serious cons (beside bzr at that time) so that the discussion look like a vi vs. emacs war, but we need to have just one system in the end. So finally, Thorsten and Michael M. made clear during the meeting that there were disappointed about the final outcome but again there was an agreement that mercurial will able to do the job.

Product Planning Coordination (Proposal on

deferred to next meeting

ESC self review

do we work as desired ? areas of improvement ? Work
with CC and community ? For this agenda item it might be useful to have
a follow up meeting during the conference, maybe together with CC to
request and get also feedback from people outside the ESC.

discussion was deferred to next meeting

Meeting: March 9/10th 2009 in Hamburg


Decision on which DSCM we use for the pilot of the transition to a DSCM, please see the result of the poll on


Face2Face meeting: November 4th 2008 in Beijing


  • Nils Fuhrmann
  • Martin Hollmichel
  • Matthias Huetsch
  • Dieter Loeschky
  • Rafaella Braconi
  • Michael Meeks
  • Thorsten Behrens
  • Xiuzhi Cheng


  • preparation of BOF "ESC achievements since Barcelona" (Thursday 6th, 5.15pm)
  • ESC next year goals
  • discussion wrt. including optional components into OO.o builds
  • Review of roles & responsibility of ESC and its members

Face2Face meeting: July 3/4th in Hamburg


Thursday 3rd

intend to attend: Michael Meeks (Novell, via phone), Nils Fuhrmann (Sun), Xuizhi Cheng (Redflag), Mathias Klose (Ubuntu), Young Lin Ma (IBM), Martin Hollmichel (Sun), Rafaella Braconi (Sun)

10 am : welcome

10.30 am : review of the ESC_dashboard, confirmation of agenda

1.30 pm : status of the first step of the SCM migration (CVS to SVN, Heiner Rechtien)

4 pm : roundtable discussion:

  • IBM-Contribution/IBMs needs, are there hurdles which might be resolved with the support of the ESC
  • ESC presentation on OOoCon in Beijing. What should be presented by whom?
  • Future of the ESC. Execution vs. Discussion

Friday 4 th

10 am: various project status: status of the performance improvement efforts, status of modularization and packaging

11 am - 4 pm TBD.

4 pm: close of meeting

review of ESC_dashboard

development roadmap sync.

Face2Face meeting: July 3/4th 2008 in Hamburg


Face2Face meeting: February 18/19th 2008 in Hamburg


Monday 18th:

11 am: review of the ESC dashboard

12.45am: break

1.15 pm: status of global feature pipline: sb's packaging split into ure/product/branding, janneke's widget layouting work, hennings's new msword filter, The ooo11lotusfilter workspace, VBA, improved EMF renderung, T602, MacOSX

2.45 pm: update of SCM discussion

4.30 pm: break

4.45 pm: updates on documentation license

5.30 pm: time for 1:1 and possibility to meet other Hamburg developer

Tuesday 19th:

10 am: shared infrastructure (Gregor to give update on buildbots, Windows build boxes) Slides

12 am: break

1 pm: continue review of ESC dashboard

4 pm: close of meeting

continue work on prioritized list of requirements (leftover from meeting 20071029)

  • discuss documentation license
  • find owners for all tasks
  • ensure all priorities are set
  • determine time line for solutions of issues

Attendees: Mathias Bauer, Rene Engelhard, Martin Hollmichel, Michael Meeks, Matthias Huetsch, Stefan Taxhet, Dieter Loeschky, Nils Fuhrmann, Rafaella Braconi, Frank Peters, Matthias Klose; partly on phone: Caolon McNamara, Xiuzhi Cheng

Review of the ESC_dashboard

Wiki better search: Also a project „Information Sharing“ running to get up guidelines for putting doc into wiki/blogs/mailing lists.

Mailing lists/unsubscribe: take it off the dashboard ? Yes, putting it this to the infrastructure requirements list (AI: Nils).

Language Packs: Rafaella / Frank

Help Content: Online Help/Owner Frank Peters,

Dictionaries to be moved to extensions, technical part has been solved for 3.0, group packaging is still in progress.

Language Fallback: Issue for 3.0, Mathias B, and Matthias Klose to follow up this in the afternoon.

Email access to bugtracking, moving to requirements documents for infrastructure

open source compliance, will send out after documentation license will be more clear.

Unit tests: kendy working on enhancing the to enhance the build to include unit tests in the main build. P2

make high impact bugs reports more visible: P2

developer focus: meeks drop it from the list

fixes on master, last item (trivial fixes ) to worked out in more detail.

Status of global feature pipeline

  • Kay R. Give an overview about the repackaging efforts. They are the first step for further modularization efforts, the three layer packaging is expected to be ready for 3.0, other modularization steps will happen after 3.0
  • widget layout : Michael M. gave a demo with various layout, code changes are already in CVS, localization of strings is work in progress, layout code can be triggered by one macro, built on top the toolkit api, currently limited to dialog, but should be expandable to any window container. Cws awtfixes1, layout01.
  • MBA: OOXML Filter, all three OOXML development work will happen in one cws (xmlfilter03) and will be integrated for OOo 3.0 beta, Work will be not complete until that time, continous enhancements will happen within the next months or years.
  • ooo11lotusfilter workspace: rene: the cws is a mess (e.g. linking with icu, copyright notes in the files) , MBA: started looking into the quality code, Matthias Hütsch: code is based on 1.1.x, next steps to bring them up to date are not determined yet., Meeks asked for participation of IBM in ESC, Loeschky reported that they will come up with nominees.
  • VBA: Andreas Bregas, Noel Power, Pei Feng Lin, Jiao Jianhua are working on that , limited ro EXCEL documents, continous integration of npower0x child workspaces are in progress. In the moment no work for Word has been started yet.
  • improved EMF renderung : Loeschky: is Novell plan to upstream that ? Michael Meeks does not know yet about the efforts to integrate this, he needs to check this.
  • T602, text import filter, pavel working with MBA on the integration, Pavel reported some small issue with this. Plan is to get integrated this for beta.
  • MacOSX on track for release for 3.0, working on some feature (start center) also effecting the other platform to meet the UI/Feature freeze.
  • Gstreamer: Matthias Hütsch: what is the status for this ? Meeks: available under LGPL but no with joint copyright.
  • CLI/mono: Engelhard: vanilla build has CLI binding available only for windows, Mono binding available in ooo-build. For also all Unix, are there plans to upstream ? Climaker has been rewritten in C# (see also Matthias Hütsch: How many QA resources are we able to spend ? Loeschky: It would help to make plan for new features available eraly to avoid duplication of efforts. Meeks to discuss this later as it is a political question. Meeks is happy to upstream the Mono stuff. Loeschky to clarify efforts for reviewing and approving 76642.

SCM review

Heiner presented the result of his and Jan H. paper File:Scm evaluation 2008 02 15.odt

  • looking at the performance numbers gives no clear favorite, Heiner is in favor for svn, Jan for git, Mathias K. Promised to provide numbers for bazaar until end of February,

proposal is to move from CVS to subversion first (possible until July) and to do a final decision once further afterwards. DSCM development is also evolving, also bazaar and mercurial should taken into account, since they had developed quite well in the last year, Michael M. fears that a second step to an DSCM will never happen. Meeks also offer to help with Jan H. to help with any migration. Having a concrete timeline for decision for DSCM might be a compromise, e.g. in a year timeframe for a final move to a DSCM. Meeks asks for open sourcing the EIS stuff since this would allow parallalization of efforts. Fuhrmann: Not generally a problem, but factoring that stuff out from internal framework also binds resources so that there would no benefit on being able to parallize work. But might an valid option for the future. Agreement: move to subversion first, starting now. Also starting re-evaluation of DSCM systems (bzr, git, mercurial) and come within a year timeframe to a final decision for the next generation SCM for OOo. Subversion also offers better migration paths to any of these DSCM.

Update on Documentation license

Rene: problem if that PDL is not free (did not pass the isolated island test, dissident test), looking for the right documentation license, it will not ever become OSI approved license.

Rene to provide link to Frank for judgement of debian-legal list wrt CC licenses (<> ???,

Shared Infrastructure:

Gregors presentation

ESC__buildbot_tasks, Martin to look for additional resources for these tasks.

Meeks: we also want to run unit test on buildbots as well.

Revisit Trivial Fixes on Master

some more detailed wording for trivial fixes on master, see FixesOnMaster. Martin to work with RE to get this implemented.

Review of Infrastructural requirements <>

  • Scalability is an issue, some numbers in the requirement are the base line and are expected to grow.
  • Transitioned Unprioritized list to Uncategorized List

Final wrap up

agreement: these f2f meeting are much more efficient than the biweekly phone calls, proposal is to do the phone calls once a month and continue with the f2f meetings.

Dieter L. proposed a regular review of roadmap on the f2f meeting agenda


participants: Mathias Bauer, Rene Engelhard, Nils Fuhrmann, Matthias Huetsch, Martin Hollmichel, Caolon McNamara, Michael Meeks

  • update on documentation license: MH proposed to use BSD like license for template, Frank Peters to give an update on documentation next f2f meeting
  • create meta issue for long outstanding patches (mmeeks) to determine systematic possiblities for improvement for integration of those and to involve also non ESC member to review those.


participants: Rene Engelhard, Nils Fuhrmann, Martin Hollmichel, Matthias Klose, Dieter Loeschky, Caolon McNamara, Michael Meeks

Work on prioritized list of action Items

it was agreed to close this agenda item now


  • next Face2Face meeting will take place Feb 18/19th in Hamburg. AI for all: prepare input for agenda.
  • Nils asks Matthias K. for participation in the SCM transition meetings
  • Michael worked out list for "being more diverse" -> see dashboard.
  • Michael asks about the status of CVS as authoritative tool for icons. This Item has marked as done in the ESC dashboard, we may need some more clarification about this.
  • Rene/Martin: no update yet regarding the PDL issue.
  • Martin H. to elaborate about the items "Fast turnaround/short build times" in the dashboard since these requirement were presented by Sun.


participants: Mathias Bauer, Rene Engelhard, Martin Hollmichel, Matthias Huetsch, Caolon McNamara, Michael Meeks (partly), Xiuzhi Cheng

Work on prioritized list of action Items

  • Updates are available within the ESC dashboard
  • Rene - Guidelines for OpenSource - not yet finished, have an issue about license for documentation because PDL licensed documents are not fully redistributable


  • Proposal is to do next Face2Face meeting on Feb 18th.
  • Rene raised that the PresenterView Extension is considered as core functionality and should be bundled with the product. Mathias B.: the decision is up to the developer. Matthias H.: In terms of modularization packaging more functionality into extensions. "Core functionality" should not be hided by extensions technology.

new actions items

  • work on agenda for next Face2Face meeting
  • Michael to work out list for being more diverse (e.g. what are non configurable functionalities, branding, etc.)


participants: Mathias Bauer, Nils Fuhrmann, Matthias Huetsch, Dieter Loeschky, Caolon McNamara, Volker Quetschke

Work on prioritized list of action Items

  • Updates are available within the ESC dashboard
  • Dieter: We should think about adding due dates to the dashboard whereever possible

new Action Items

  • Matthias Huetsch: Provide update for the modularization efforts within the ESC dashboard
  • Nils: Ask Frank Peters and Rafaella Braconi to provide updates on their action items within the dashboard and to participate within the next meeting
  • All: Update the dashboard when status of action items changed and add due dates where possible


participants: Mathias Bauer, Nils Fuhrmann, Rafaella Braconi, Rene Engelhard (partly), Matthias Huetsch, Dieter Loeschky (partly), Pavel Janik, Caolon McNamara, Volker Quetschke, Xiuzhi Cheng

action items

  • meet weekly until prioritized list is complete.
    • Processes -- More developer—focus in processes, postponed because high prioritized by Novell and Michael not present
    • Processes -- Easy integration of small fixes/Fast Development Turnaround/Short build times: Martin and Mathias will followup with Michael on this.
    • Processes -- More ways of being diverse in the source code, postponed because high prioritized by Novell and Michael not present
    • Tools and Infrastructure: Open Tools and Infrastructure, community controlled, Owner NF: NF: #Infrastructure requirements will be evaluated in the context of the Sun OpenSource infrastructure efforts
    • [Prioritized list of requirements] has been updated.


participants: Michael Meeks, Nils Fuhrmann, Rene Engelhard, Matthias Huetsch,

action items

  • meet weekly until prioritized list is complete.

regular review of long-term road-blocked patches

calc status bar click

  • mhu: not assigned to anyone 'real'
  • nils: with timeout rules can assume UI approved already
  • mhu: perhaps re-request input, and then timeout
  • mmeeks: so, should assign to a real person & ping UE

Face2Face meeting in Hamburg 2007-10-29/30


[Sun requirements]

[Ubuntu requirements]

[RedFlag2000 requirements]

[Novell requirements]

[Prioritized list of requirements]

[additional notes]


participants: Mathias Bauer, Rene Engelhard, Nils Fuhrmann, Martin Hollmichel, Matthias Huetsch, Matthias Klose, Caolon McNamara, Michael Meeks, Volker Quetschke

  • planning next Face2Face meeting

new action item: Martin to sum up discussion as draft for agenda for Face2Face meeting

2007-09-18 (Barcelona)

participants: Mathias Bauer, Nils Fuhrmann, Martin Hollmichel, Matthias Huetsch, Pavel Janik, Dieter Loeschky, Michael Meeks, Xiuzhi Cheng

action items

  • all: prepare agenda for Barcelona meeting, done
  • Martin: find new slot for Barcelona ESC meeting, done
  • all: How to identify responsible person translation fixes for a particular language: Nils sent out his [answer]

my patch adds a feature: our OASIS engagement

  • scope / timeliness
  • direction
  • credibility

Meeks: there were improvements done on dealing with child workspaces, specifications, but it is still difficult to deal with new features for the native file format, because of the OASIS ODF (Technical Committee) TC.

Hollmichel: asking, if ESC is the right forum to resolve problem in the ODF TC

Meeks: but this is major roadblock for getting simple fixes done and there is a mechanism for feed into TC needed

Huetsch: if you want to change the international standard you have to come with more than patch, thats simply a different scope, it's not a typical barrier of entry

Huetsch: a need for meachanism to feed into OASIS, we can introduce not yet standardized additions but the submitter has to bring it into TC

Loeschky: This is needed because the owner also need to have the IP of the proposed enhancement to bring it into the committee

Bauer: fine granular changes can be introduced anytime, and everybody can drive these efforts

Loeschky: not only ideas but concrete proposals should be brought to the TC

Meeks: problem is that effort for contributing to the TC is much more effort than the patch., but agreed that this has to be addressed by OASIS TC

Loeschky: we (Novell, Sun) will assign engineers to address those issues to the ODF TC.

review of proposed UE process

all agreed that the proposed process is fine.


it was agreed to postpone the remaining agenda items to our regular meeting slots and go for the NLC party.


participants: Mathias Bauer, Michael Bemmer, Nils Fuhrmann, Martin Hollmichel, Matthias Huetsch, Pavel Janik, Dieter Loeschky, Caolan McNamara, Michael Meeks, Volker Quetschke,Xiuzhi Cheng

Inclusion of non-Sun-owned components

  • Meeks: Novell provides strong support for (15+ people) and has also been a major advocate of the JCA (see for example the "sign the JCA today" initiative to draw new developers to the project). However the project has changed and grown since the beginning, so it is worth re-visiting our assumptions around ownership, particularly since the JCA inhibits us from contributing. Novell is unwilling to JCA complete, new, separable modules, we work to create. Specifically there is resistance to give "full" code ownership to Sun but being limited to LGPL ourselves.
  • Meeks: Make it possible to accept code into OOo that is not covered by JCA, like it is already possible for the external project.
  • Bemmer: This is not going to happen. There are good reasons for Sun's copyright ownership.
  • Meeks: This benefits only Sun for all others are limited to LGPL.
  • Bemmer: This will not change and all open source projects Sun has initiated are set up like this.
  • Meeks: We should vote on this.
  • Hollmichel: This is not changeable by a vote.
  • Bemmer: Patches for core functionality, (example Calc solver) do not go into the external component! Core functionality can only be changed by patches that are provided under the JCA and are not going to get integrated into the master otherwise.
  • Meeks: We should get a stronger commit warning to state that the act of committing to CVS, and not eg. nomination implies both Delivery to and Acceptance by Sun, since this was not clear to us. To avoid confusion, in future we are happy to follow that rule. Unfortunately there might be some patches committed already where this was not fully realized by the committer.
  • Bemmer: We are not stealing the existing code, if a patch is not covered by the JCA we are not going to take it.

Regular review of long-term road-blocked patches

fontconfig / font substitution

  • McNamara: Two years for a nice patch that improves functionality.
  • Hollmichel: Some more work on windows is needed, work in progress.

sax bug.

  • Meeks: *presents the case*
  • Loeschky/Huetsch: Someone is looking at this.

calc: merge & center

  • Meeks: *presents the case*
  • Hutsch/Bauer: Only one year old ;)
  • Meeks: There is already activity in the issue.
  • Bauer: It is currently being discussed by User Experience.

hungarian font fix

  • Meeks: *presents the case*
  • Hollmichel: Looks easy. Someone will check and apply.

translation fix

  • Meeks: *presents the case*
  • Meeks: This is a general problem with translation issues.
  • McNamara: For example issue 64726 - What to do with these fixes?
  • Hollmichel: The project owner should assign the patches, but ...

open action items

Prepare agenda for Barcelona meeting

  • Meeks: Will look into it.

Find new slot for Barcelona ESC meeting

  • Hollmichel: No problem, will update the programm.

New item

How to identify responsible person translation fixes for a particular language


participants: Mathias Bauer, Xiuzhi Cheng, Martin Hollmichel, Caolan McNamara, Nils Fuhrmann, Dieter Loeschky, Volker Quetschke, ause

action items

  • Action Item Nils: more info on the status of windows buildbot:

ause reported that the existing Windows build bot will be migrated to newer hardware, the Linux bots seems to be orphaned. Xuizhi reported that two CH2000 engineers are looking on how to setup build boxes for Linux and Windows. If they need assistance, they should use the list.

renew cws policies

  • review of draft of new cws policies (latest version on ). Matthias: naming of high/low impact feature maybe misleading. we will collect suggestion for more descriptive wording offline until Tuesday, Martin will post the latest draft of the policies to the list until Wednesday.

Barcelona ESC meeting

  • Barcelona ESC meeting is currently scheduled for Tuesday morning, most of the members of the ESC will arrive later that day so that a time slot 7-9 pm seems to be more feasible. Martin to contact conference team.
  • action item all: prepare agenda for Barcelona meeting.


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

Finding QA for workspaces

  • thorsten: new way to locate a qa person, 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
  • Nils: action item, more info on the status of windows buildbot
  • Nils: 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.


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.


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

  • 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.


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