Apache OpenOffice Wiki - User contributions [en]

ESC minutes

2007-08-28T22:16:40Z

Vq: Small addendum.

Engineering Steering Committee Meetings Minutes

The Engineering Steering Committee meets every two weeks on Monday 4pm UTC (http://www.timeanddate.com/worldclock/meeting.html , http://www.google.com/calendar/embed?src=k4bgtc8bil9cs2a77lhh1r998g%40group.calendar.google.com).

= agenda for next meetings =

== 2007-09-10 ==
=== Regular review of long-term road-blocked patches ===
* ?

== open action items ==

* all: prepare agenda for Barcelona meeting.

* Martin: find new slot for Barcelona ESC meeting.

* all: How to identify responsible person translation fixes for a particular language.

== open agenda items ==

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

= Minutes =

== 2007-08-27 ==

participants: Michael Bemmer, Martin Hollmichel, Pavel Janik, Caolan McNamara, Michael Meeks, Volker Quetschke

=== Inclusion of non-Sun-owned components ===
* Meeks: Novell provides strong support for OpenOffice.org (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) but there is also resistance to provide "new functionality" patches because of the JCA. Specifically there is resistance to give "full" code ownership to Sun but being limited to LGPL themselves.
* Meeks: Make it possible to accept code into OOo that is not covert 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 of Sun's open source projects are setup 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 everything that gets committed to a CWS needs to be covered by a JCA and cannot be committed otherwise. This is an active act and by committing this rule is accepted. The consequence of this is that "new functionality" patches are not going to get committed to a CWS anymore. Unfortunately there might be some patches committed already where this was not fully realized by the committer.
* Bemmer: We are not ''stealing'' the 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 ===

==== [http://www.openoffice.org/issues/show_bug.cgi?id=54603 fontconfig / font substitution] ====
* McNamara: Two years for a nice patch that improves functionality.
* Hollmichel: Some more work on windows is needed, work in progress.

==== [http://www.openoffice.org/issues/show_bug.cgi?id=66693 sax bug.] ====
* Meeks: *presents the case*
* Loeschky/Huetsch: Someone is looking at this.

==== [http://www.openoffice.org/issues/show_bug.cgi?id=67243 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.

==== [http://www.openoffice.org/issues/show_bug.cgi?id=71452 hungarian font fix] ====
* Meeks: *presents the case*
* Hollmichel: Looks easy. Someone will check and apply.

==== [http://www.openoffice.org/issues/show_bug.cgi?id=74881 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 ====

== 2007-06-25 ==

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

=== action items ===

* Action item Lutz: lutz will provide the new document of guidelines (Done): http://wiki.services.openoffice.org/wiki/HowTo_Request_User_Experience_Assistance

* 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 tinderbox@tools.openoffice.org list.

=== renew cws policies ===

* review of draft of new cws policies (latest version on http://ooo.services.openoffice.org/~mh93703/cws-policies-2007_06_25.html ). 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 dev@openoffice.org 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.

== 2007-06-11 ==

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, 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
* 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 [http://wiki.services.openoffice.org/wiki/HowTo_Request_User_Experience_Assistance guidelines] to try and also bring external people into the fold to involve more people in the process.
* Nesshof: new [http://ooo.services.openoffice.org/~mh93703/cws-policies-2007_06_11.html 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 ===

==== [http://www.openoffice.org/issues/show_bug.cgi?id=45245 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'

==== [http://www.openoffice.org/issues/show_bug.cgi?id=49385 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

==== [http://www.openoffice.org/issues/show_bug.cgi?id=49351 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

==== [http://www.openoffice.org/issues/show_bug.cgi?id=48814 -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#QA_Engineers|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 ===
==== [http://www.openoffice.org/issues/show_bug.cgi?id=63263 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.
==== [http://www.openoffice.org/issues/show_bug.cgi?id=20496 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 ?

==== [http://www.openoffice.org/issues/show_bug.cgi?id=35578 autofilter options] ====

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

==== [http://www.openoffice.org/issues/show_bug.cgi?id=21923 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.

==== [http://www.openoffice.org/issues/show_bug.cgi?id=35338 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 ===
==== [http://www.openoffice.org/issues/show_bug.cgi?id=3687 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 ?

==== [http://www.openoffice.org/issues/show_bug.cgi?id=66680 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 ?

ESC minutes

2007-08-28T17:20:57Z

Vq: /* Inclusion of non-Sun-owned components */

Engineering Steering Committee Meetings Minutes

The Engineering Steering Committee meets every two weeks on Monday 4pm UTC (http://www.timeanddate.com/worldclock/meeting.html , http://www.google.com/calendar/embed?src=k4bgtc8bil9cs2a77lhh1r998g%40group.calendar.google.com).

= agenda for next meetings =

== 2007-09-10 ==
=== Regular review of long-term road-blocked patches ===
* ?

== open action items ==

* all: prepare agenda for Barcelona meeting.

* Martin: find new slot for Barcelona ESC meeting.

* all: How to identify responsible person translation fixes for a particular language.

== open agenda items ==

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

= Minutes =

== 2007-08-27 ==

participants: Michael Bemmer, Martin Hollmichel, Pavel Janik, Caolan McNamara, Michael Meeks, Volker Quetschke

=== Inclusion of non-Sun-owned components ===
* Meeks: Novell provides strong support for OpenOffice.org (15+ people) but there is resistance to provide "new functionality" patches because of the JCA. Specifically there is resistance to give "full" code ownership to Sun but being limited to LGPL themselves.
* Meeks: Make it possible to accept code into OOo that is not covert 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.
* Meeks: We should vote on this.
* Hollmichel: This is not changeble 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 everything that gets committed to a CWS needs to be covered by a JCA and cannot be committed otherwise. This is an active act and by committing this rule is accepted. The consequence of this is that "new functionality" patches are not going to get committed to a CWS anymore. Unfortunately there might be some patches committed already where this was not fully realized by the committer.
* Bemmer: We are not ''stealing'' the 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 ===

==== [http://www.openoffice.org/issues/show_bug.cgi?id=54603 fontconfig / font substitution] ====
* McNamara: Two years for a nice patch that improves functionality.
* Hollmichel: Some more work on windows is needed, work in progress.

==== [http://www.openoffice.org/issues/show_bug.cgi?id=66693 sax bug.] ====
* Meeks: *presents the case*
* Hollmichel: Someone is looking at this.

==== [http://www.openoffice.org/issues/show_bug.cgi?id=67243 calc: merge & center] ====
* Meeks: *presents the case*
* Hollmichel: Only one year old ;)
* Meeks: There is already activity in the issue.
* Hollmichel: It is currently being discussed by User Experience.

==== [http://www.openoffice.org/issues/show_bug.cgi?id=71452 hungarian font fix] ====
* Meeks: *presents the case*
* Hollmichel: Looks easy. Someone will check and apply.

==== [http://www.openoffice.org/issues/show_bug.cgi?id=74881 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 ====

== 2007-06-25 ==

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

=== action items ===

* Action item Lutz: lutz will provide the new document of guidelines (Done): http://wiki.services.openoffice.org/wiki/HowTo_Request_User_Experience_Assistance

* 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 tinderbox@tools.openoffice.org list.

=== renew cws policies ===

* review of draft of new cws policies (latest version on http://ooo.services.openoffice.org/~mh93703/cws-policies-2007_06_25.html ). 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 dev@openoffice.org 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.

== 2007-06-11 ==

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, 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
* 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 [http://wiki.services.openoffice.org/wiki/HowTo_Request_User_Experience_Assistance guidelines] to try and also bring external people into the fold to involve more people in the process.
* Nesshof: new [http://ooo.services.openoffice.org/~mh93703/cws-policies-2007_06_11.html 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 ===

==== [http://www.openoffice.org/issues/show_bug.cgi?id=45245 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'

==== [http://www.openoffice.org/issues/show_bug.cgi?id=49385 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

==== [http://www.openoffice.org/issues/show_bug.cgi?id=49351 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

==== [http://www.openoffice.org/issues/show_bug.cgi?id=48814 -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#QA_Engineers|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 ===
==== [http://www.openoffice.org/issues/show_bug.cgi?id=63263 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.
==== [http://www.openoffice.org/issues/show_bug.cgi?id=20496 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 ?

==== [http://www.openoffice.org/issues/show_bug.cgi?id=35578 autofilter options] ====

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

==== [http://www.openoffice.org/issues/show_bug.cgi?id=21923 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.

==== [http://www.openoffice.org/issues/show_bug.cgi?id=35338 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 ===
==== [http://www.openoffice.org/issues/show_bug.cgi?id=3687 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 ?

==== [http://www.openoffice.org/issues/show_bug.cgi?id=66680 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 ?

ESC minutes

2007-08-28T17:20:16Z

Vq: Add 27.08.2007 minutes

Engineering Steering Committee Meetings Minutes

The Engineering Steering Committee meets every two weeks on Monday 4pm UTC (http://www.timeanddate.com/worldclock/meeting.html , http://www.google.com/calendar/embed?src=k4bgtc8bil9cs2a77lhh1r998g%40group.calendar.google.com).

= agenda for next meetings =

== 2007-09-10 ==
=== Regular review of long-term road-blocked patches ===
* ?

== open action items ==

* all: prepare agenda for Barcelona meeting.

* Martin: find new slot for Barcelona ESC meeting.

* all: How to identify responsible person translation fixes for a particular language.

== open agenda items ==

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

= Minutes =

== 2007-08-27 ==

participants: Michael Bemmer, Martin Hollmichel, Pavel Janik, Caolan McNamara, Michael Meeks, Volker Quetschke

=== Inclusion of non-Sun-owned components ===
* Meeks: Novell provides strong support for OpenOffice.org (15+ people) but there is resistance to provide "new functionality" patches because of the JCA.
Specifically there is resistance to give "full" code ownership to Sun but being limited to LGPL themselves.
* Meeks: Make it possible to accept code into OOo that is not covert 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.
* Meeks: We should vote on this.
* Hollmichel: This is not changeble 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 everything that gets committed to a CWS needs to be covered by a JCA and cannot be committed otherwise. This is an active act and by committing this rule is accepted. The consequence of this is that "new functionality" patches are not going to get committed to a CWS anymore. Unfortunately there might be some patches committed already where this was not fully realized by the committer.
* Bemmer: We are not ''stealing'' the 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 ===

==== [http://www.openoffice.org/issues/show_bug.cgi?id=54603 fontconfig / font substitution] ====
* McNamara: Two years for a nice patch that improves functionality.
* Hollmichel: Some more work on windows is needed, work in progress.

==== [http://www.openoffice.org/issues/show_bug.cgi?id=66693 sax bug.] ====
* Meeks: *presents the case*
* Hollmichel: Someone is looking at this.

==== [http://www.openoffice.org/issues/show_bug.cgi?id=67243 calc: merge & center] ====
* Meeks: *presents the case*
* Hollmichel: Only one year old ;)
* Meeks: There is already activity in the issue.
* Hollmichel: It is currently being discussed by User Experience.

==== [http://www.openoffice.org/issues/show_bug.cgi?id=71452 hungarian font fix] ====
* Meeks: *presents the case*
* Hollmichel: Looks easy. Someone will check and apply.

==== [http://www.openoffice.org/issues/show_bug.cgi?id=74881 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 ====

== 2007-06-25 ==

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

=== action items ===

* Action item Lutz: lutz will provide the new document of guidelines (Done): http://wiki.services.openoffice.org/wiki/HowTo_Request_User_Experience_Assistance

* 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 tinderbox@tools.openoffice.org list.

=== renew cws policies ===

* review of draft of new cws policies (latest version on http://ooo.services.openoffice.org/~mh93703/cws-policies-2007_06_25.html ). 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 dev@openoffice.org 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.

== 2007-06-11 ==

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, 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
* 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 [http://wiki.services.openoffice.org/wiki/HowTo_Request_User_Experience_Assistance guidelines] to try and also bring external people into the fold to involve more people in the process.
* Nesshof: new [http://ooo.services.openoffice.org/~mh93703/cws-policies-2007_06_11.html 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 ===

==== [http://www.openoffice.org/issues/show_bug.cgi?id=45245 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'

==== [http://www.openoffice.org/issues/show_bug.cgi?id=49385 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

==== [http://www.openoffice.org/issues/show_bug.cgi?id=49351 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

==== [http://www.openoffice.org/issues/show_bug.cgi?id=48814 -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#QA_Engineers|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 ===
==== [http://www.openoffice.org/issues/show_bug.cgi?id=63263 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.
==== [http://www.openoffice.org/issues/show_bug.cgi?id=20496 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 ?

==== [http://www.openoffice.org/issues/show_bug.cgi?id=35578 autofilter options] ====

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

==== [http://www.openoffice.org/issues/show_bug.cgi?id=21923 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.

==== [http://www.openoffice.org/issues/show_bug.cgi?id=35338 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 ===
==== [http://www.openoffice.org/issues/show_bug.cgi?id=3687 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 ?

==== [http://www.openoffice.org/issues/show_bug.cgi?id=66680 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 ?

DomainDeveloper

2006-12-24T04:35:51Z

Vq: Update personal entry

A mapping of names to OOo accounts.

Abbrev.:

* PL : Project Lead
* CL : Project Co-Lead
* CC : Community Council Member
* ESC : Engineering Steering Committee Member
* CVS : has write access to the OOo CVS repository

----

=== Developers ===

{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
! Name || CVS || @openoffice.org || [[IRC Communication]] || Notes || Affiliation
|-
| || || || || ||
|-
| Volker Ahrendt|| X || va||||||Sun Microsystems
|-
| Kai Ahrens|| X || ka || Kai_Ahrens ||PL Graphic Applications||Sun Microsystems
|-
| Gene Anaya|| || ganaya||||||
|-
| Joost Andrae|| X || ja||ja||CL qa, release testing en-US builds and releasing builds||Sun Microsystems
|-
| Eric Bachard|| X || ericb||ericb2||Mac OSX/Linux PPC ports/CL porting||French OOo project
|-
| Kai Backman|| || kaib ||KaiB||||
|-
| Sascha Ballach|| X || sab||||||
|-
| Jayant Balraj Madavi|| || jayant_madavi||aZEN_JM||Connectivity / Database||Novell, Inc.
|-
| Jörg Barfurth|| X || jb||JoergB||Configuration Util||Sun Microsystems
|-
| Mathias Bauer|| X || mba||||PL Framework, XML||Sun Microsystems
|-
| Thorsten Behrens|| X || thb||thorsten||vcl/impress/toolkit visionary||Sun Microsystems
|-
| Thomas Benisch|| X || tbe||||Scripting framework||Sun Microsystems
|-
| Stefan Bergmann|| X || sb||||CL UDK, tools&UCB hacker||Sun Microsystems
|-
| Andreas Bille|| X || abi||||||Sun Microsystems
|-
| Éric Bischoff|| X || ebischoff||ebischoff||KDE A/B driver||Bureau Cornavin
|-
| Nick Blievers|| X || nick||||IRIX||
|-
| Daniel Boelzle|| X || dbo||||UNO core/bridges/packages||Sun Microsystems
|-
| Oliver Bolte|| X || obo||||RE||Sun Microsystems
|-
| Rafaella Braconi|| || coni||||CL l10n, globalization program manager||Sun Microsystems
|-
| Michael Brauer|| X || mib||||PL XML||Sun Microsystems
|-
| Oliver Braun|| X || obr||obr||System Integration/Accessibility Hacker||Sun Microsystems
|-
| Andreas Bregas|| X || ab||||StarBasic||Sun Microsystems
|-
| Jörg Brunsmann|| || jbrunsmann||||UDK||
|-
| Jörg Budischewski|| || jbu||PyUNO hacker||||Sun Microsystems
|-
| Peter Burow|| X || pb||UI||||Sun Microsystems
|-
| Aidan Butler|| || aidan||||XML filters||
|-
| Giuseppe Castagno || X || beppec56 || beppec56_ or beppe_c || PDF output
|-
| Scott Carr|| || kcarr||kcarr||Documentation||Progbits
|-
| Colin Charles|| || drbyte||bytee||Malaysian native-lang project||bytebot.net
|-
| Behrend Cornelius|| X || bc||||Wizards||Sun Microsystems
|-
| Michael Cziebalski|| || mci||||||
|-
| [[User:pdefilippis|Pierre de Filippis]]|| X || pdefilippis||aliscafo||Mac OSX native porting||
|-
| Andrew Dent|| X ||ace_dent||ace_dent||ui/custom_images||
|-
| Naren Devaiah|| || ||ndev||Performance||Intel Corporation
|-
| Nitin Dongre|| || ||nitin_BITS||||Novell, Inc.(intern)
|-
| Radek Doulik|| || radekdoulik||rodo_||Canvas hacker||Novell, Inc.
|-
| Carsten Driesner|| X || cd||||Framework||Sun Microsystems
|-
| Herbert Duerr|| X || hdu||hdu_hh||GSL||Sun Microsystems
|-
| Oliver Düsterhoff|| X || od||Writer||||Sun Microsystems
|-
| Bernd Eilers|| X || bei||rfc821||EIS||Sun Microsystems
|-
| René Engelhard|| X || rene||_rene_||config_office, Debian packager||Debian
|-
| Andre Fischer|| X || af||||Impress||Sun Microsystems
|-
| Uwe Fischer || || ufi || || || Sun Microsystems
|-
| Ken Foskey|| || waratah||waratah||config_office/dmake man||slug.org.au
|-
| Duncan Foster|| || dfoster||||||
|-
| David Fraser|| || davidfraser||davidfraser||South African translations, multilingual builds||translate.org.za
|-
| Nils Fuhrmann|| || nf||||Localization||Sun Microsystems
|-
| Martin Gallwey|| X || mtg||marty_||XML/Writer/packaging||
|-
| Pierre-Andre Galmes || || pagalmes || pagalmes || Chart2 ||
|-
| Tony Galmiche|| X || tonygalmiche||||CL FR native-lang project||
|-
| Sunil Gandhi|| || ||tyro||||NOSIP
|-
| Sophie Gautier|| X || sgauti|| sophi ||PL FR native-lang project, CC ||.
|-
| Vladimir Glazounov|| X || vg||||RE||Sun Microsystems
|-
| Laurent Godard || X || laurentgodard || lgodard || CC, PL Extensions, Fr Native-lang Project || inDesko/Nuxeo
|-
| Jody Goldberg|| X || jodygoldberg||jody||[[Calc]] spreadsheet-ness||Novell, Inc.
|-
| Dirk Grobler|| X || dg||||Database Access||Sun Microsystems
|-
| Bettina Haberer|| || bh||||RFEOwner||Sun Microsystems
|-
| Ingrid Halama|| X || iha||||Chart||Sun Microsystems
|-
| Chris Halls|| X || haggai||haggai||Debian packager&misc. hacker||Credativ Ltd., Debian
|-
| Gregor Hartmann|| X || gh|| Lachs ||Testtool||Sun Microsystems
|-
| Bustamam Harun|| || bustamam||||Malaysian stuff||
|-
| Kevin Hendricks|| X || khendricks||||PL Lingucomponent, PowerPC||
|-
| Con Hennessy|| || cphennessy||cph2 or cph_||hacker & former council person||OpenApp
|-
| Ivo Hinkelmann|| X || ihi||ivo||l10n tooling/general/RE||Sun Microsystems
|-
| Eric Hoch|| X || maveric||mav_eric||Mac Porting||
|-
| [[User:Lutz_Hoeger|Lutz Hoeger]]|| || lho||lutzh||[[User Experience]]||Sun Microsystems
|-
| Jan Holešovský|| X || kendy||kendy||KDE integration||Novell, Inc.
|-
| Martin Hollmichel|| X || mh||Ratte/Nesshof||Build Maestro, PL External, Tools, Porting, CC||Sun Microsystems
|-
| Karl Hong|| X || khong||||i18n, CJK expert||Sun Microsystems
|-
| Matthias Huetsch|| X || mhu||||Performance/strategy, PL UCB, CC, ESC||Sun Microsystems
|-
| Michael Hönnig|| X || mi||||PL API||
|-
| [[User:icobgr|Hristo Hristov]] || || icobgr || icobgr || PL Bulgarian native-lang project ||
|-
| Sven Jacobi|| X || sj||||Escherwizard||Sun Microsystems
|-
| Jörg Jahnke|| || jj||||Internal tooling||Sun Microsystems
|-
| Christian Jansen|| || cj ||||Menu and Toolbar?||Sun Microsystems
|-
| Ocke Janssen|| X || oj||Base||||Sun Microsystems
|-
| Pavel Janík|| X || pjanik||paveljanik||PL Czech native-lang project, CL l10n, CC, ESC, l10n builds||
|-
| Berry Jia|| X || berryjia||||||Sun Microsystems
|-
| Pascal Junck|| || pjunck||||||Sun Microsystems
|-
| Peter Junge|| X || pj|| peter13j|| OOo community contact for my Chinese Employer, QA||Beijing Redflag CH2000
|-
| Christian Junker|| || Cyb||christianju||API||Trees For Life
|-
| Hirano Kazunari|| || khirano||||Japanese||
|-
| Dhananjay Keskar|| X || dkeskar ||dkeskar||Performance,Buildbot,cat-herder||Intel Corporation
|-
| Robert Kinsella|| || rkinsella||||||Sun Microsystems
|-
| Volodymyr Khrystynych|| || volody||||XML Filter||
|-
| Matthias Klose|| || doko||doko||Ubuntu, gcc, python packager||Canonical, Inc.
|-
| Laszlo Kovacs|| || lkovacs||||Documentation||
|-
| Martin Kretzschmar|| X || mkretzschmar||martink||Gnome / Debian||Student
|-
| Will Lachance|| || wlach||wlach_||Word Perfect File Filters||Net Integration Technologies, Inc.
|-
| Thomas Lange|| X || tl||||||Sun Microsystems
|-
| Lars Langhans|| X || lla||||||Sun Microsystems
|-
| Hans-Joachim Lankenau|| X || hjs||ause||dmake makefile expert, RE||Sun Microsystems
|-
| Németh László|| X || nemeth||||PL lingucomponent||
|-
| Michael Leibowitz|| X || mikeleib ||mikeleib||performance||Intel Corporation
|-
| Wind Li|| X || windly||||Address books||
|-
| Ping Liao|| || pliao||||||
|-
| Tor Lillqvist|| X || tml||tml_||||Novell, Inc.
|-
| Joachim Lingner|| X || jl||||Java, CLI||Sun Microsystems
|-
| Christian Lippka|| X || cl||ChristianL||Graphic Applications||Sun Microsystems
|-
| Mindy Liu|| || mindyliu||||||
|-
| Dieter Loeschky|| X || ||||Localization||Sun Microsystems
|-
| Philipp Lohmann|| X || pl||pl_hh||VCL/X11 (GSL) hacker||Sun Microsystems
|-
| Jackson Low|| X || xxjack12xx||||Porting||
|-
| Patrick Luby|| || pluby||||Mac||
|-
| Prasad Madhav || X || pmadhav || pmadhav || Buildbot || Intern@Intel
|-
| Babak Mahbod|| || bmahbod||||||
|-
| Martin Maher|| || mmaher||||Writer & Filter chap||
|-
| Nakata Maho|| X || maho||_maho_||PL QA, FreeBSD guy||Independent
|-
| John Marmion|| X || jmarmion||||||
|-
| Andreas Martens|| X || ama||||PL Writer||Sun Microsystems
|-
| [[User:smsm1|Shaun McDonald]] || X || smsm1 || shaunmcdonald || Mac Port, buildbot MacPort1 || Student
|-
| Caolán McNamara|| X || cmc||caolan||CL Writer & Filter man||RedHat, Inc.
|-
| Michael Meeks|| X || mmeeks||michael_||ugly hack-er, ESC||Novell, Inc.
|-
| Frank Meies|| X || fme||||Writer||Sun Microsystems
|-
| Federico Mena-Quintero|| || federicomena||federico||perfectionist||Novell, Inc.
|-
| Michael Mi|| || mmi||||||
|-
| Björn Milcke|| X || bm||bm_||Chart||Sun Microsystems
|-
| Petr Mladek|| || pmladek||pmladek||SUSE RPMs, ooo-build releases||Novell, Inc.
|-
| Cyrille Moureaux|| X || cyrillem||Cyrille||||Sun Microsystems
|-
| [[User:Mmp|Matthias Müller-Prove]]|| || mmp|| mprove|| [[User Experience]] Engineer, http://ui.openoffice.org || Sun Microsystems
|-
| Niklas Nebel|| X || nn||||PL [[Calc]]||Sun Microsystems
|-
| Christoph Neumann|| X || cn||||API tests||Sun Microsystems
|-
| NicelKM|| X || mnicel||nicel||||Novell, Inc.
|-
| Bertram Nolte|| || bnolte||||||
|-
| Tomas O'Connor|| || toconnor||||Scripting Framework||
|-
| Lars Oppermann|| X || lo||||||Sun Microsystems
|-
| Rodrigo Parra Novo|| X || rodarvus||rodarvus||Gnumeric/Abiword OpenDocument Format support and port to Maemo||INdT (Instituto Nokia de Tecnologia)
|-
| Edward Peterlin|| X || OPENSTEP||||Mac||
|-
| Frank Peters|| X || fpe||||Documentation||Sun Microsystems
|-
| Christof Pintaske|| X || cp||||||Sun Microsystems
|-
| Ron Piterman|| || rpiterman||||||
|-
| Noel Power|| || npower||noelp||VBA Interop, Scripting||Novell, Inc.
|-
| Nikolai Pretzell|| X || np || ||Autodoc, code quality||Sun Microsystems
|-
| Volker Quetschke|| X || vq||vq||W32-tcsh/bash build environment and dmake Hacker, ESC||Gravity Waves
|-
| Tino Rachui|| X || tra||tinor||GSL/Unix Hacker||Sun Microsystems
|-
| [[User:Kr|Kay Ramme]]|| X || kr||||PL UDK||Sun Microsystems
|-
| [[User:ErAck|Eike Rathke]]|| X || er||erAck||CL [[Calc]], engine; CL i18n; stricken with number formatter||Sun Microsystems
|-
| Michael Rauch|| X || mrauch||||NetBSD||
|-
| Jens-Heiner Rechtien|| X || hr||blauwal||RE; OOo SCM (CVS, CWS tooling); Porting; Compilers||Sun Microsystems
|-
| Daniel Rentz|| X || dr||||[[Calc]] Excel filter, UI||Sun Microsystems
|-
| Florian Reuter|| X || flr||||Writer filters||Novell, Inc.
|-
| Georg Richter|| X || grichter||georg||Base, native MySQL driver||MySQL AB
|-
| G. Roderick Singleton|| || grsingleton||grsingleton||Documentation||pathtech.org
|-
| Hennes Rohling|| X || hro||||GSL & Util||Sun Microsystems
|-
| Bibek Sahu|| || Bibek||bibek||Impress pieces||Trees For Life
|-
| Andreas Schlüns|| X || as||||Framework||Sun Microsystems
|-
| Ingo Schmidt|| X || is||||(Native) Installation||Sun Microsystems
|-
| Jürgen Schmidt|| X || jsc||||PL API, UNO, SDK||Sun Microsystems
|-
| Stephan Schäfer|| X || ssa||ssa||VCL||Sun Microsystems
|-
| Frank Schönheit|| X || fs||FrankS||Database Access, Forms||Sun Microsystems
|-
| Julian Seward || || sewardj || || valgrind ||
|-
| Darragh Sherwin|| || dsherwin||darragh||E-Legislation / E-GovSystems||Propylon
|-
| Raul Siddhartha|| || rsiddhartha||raul||GTK File Selector||Novell, Inc.
|-
| Sarah Smith|| || ssmith||||||
|-
| Rajesh Sola|| || rajeshsola||sola||misc.||NOSIP
|-
| Kai Sommerfeld|| X || kso||||manager & hacker||Sun Microsystems
|-
| Oliver Specht|| X || os||||PL UI||Sun Microsystems
|-
| Jörg Spindler|| || jspindler||||||
|-
| Fridrich Štrba|| X || fridrich_strba||Fridrich||Word Perfect Hacker||
|-
| Ulf Stroehler|| || us||||||Sun Microsystems
|-
| Muthu Subramanian|| || muthusuba||muthusuba||misc.||
|-
| Louis Suárez-Potts|| || louis||louis||Community Manager||Collab.net
|-
| Claus Sørensen|| || cs||c26n,cHBs,chbs||Danish Localization and Project Management Tool(oopm)||ProFOSS
|-
| Stefan Taxhet|| X || st||stx12||CC, interpersonal problem fixer||Sun Microsystems
|-
| Armin Theissen|| || armin||||||
|-
| Caio Tiago Oliveira|| X || asrail||asrail||CL QA||Independent
|-
| Jan Tietjens|| || tietjens||||||
|-
| Rüdiger Timm|| X || rt||||RE||Sun Microsystems
|-
| Malte Timmermann|| X || mt||||||Sun Microsystems
|-
| Gerhard Tonn|| || tonn||||s390||
|-
| Willem van Dorp|| || willem.vandorp||||||
|-
| Tom Verbeek|| X || tv||||Wizards, Art team||Sun Microsystems
|-
| Sander Vesik|| || svesik||||||
|-
| Daniel Vogelheim|| X || dvo||||XML||
|-
| Mikhail Voitenko|| X || mav||Framework||||Sun Microsystems
|-
| Robert Vojta|| X || rvojta||rvojta||VBA Interop||
|-
| Dirk Völzke|| X || dv||||Installation||Sun Microsystems
|-
| [[User:Sparcmoz|Jim Watson]]|| X || sparcmoz|| sparcmoz||GNU Linux sparc porter||clug.org.au
|-
| Armin Weiss|| X || aw||||||Sun Microsystems
|-
| Dan Williams|| X || fa||dcbw||Mac et. al. hacker||RedHat, Inc.
|-
| Stephan Wunderlich|| X || sw||||||
|-
| Kohei Yoshida|| X || kohei||kohei_||[[Calc]] hacker, Calc optimization solver developer||SlickEdit, Inc.
|-
| George Zahopoulos|| X || georgez||||||
|-
| Kurt Zenker|| X || kz||smoketester||RE||Sun Microsystems
|-
| Claudio F Filho|| || filhocf||filhocf||Brazilian portuguese Localization||BrOffice.org
|-
| Xiaoyang Yu|| || || ||Disk block reordering||Intel Corporation
|-
| Antonio Xu|| X || antoxu || antoxu || Async dialogs, PRC improvements || Intel Corporation
|-
| Rail Aliev || X || rail || rail || Ru and Tr NL Co-lead || Infra-Resource
|-
| Jeremy Zheng|| X || zhiming || Jeremy || Async dialogs, PRC improvements || Intel Corporation
|-
| [[User:Schmidtm|Matthias Schmidt]] || || schmidtm || schmidtm || Mac OSX Aqua Port || Sun Microsystems
|-
| Yuri Dario || || ydario || Paperino || OS/2 Port || Serenity Systems intl
|-
| Wei Zhao || || weiz || || Chinese Localization || Beijing Redflag CH2000
|-
|}

=== QA Engineers ===

{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
! Name ||CVS||@openoffice.org || [[IRC Communication]] || Interested modules || Notes || Affiliation
|-
| Stefan Baltzer||||sba||||writer||||Sun Microsystems
|-
| Thorsten Bosbach||X||tbo||||framework, qa/qatesttool||QA Framework / Automation||Sun Microsystems
|-
| Oliver Craemer||X||oc||||[[Calc]]||QA Calc / Automation||Sun Microsystems
|-
| Helge Delfs||X||hde||||writer, qa/qatesttool||QA Writer / Automation||Sun Microsystems
|-
| Fredrik Haegg||X||fha||||draw, impress, qa/qatesttool||QA Graphics / Automation||Sun Microsystems
|-
| Hasan Ilter||||hi||||writer, printing, pdf export||||Sun Microsystems
|-
| Michael Rüß||||mru||||writer, word im/export||||Sun Microsystems
|-
| Éric Savary||||es||||writer, accessibility||||Sun Microsystems
|-
| [[User:jsi|Joerg Sievers]]||X||jsi||jogi||qa/qatesttool, [[Calc]]||Automation / QA Calc||Sun Microsystems
|-
| Joerg Skottke||X||jsk||skotti||framework, qa/qatesttool||QA Framework / Automation||Sun Microsystems
|-
| Marc Neumann||X||msc||||database, qa/qatesttool||QA Base / Automation||Sun Microsystems
|-
| Chris Lukasiak||||clu||||database||||Sun Microsystems
|-
| Frank Stecher||||fst||||[[Calc]]||||Sun Microsystems
|-
| Jack Warchold|||| jw||||writer, import/export filters||||Sun Microsystems
|-
| Uwe Luebbers||||ul||||framework||||Sun Microsystems
|-
| Thorsten Martens||||tm||||framework||||Sun Microsystems
|-
| Olaf Felka|||| of||||framework, installation||||Sun Microsystems
|-
| Thomas Klarhoefer||||kla||||chart||||Sun Microsystems
|-
| Wolfram Garten|||| wg||||draw, impress||||Sun Microsystems
|-
| Christian Guenther||||cgu||||draw, impress||||Sun Microsystems
|-
| [[User:Thorsten_Ziehm|Thorsten Ziehm]]||||| thorstenziehm||||||QA lead||Sun Microsystems
|-
|}

We are tracking pending JCAs in the document [[Pending JCAs]].

== Related Pages ==
* [[User Experience Community]]
* A map of OOo developers around the world is available at http://www.frappr.com/ooodev, please add yourself to the map if you're involved in OOo development. It's just fun to see who's where :-)

[[Category:Development]]

Building OpenOffice.org

2006-09-17T19:16:28Z

Vq: Add Windows to the list.

[[Category:Development]]
These are the instructions on how to build "vanilla" OpenOffice.org. Vanilla means: without tools like ooobuild that wrap the build-process. If you're using ooobuild, have a look at [[Building_with_ooobuild]] instead.

= Compiling OpenOffice.org : the practice =
== Getting the sources ==
To not make these instructions longer than necessary, there is a dedicated page on [[Getting_It | how to get the source]].

== Dependencies ==
Of course you need to have some development libraries installed to build OpenOffice.org.
The configure script will complain if something is missing.
Until this guide lists the prerequisites, please have a look at http://tools.openoffice.org/

==Different Platforms==
Some information for specific platforms is provided at [http://tools.openoffice.org#Build tools].

Also for Mac OS X see [[MacOSXBuildInstructions]], for GNU/Linux Sparc see [[GNULinuxSparcPorting]] and for Windows see [[Windows]].

= Building a Milestone =
== Running configure ==
The first step after getting the sources (and hopefully all prerequisites) is to run configure:

<pre>
cd <SRC_ROOT>
cd config_office
./configure
</pre>

You will most likely have to tell configure where it finds some packages such as ant or tell it what java to use. Use
<pre>
./configure --help
</pre>
to get a list of valid options that you can use.

If you forgot to install some dependencies, the configure will remind you
which one are lacking.

Special hint related to ant: Make sure to use an absolute path.

== Bootstrapping ==
When configure ran fine (i.e. it did finish without any error or warnings), you can continue the build.
Configure creates an environment file that you need to read into your shell.
If you run bash, use
<pre>
cd <SRC_ROOT>
source LinuxIntelEnv.Set.sh
</pre>
If you run a tcsh or similar, use
<pre>
cd <SRC_ROOT>
source LinuxIntelEnv.Set
rehash
</pre>

The last step before the real build is to build the buildtools that OOo uses. To do so, simply run
<pre>
./bootstrap
</pre>
in <SRC_ROOT>

== Starting the real build ==
Now it is time for the real build
Just type
<pre>
dmake
</pre>
in <SRC_ROOT> and then relax.
Building OOo takes some time (approx 10-12 hours on standard desktop PC) so you can do other things in the meantime.

= Building a [[CWS]] =
In order to build a cws, you need to first checkout the milestone that the cws is based upon (see Getting the source above). After that, you have to update the modules included in the cws with the cvs tag of the CWS.

You can either use [[EIS]] to get information about what milestone is the base for the CWS (see the field "Milestone (current)") and what modules it includes (see the table "Modules & Files") - or you can use [http://go-oo.org/tinderbox/tags/tag-list Tinderbox's tag-list] to get this information.

Once you have collected the necessary information, you can run:

<pre>
cd <SRC_ROOT>
setenv CVSROOT ":pserver:anoncvs@anoncvs.services.openoffice.org:/cvs"
cvs [optional cvs flags such as -z #] update -dP -r <cwstag> <module1> <module2> <moduleN>
</pre>

Where
* SRC_ROOT is the top-level directory of your milestone-checkout
* cwstag is the cvs tag of the CWS. The tag is in the form cws_<main codeline>_<name of cws>, for example cws_src680_chart2mst3

Note: If you're using cvs using the ssh-tunnel, use ssh's compression rather than cvs compression - that gives better results

For example, you can issue :

<pre>
cd src680-m172
setenv CVSROOT ":pserver:anoncvs@anoncvs.services.openoffice.org:/cvs"
cvs -z3 update -dP -r cws_src680_chart2mst3 chart2/ offuh/
</pre>

= Tips and Tricks =

Here are some tips that make your life easier or can accelerate the build

== ccache ==
If possible (Not for Windows builds), it is strongly recommended to install (and configure) [http://ccache.samba.org/ ccache] - this will greatly reduce build time on subsequent builds.

== set nodep=TRUE ==
If you set the environment variable nodep to TRUE, then dependendy information files are not created - the build finishes faster.

But only enable that on a clean build. Once you have built OOo and then made modifications, unset the variable again to be on the safe side.

== set NO_HIDS=TRUE ==
Similar to the nodep variabnle, this one prevents the generation of HIDs (Help IDs) that are mainly used for automated testing - if you only want to build OOo, you don't need those.

== use parallel builds ==
If you have a multiprocessor machine or similar, you can run a parallel build. There are two levels of parallelism - one operating on makefile level, the other one on module level

=== set MAXPROCESS=<numer or processes> ===
This is the makefile-parallelism. This tells dmake how many targets it is allowed to build in parallel

=== running parallel build.pl ===
For parallelism on the module level, you have to run build from <SRC_ROOT>/instsetoo_native with the -P<number> switch, for example:
<pre>
build -P2
</pre>

== create prebuilt mozilla and use that instead of recompiling everytime ==
For the mozilla-components you have the choice to either build from mozilla sources, to use precompiled packages ([http://tools.openoffice.org/moz_prebuild/680/ the "official" ones can be obtained from tools.openoffice.org]) or to use system-mozilla (the one installed on your buildsystem, not everything might work, depending on the version you got installed)
You can easily create your own version of the prepacked binaries if you wish to do so (either because you cannot use the official ones because of mismatch of compiler version used to build them/other technical reasons or because you want to use stuff you didn't build yourself).
To do so:

* build the <code>moz</code> module from the mozilla sources (use <code>--enable-build-mozilla</code> when running configure and put the mozilla-source tarball to <code>moz/download</code>)
* in <code>moz</code> run <code>dmake zip</code> to create the zip files
* you'll find the zips in <code>{unxlngi#,wntmsci#}.pro/zipped</code>

Copy them to a location of your liking.
Now instead of using <code>--enable-build-mozilla</code>, use <code>--disable-build-mozilla</code> and copy the zips you created or downloaded to <code>moz/zipped</code> and these will be used when compiling.
This will greatly reduce build-time (you save the time that would otherwise be spent on compiling mozilla)

== saving diskscpace by linking to the solver only ==
Use "--dlv_switch -link" when running build to tell deliver to only link the files instead of copying them:
<pre>
build --dlv_switch -link
</pre>

Building OpenOffice.org

2006-09-17T18:41:31Z

Vq: Move ccache to Tips and Tricks

[[Category:Development]]
These are the instructions on how to build "vanilla" OpenOffice.org. Vanilla means: without tools like ooobuild that wrap the build-process. If you're using ooobuild, have a look at [[Building_with_ooobuild]] instead.

= Compiling OpenOffice.org : the practice =
== Getting the sources ==
To not make these instructions longer than necessary, there is a dedicated page on [[Getting_It | how to get the source]].

== Dependencies ==
Of course you need to have some development libraries installed to build OpenOffice.org.
The configure script will complain if something is missing.
Until this guide lists the prerequisites, please have a look at http://tools.openoffice.org/

==Different Platforms==
Some information for specific platforms is provided at [http://tools.openoffice.org#Build tools].

Also for Mac OS X see [[MacOSXBuildInstructions]] and for GNU/Linux Sparc see [[GNULinuxSparcPorting]]

= Building a Milestone =
== Running configure ==
The first step after getting the sources (and hopefully all prerequisites) is to run configure:

<pre>
cd <SRC_ROOT>
cd config_office
./configure
</pre>

You will most likely have to tell configure where it finds some packages such as ant or tell it what java to use. Use
<pre>
./configure --help
</pre>
to get a list of valid options that you can use.

If you forgot to install some dependencies, the configure will remind you
which one are lacking.

Special hint related to ant: Make sure to use an absolute path.

== Bootstrapping ==
When configure ran fine (i.e. it did finish without any error or warnings), you can continue the build.
Configure creates an environment file that you need to read into your shell.
If you run bash, use
<pre>
cd <SRC_ROOT>
source LinuxIntelEnv.Set.sh
</pre>
If you run a tcsh or similar, use
<pre>
cd <SRC_ROOT>
source LinuxIntelEnv.Set
rehash
</pre>

The last step before the real build is to build the buildtools that OOo uses. To do so, simply run
<pre>
./bootstrap
</pre>
in <SRC_ROOT>

== Starting the real build ==
Now it is time for the real build
Just type
<pre>
dmake
</pre>
in <SRC_ROOT> and then relax.
Building OOo takes some time (approx 10-12 hours on standard desktop PC) so you can do other things in the meantime.

= Building a [[CWS]] =
In order to build a cws, you need to first checkout the milestone that the cws is based upon (see Getting the source above). After that, you have to update the modules included in the cws with the cvs tag of the CWS.

You can either use [[EIS]] to get information about what milestone is the base for the CWS (see the field "Milestone (current)") and what modules it includes (see the table "Modules & Files") - or you can use [http://go-oo.org/tinderbox/tags/tag-list Tinderbox's tag-list] to get this information.

Once you have collected the necessary information, you can run:

<pre>
cd <SRC_ROOT>
setenv CVSROOT ":pserver:anoncvs@anoncvs.services.openoffice.org:/cvs"
cvs [optional cvs flags such as -z #] update -dP -r <cwstag> <module1> <module2> <moduleN>
</pre>

Where
* SRC_ROOT is the top-level directory of your milestone-checkout
* cwstag is the cvs tag of the CWS. The tag is in the form cws_<main codeline>_<name of cws>, for example cws_src680_chart2mst3

Note: If you're using cvs using the ssh-tunnel, use ssh's compression rather than cvs compression - that gives better results

For example, you can issue :

<pre>
cd src680-m172
setenv CVSROOT ":pserver:anoncvs@anoncvs.services.openoffice.org:/cvs"
cvs -z3 update -dP -r cws_src680_chart2mst3 chart2/ offuh/
</pre>

= Tips and Tricks =

Here are some tips that make your life easier or can accelerate the build

== ccache ==
If possible (Not for Windows builds), it is strongly recommended to install (and configure) [http://ccache.samba.org/ ccache] - this will greatly reduce build time on subsequent builds.

== set nodep=TRUE ==
If you set the environment variable nodep to TRUE, then dependendy information files are not created - the build finishes faster.

But only enable that on a clean build. Once you have built OOo and then made modifications, unset the variable again to be on the safe side.

== set NO_HIDS=TRUE ==
Similar to the nodep variabnle, this one prevents the generation of HIDs (Help IDs) that are mainly used for automated testing - if you only want to build OOo, you don't need those.

== use parallel builds ==
If you have a multiprocessor machine or similar, you can run a parallel build. There are two levels of parallelism - one operating on makefile level, the other one on module level

=== set MAXPROCESS=<numer or processes> ===
This is the makefile-parallelism. This tells dmake how many targets it is allowed to build in parallel

=== running parallel build.pl ===
For parallelism on the module level, you have to run build from <SRC_ROOT>/instsetoo_native with the -P<number> switch, for example:
<pre>
build -P2
</pre>

== create prebuilt mozilla and use that instead of recompiling everytime ==
For the mozilla-components you have the choice to either build from mozilla sources, to use precompiled packages ([http://tools.openoffice.org/moz_prebuild/680/ the "official" ones can be obtained from tools.openoffice.org]) or to use system-mozilla (the one installed on your buildsystem, not everything might work, depending on the version you got installed)
You can easily create your own version of the prepacked binaries if you wish to do so (either because you cannot use the official ones because of mismatch of compiler version used to build them/other technical reasons or because you want to use stuff you didn't build yourself).
To do so:

* build the <code>moz</code> module from the mozilla sources (use <code>--enable-build-mozilla</code> when running configure and put the mozilla-source tarball to <code>moz/download</code>)
* in <code>moz</code> run <code>dmake zip</code> to create the zip files
* you'll find the zips in <code>{unxlngi#,wntmsci#}.pro/zipped</code>

Copy them to a location of your liking.
Now instead of using <code>--enable-build-mozilla</code>, use <code>--disable-build-mozilla</code> and copy the zips you created or downloaded to <code>moz/zipped</code> and these will be used when compiling.
This will greatly reduce build-time (you save the time that would otherwise be spent on compiling mozilla)

== saving diskscpace by linking to the solver only ==
Use "--dlv_switch -link" when running build to tell deliver to only link the files instead of copying them:
<pre>
build --dlv_switch -link
</pre>

Building

2006-09-15T22:36:24Z

Vq: Fix page name of build page

[[Category: Development]]
There are at least two ways to build OOo - one is to just use the sources and the included buildsystem directly (this is explained in [[Building OpenOffice.org]]) or to use a system that encapsulates the process and manages some additional patchsets (that system is called ooo-build and using it is explained in [[Building with ooobuild]]

There are also some [[:Category:Distribution-Specific_Build_Instructions | Distribution-specific instructions ]]

Building vanilla

2006-09-15T22:33:45Z

Vq: Building vanilla moved to Building OpenOffice.org: We are not building vanilla, we are building the regular OpenOffice.org.

#REDIRECT [[Building OpenOffice.org]]

Building OpenOffice.org

2006-09-15T22:33:45Z

Vq: Building vanilla moved to Building OpenOffice.org: We are not building vanilla, we are building the regular OpenOffice.org.

[[Category:Development]]
These are the instructions on how to build "vanilla" OpenOffice.org. Vanilla means: without tools like ooobuild that wrap the build-process. If you're using ooobuild, have a look at [[Building_with_ooobuild]] instead.

= Compiling OpenOffice.org : the practice =
== Getting the sources ==
To not make these instructions longer than necessary, there is a dedicated page on [[Getting_It | how to get the source]].

== Dependencies ==
Of course you need to have some development libraries installed to build OpenOffice.org.
The configure script will complain if something is missing.
Until this guide lists the prerequisites, please have a look at http://tools.openoffice.org/

While not dependencies, it is strongly recommended to install (and configure) [http://ccache.samba.org/ ccache] - this will greatly reduce build time on subsequent builds.

==Different Platforms==
Some information for specific platforms is provided at [http://tools.openoffice.org#Build tools].

Also for Mac OS X see [[MacOSXBuildInstructions]] and for GNU/Linux Sparc see [[GNULinuxSparcPorting]]

= Building a Milestone =
== Running configure ==
The first step after getting the sources (and hopefully all prerequisites) is to run configure:

<pre>
cd <SRC_ROOT>
cd config_office
./configure
</pre>

You will most likely have to tell configure where it finds some packages such as ant or tell it what java to use. Use
<pre>
./configure --help
</pre>
to get a list of valid options that you can use.

If you forgot to install some dependencies, the configure will remind you
which one are lacking.

Special hint related to ant: Make sure to use an absolute path.

== Bootstrapping ==
When configure ran fine (i.e. it did finish without any error or warnings), you can continue the build.
Configure creates an environment file that you need to read into your shell.
If you run bash, use
<pre>
cd <SRC_ROOT>
source LinuxIntelEnv.Set.sh
</pre>
If you run a tcsh or similar, use
<pre>
cd <SRC_ROOT>
source LinuxIntelEnv.Set
rehash
</pre>

The last step before the real build is to build the buildtools that OOo uses. To do so, simply run
<pre>
./bootstrap
</pre>
in <SRC_ROOT>

== Starting the real build ==
Now it is time for the real build
Just type
<pre>
dmake
</pre>
in <SRC_ROOT> and then relax.
Building OOo takes some time (approx 10-12 hours on standard desktop PC) so you can do other things in the meantime.

= Building a [[CWS]] =
In order to build a cws, you need to first checkout the milestone that the cws is based upon (see Getting the source above). After that, you have to update the modules included in the cws with the cvs tag of the CWS.

You can either use [[EIS]] to get information about what milestone is the base for the CWS (see the field "Milestone (current)") and what modules it includes (see the table "Modules & Files") - or you can use [http://go-oo.org/tinderbox/tags/tag-list Tinderbox's tag-list] to get this information.

Once you have collected the necessary information, you can run:

<pre>
cd <SRC_ROOT>
setenv CVSROOT ":pserver:anoncvs@anoncvs.services.openoffice.org:/cvs"
cvs [optional cvs flags such as -z #] update -dP -r <cwstag> <module1> <module2> <moduleN>
</pre>

Where
* SRC_ROOT is the top-level directory of your milestone-checkout
* cwstag is the cvs tag of the CWS. The tag is in the form cws_<main codeline>_<name of cws>, for example cws_src680_chart2mst3

Note: If you're using cvs using the ssh-tunnel, use ssh's compression rather than cvs compression - that gives better results

For example, you can issue :

<pre>
cd src680-m172
setenv CVSROOT ":pserver:anoncvs@anoncvs.services.openoffice.org:/cvs"
cvs -z3 update -dP -r cws_src680_chart2mst3 chart2/ offuh/
</pre>

= Tips and Tricks =

Here are some tips that make your life easier or can accelerate the build
== set nodep=TRUE ==
If you set the environment variable nodep to TRUE, then dependendy information files are not created - the build finishes faster.

But only enable that on a clean build. Once you have built OOo and then made modifications, unset the variable again to be on the safe side.

== set NO_HIDS=TRUE ==
Similar to the nodep variabnle, this one prevents the generation of HIDs (Help IDs) that are mainly used for automated testing - if you only want to build OOo, you don't need those.

== use parallel builds ==
If you have a multiprocessor machine or similar, you can run a parallel build. There are two levels of parallelism - one operating on makefile level, the other one on module level

=== set MAXPROCESS=<numer or processes> ===
This is the makefile-parallelism. This tells dmake how many targets it is allowed to build in parallel

=== running parallel build.pl ===
For parallelism on the module level, you have to run build from <SRC_ROOT>/instsetoo_native with the -P<number> switch, for example:
<pre>
build -P2
</pre>

== create prebuilt mozilla and use that instead of recompiling everytime ==
For the mozilla-components you have the choice to either build from mozilla sources, to use precompiled packages ([http://tools.openoffice.org/moz_prebuild/680/ the "official" ones can be obtained from tools.openoffice.org]) or to use system-mozilla (the one installed on your buildsystem, not everything might work, depending on the version you got installed)
You can easily create your own version of the prepacked binaries if you wish to do so (either because you cannot use the official ones because of mismatch of compiler version used to build them/other technical reasons or because you want to use stuff you didn't build yourself).
To do so:

* build the <code>moz</code> module from the mozilla sources (use <code>--enable-build-mozilla</code> when running configure and put the mozilla-source tarball to <code>moz/download</code>)
* in <code>moz</code> run <code>dmake zip</code> to create the zip files
* you'll find the zips in <code>{unxlngi#,wntmsci#}.pro/zipped</code>

Copy them to a location of your liking.
Now instead of using <code>--enable-build-mozilla</code>, use <code>--disable-build-mozilla</code> and copy the zips you created or downloaded to <code>moz/zipped</code> and these will be used when compiling.
This will greatly reduce build-time (you save the time that would otherwise be spent on compiling mozilla)

== saving diskscpace by linking to the solver only ==
Use "--dlv_switch -link" when running build to tell deliver to only link the files instead of copying them:
<pre>
build --dlv_switch -link
</pre>

Building OpenOffice.org

2006-09-15T18:17:05Z

Vq: /* create prebuilt mozilla and use that instead of recompiling everytime */

[[Category:Development]]
These are the instructions on how to build "vanilla" OpenOffice.org. Vanilla means: without tools like ooobuild that wrap the build-process. If you're using ooobuild, have a look at [[Building_with_ooobuild]] instead.

= Compiling OpenOffice.org : the practice =
== Getting the sources ==
To not make these instructions longer than necessary, there is a dedicated page on [[Getting_It | how to get the source]].

== Dependencies ==
Of course you need to have some development libraries installed to build OpenOffice.org.
The configure script will complain if something is missing.
Until this guide lists the prerequisites, please have a look at http://tools.openoffice.org/

While not dependencies, it is strongly recommended to install (and configure) [http://ccache.samba.org/ ccache] - this will greatly reduce build time on subsequent builds.

==Different Platforms==
Some information for specific platforms is provided at [http://tools.openoffice.org#Build tools].

Also for Mac OS X see [[MacOSXBuildInstructions]] and for GNU/Linux Sparc see [[GNULinuxSparcPorting]]

= Building a Milestone =
== Running configure ==
The first step after getting the sources (and hopefully all prerequisites) is to run configure:

<pre>
cd <SRC_ROOT>
cd config_office
./configure
</pre>

You will most likely have to tell configure where it finds some packages such as ant or tell it what java to use. Use
<pre>
./configure --help
</pre>
to get a list of valid options that you can use.

If you forgot to install some dependencies, the configure will remind you
which one are lacking.

Special hint related to ant: Make sure to use an absolute path.

== Bootstrapping ==
When configure ran fine (i.e. it did finish without any error or warnings), you can continue the build.
Configure creates an environment file that you need to read into your shell.
If you run bash, use
<pre>
cd <SRC_ROOT>
source LinuxIntelEnv.Set.sh
</pre>
If you run a tcsh or similar, use
<pre>
cd <SRC_ROOT>
source LinuxIntelEnv.Set
rehash
</pre>

The last step before the real build is to build the buildtools that OOo uses. To do so, simply run
<pre>
./bootstrap
</pre>
in <SRC_ROOT>

== Starting the real build ==
Now it is time for the real build
Just type
<pre>
dmake
</pre>
in <SRC_ROOT> and then relax.
Building OOo takes some time (approx 10-12 hours on standard desktop PC) so you can do other things in the meantime.

= Building a [[CWS]] =
In order to build a cws, you need to first checkout the milestone that the cws is based upon (see Getting the source above). After that, you have to update the modules included in the cws with the cvs tag of the CWS.

You can either use [[EIS]] to get information about what milestone is the base for the CWS (see the field "Milestone (current)") and what modules it includes (see the table "Modules & Files") - or you can use [http://go-oo.org/tinderbox/tags/tag-list Tinderbox's tag-list] to get this information.

Once you have collected the necessary information, you can run:

<pre>
cd <SRC_ROOT>
setenv CVSROOT ":pserver:anoncvs@anoncvs.services.openoffice.org:/cvs"
cvs [optional cvs flags such as -z #] update -dP -r <cwstag> <module1> <module2> <moduleN>
</pre>

Where
* SRC_ROOT is the top-level directory of your milestone-checkout
* cwstag is the cvs tag of the CWS. The tag is in the form cws_<main codeline>_<name of cws>, for example cws_src680_chart2mst3

Note: If you're using cvs using the ssh-tunnel, use ssh's compression rather than cvs compression - that gives better results

For example, you can issue :

<pre>
cd src680-m172
setenv CVSROOT ":pserver:anoncvs@anoncvs.services.openoffice.org:/cvs"
cvs -z3 update -dP -r cws_src680_chart2mst3 chart2/ offuh/
</pre>

= Tips and Tricks =

Here are some tips that make your life easier or can accelerate the build
== set nodep=TRUE ==
If you set the environment variable nodep to TRUE, then dependendy information files are not created - the build finishes faster.

But only enable that on a clean build. Once you have built OOo and then made modifications, unset the variable again to be on the safe side.

== set NO_HIDS=TRUE ==
Similar to the nodep variabnle, this one prevents the generation of HIDs (Help IDs) that are mainly used for automated testing - if you only want to build OOo, you don't need those.

== use parallel builds ==
If you have a multiprocessor machine or similar, you can run a parallel build. There are two levels of parallelism - one operating on makefile level, the other one on module level

=== set MAXPROCESS=<numer or processes> ===
This is the makefile-parallelism. This tells dmake how many targets it is allowed to build in parallel

=== running parallel build.pl ===
For parallelism on the module level, you have to run build from <SRC_ROOT>/instsetoo_native with the -P<number> switch, for example:
<pre>
build -P2
</pre>

== create prebuilt mozilla and use that instead of recompiling everytime ==
For the mozilla-components you have the choice to either build from mozilla sources, to use precompiled packages ([http://tools.openoffice.org/moz_prebuild/680/ the "official" ones can be obtained from tools.openoffice.org]) or to use system-mozilla (the one installed on your buildsystem, not everything might work, depending on the version you got installed)
You can easily create your own version of the prepacked binaries if you wish to do so (either because you cannot use the official ones because of mismatch of compiler version used to build them/other technical reasons or because you want to use stuff you didn't build yourself).
To do so:

* build the <code>moz</code> module from the mozilla sources (use <code>--enable-build-mozilla</code> when running configure and put the mozilla-source tarball to <code>moz/download</code>)
* in <code>moz</code> run <code>dmake zip</code> to create the zip files
* you'll find the zips in <code>{unxlngi#,wntmsci#}.pro/zipped</code>

Copy them to a location of your liking.
Now instead of using <code>--enable-build-mozilla</code>, use <code>--disable-build-mozilla</code> and copy the zips you created or downloaded to <code>moz/zipped</code> and these will be used when compiling.
This will greatly reduce build-time (you save the time that would otherwise be spent on compiling mozilla)

== saving diskscpace by linking to the solver only ==
Use "--dlv_switch -link" when running build to tell deliver to only link the files instead of copying them:
<pre>
build --dlv_switch -link
</pre>

Building OpenOffice.org

2006-09-15T18:15:00Z

Vq: /* create prebuilt mozilla and use that instead of recompiling everytime */

[[Category:Development]]
These are the instructions on how to build "vanilla" OpenOffice.org. Vanilla means: without tools like ooobuild that wrap the build-process. If you're using ooobuild, have a look at [[Building_with_ooobuild]] instead.

= Compiling OpenOffice.org : the practice =
== Getting the sources ==
To not make these instructions longer than necessary, there is a dedicated page on [[Getting_It | how to get the source]].

== Dependencies ==
Of course you need to have some development libraries installed to build OpenOffice.org.
The configure script will complain if something is missing.
Until this guide lists the prerequisites, please have a look at http://tools.openoffice.org/

While not dependencies, it is strongly recommended to install (and configure) [http://ccache.samba.org/ ccache] - this will greatly reduce build time on subsequent builds.

==Different Platforms==
Some information for specific platforms is provided at [http://tools.openoffice.org#Build tools].

Also for Mac OS X see [[MacOSXBuildInstructions]] and for GNU/Linux Sparc see [[GNULinuxSparcPorting]]

= Building a Milestone =
== Running configure ==
The first step after getting the sources (and hopefully all prerequisites) is to run configure:

<pre>
cd <SRC_ROOT>
cd config_office
./configure
</pre>

You will most likely have to tell configure where it finds some packages such as ant or tell it what java to use. Use
<pre>
./configure --help
</pre>
to get a list of valid options that you can use.

If you forgot to install some dependencies, the configure will remind you
which one are lacking.

Special hint related to ant: Make sure to use an absolute path.

== Bootstrapping ==
When configure ran fine (i.e. it did finish without any error or warnings), you can continue the build.
Configure creates an environment file that you need to read into your shell.
If you run bash, use
<pre>
cd <SRC_ROOT>
source LinuxIntelEnv.Set.sh
</pre>
If you run a tcsh or similar, use
<pre>
cd <SRC_ROOT>
source LinuxIntelEnv.Set
rehash
</pre>

The last step before the real build is to build the buildtools that OOo uses. To do so, simply run
<pre>
./bootstrap
</pre>
in <SRC_ROOT>

== Starting the real build ==
Now it is time for the real build
Just type
<pre>
dmake
</pre>
in <SRC_ROOT> and then relax.
Building OOo takes some time (approx 10-12 hours on standard desktop PC) so you can do other things in the meantime.

= Building a [[CWS]] =
In order to build a cws, you need to first checkout the milestone that the cws is based upon (see Getting the source above). After that, you have to update the modules included in the cws with the cvs tag of the CWS.

You can either use [[EIS]] to get information about what milestone is the base for the CWS (see the field "Milestone (current)") and what modules it includes (see the table "Modules & Files") - or you can use [http://go-oo.org/tinderbox/tags/tag-list Tinderbox's tag-list] to get this information.

Once you have collected the necessary information, you can run:

<pre>
cd <SRC_ROOT>
setenv CVSROOT ":pserver:anoncvs@anoncvs.services.openoffice.org:/cvs"
cvs [optional cvs flags such as -z #] update -dP -r <cwstag> <module1> <module2> <moduleN>
</pre>

Where
* SRC_ROOT is the top-level directory of your milestone-checkout
* cwstag is the cvs tag of the CWS. The tag is in the form cws_<main codeline>_<name of cws>, for example cws_src680_chart2mst3

Note: If you're using cvs using the ssh-tunnel, use ssh's compression rather than cvs compression - that gives better results

For example, you can issue :

<pre>
cd src680-m172
setenv CVSROOT ":pserver:anoncvs@anoncvs.services.openoffice.org:/cvs"
cvs -z3 update -dP -r cws_src680_chart2mst3 chart2/ offuh/
</pre>

= Tips and Tricks =

Here are some tips that make your life easier or can accelerate the build
== set nodep=TRUE ==
If you set the environment variable nodep to TRUE, then dependendy information files are not created - the build finishes faster.

But only enable that on a clean build. Once you have built OOo and then made modifications, unset the variable again to be on the safe side.

== set NO_HIDS=TRUE ==
Similar to the nodep variabnle, this one prevents the generation of HIDs (Help IDs) that are mainly used for automated testing - if you only want to build OOo, you don't need those.

== use parallel builds ==
If you have a multiprocessor machine or similar, you can run a parallel build. There are two levels of parallelism - one operating on makefile level, the other one on module level

=== set MAXPROCESS=<numer or processes> ===
This is the makefile-parallelism. This tells dmake how many targets it is allowed to build in parallel

=== running parallel build.pl ===
For parallelism on the module level, you have to run build from <SRC_ROOT>/instsetoo_native with the -P<number> switch, for example:
<pre>
build -P2
</pre>

== create prebuilt mozilla and use that instead of recompiling everytime ==
For the mozilla-components you have the choice to either build from mozilla sources, to use precompiled packages ([http://tools.openoffice.org/moz_prebuild/680/ the "official" ones can be obtained from tools.openoffice.org]) or to use system-mozilla (the one installed on your buildsystem, not everything might work, depending on the version you got installed)
You can easily create your own version of the prepacked binaries if you wish to do so (either because you cannot use the official ones because of mismatch of compiler version used to build them/other technical reasons or because you want to use stuff you didn't build yourself).
To do so:

* build the <code>moz</code> module from the mozilla sources (use <code>--enable-build-mozilla</code> when running configure and put the mozilla-source tarball to <code>moz/download</code>)
* in <code>moz</code> run <code>dmake zip</code> to create the zip files
* you'll find the zips in <code>unxlngi#.pro/zipped</code>

Copy them to a location of your liking.
Now instead of using <code>--enable-build-mozilla</code>, use <code>--disable-build-mozilla</code> and copy the zips you created or downloaded to <code>moz/zipped</code> and these will be used when compiling.
This will greatly reduce build-time (you save the time that would otherwise be spent on compiling mozilla)

== saving diskscpace by linking to the solver only ==
Use "--dlv_switch -link" when running build to tell deliver to only link the files instead of copying them:
<pre>
build --dlv_switch -link
</pre>

Building OpenOffice.org

2006-09-15T17:59:41Z

Vq:

[[Category:Development]]
These are the instructions on how to build "vanilla" OpenOffice.org. Vanilla means: without tools like ooobuild that wrap the build-process. If you're using ooobuild, have a look at [[Building_with_ooobuild]] instead.

= Compiling OpenOffice.org : the practice =
== Getting the sources ==
To not make these instructions longer than necessary, there is a dedicated page on [[Getting_It | how to get the source]].

== Dependencies ==
Of course you need to have some development libraries installed to build OpenOffice.org.
The configure script will complain if something is missing.
Until this guide lists the prerequisites, please have a look at http://tools.openoffice.org/

While not dependencies, it is strongly recommended to install (and configure) [http://ccache.samba.org/ ccache] - this will greatly reduce build time on subsequent builds.

==Different Platforms==
Some information for specific platforms is provided at [http://tools.openoffice.org#Build tools].

Also for Mac OS X see [[MacOSXBuildInstructions]] and for GNU/Linux Sparc see [[GNULinuxSparcPorting]]

= Building a Milestone =
== Running configure ==
The first step after getting the sources (and hopefully all prerequisites) is to run configure:

<pre>
cd <SRC_ROOT>
cd config_office
./configure
</pre>

You will most likely have to tell configure where it finds some packages such as ant or tell it what java to use. Use
<pre>
./configure --help
</pre>
to get a list of valid options that you can use.

If you forgot to install some dependencies, the configure will remind you
which one are lacking.

Special hint related to ant: Make sure to use an absolute path.

== Bootstrapping ==
When configure ran fine (i.e. it did finish without any error or warnings), you can continue the build.
Configure creates an environment file that you need to read into your shell.
If you run bash, use
<pre>
cd <SRC_ROOT>
source LinuxIntelEnv.Set.sh
</pre>
If you run a tcsh or similar, use
<pre>
cd <SRC_ROOT>
source LinuxIntelEnv.Set
rehash
</pre>

The last step before the real build is to build the buildtools that OOo uses. To do so, simply run
<pre>
./bootstrap
</pre>
in <SRC_ROOT>

== Starting the real build ==
Now it is time for the real build
Just type
<pre>
dmake
</pre>
in <SRC_ROOT> and then relax.
Building OOo takes some time (approx 10-12 hours on standard desktop PC) so you can do other things in the meantime.

= Building a [[CWS]] =
In order to build a cws, you need to first checkout the milestone that the cws is based upon (see Getting the source above). After that, you have to update the modules included in the cws with the cvs tag of the CWS.

You can either use [[EIS]] to get information about what milestone is the base for the CWS (see the field "Milestone (current)") and what modules it includes (see the table "Modules & Files") - or you can use [http://go-oo.org/tinderbox/tags/tag-list Tinderbox's tag-list] to get this information.

Once you have collected the necessary information, you can run:

<pre>
cd <SRC_ROOT>
setenv CVSROOT ":pserver:anoncvs@anoncvs.services.openoffice.org:/cvs"
cvs [optional cvs flags such as -z #] update -dP -r <cwstag> <module1> <module2> <moduleN>
</pre>

Where
* SRC_ROOT is the top-level directory of your milestone-checkout
* cwstag is the cvs tag of the CWS. The tag is in the form cws_<main codeline>_<name of cws>, for example cws_src680_chart2mst3

Note: If you're using cvs using the ssh-tunnel, use ssh's compression rather than cvs compression - that gives better results

For example, you can issue :

<pre>
cd src680-m172
setenv CVSROOT ":pserver:anoncvs@anoncvs.services.openoffice.org:/cvs"
cvs -z3 update -dP -r cws_src680_chart2mst3 chart2/ offuh/
</pre>

= Tips and Tricks =

Here are some tips that make your life easier or can accelerate the build
== set nodep=TRUE ==
If you set the environment variable nodep to TRUE, then dependendy information files are not created - the build finishes faster.

But only enable that on a clean build. Once you have built OOo and then made modifications, unset the variable again to be on the safe side.

== set NO_HIDS=TRUE ==
Similar to the nodep variabnle, this one prevents the generation of HIDs (Help IDs) that are mainly used for automated testing - if you only want to build OOo, you don't need those.

== use parallel builds ==
If you have a multiprocessor machine or similar, you can run a parallel build. There are two levels of parallelism - one operating on makefile level, the other one on module level

=== set MAXPROCESS=<numer or processes> ===
This is the makefile-parallelism. This tells dmake how many targets it is allowed to build in parallel

=== running parallel build.pl ===
For parallelism on the module level, you have to run build from <SRC_ROOT>/instsetoo_native with the -P<number> switch, for example:
<pre>
build -P2
</pre>

== create prebuilt mozilla and use that instead of recompiling everytime ==
For the mozilla-components you have the choice to either build from mozilla sources, to use precompiled packages ([http://tools.openoffice.org/moz_prebuild/680/ the "official" ones can be obtained from tools.openoffice.org]) or to use system-mozilla (the one installed on your buildsystem, not everything might work, depending on the version you got installed)
You can easily create your own version of the prepacked binaries if you wish to do so (either because you cannot use the official ones because of mismatch of compiler version used to build them/other technical reasons or because you want to use stuff you didn't build yourself).
To do so:

* build the <code>moz</code> module from the mozilla sources (use <code>--enable-build-mozilla</code> when running configure and put the mozilla-source tarball to <code>moz/download</code>)
* in <code>moz</code> run <code>dmake zip</code> to create the zip files
* you'll find the zips in <code>unxlngi#.pro/zipped</code>

Copy them to a location of your liking.
Now instead of using <code>--enable-build-mozilla</code>, just copy the zips you created to <code>moz/zipped</code> and these will be used when compiling.
This will greatly reduce build-time (you save the time that would otherwise be spent on compiling mozilla)

== saving diskscpace by linking to the solver only ==
Use "--dlv_switch -link" when running build to tell deliver to only link the files instead of copying them:
<pre>
build --dlv_switch -link
</pre>

Tinderbox Setup

2006-07-03T21:23:56Z

Vq: Files in cvs were updated

Disclaimer! I tested the tinderbox scripts that are described on this page only with W32-tcsh but they should work with any *NIX like system. They are to be considered of beta quality only. Patches are very much appreciated.

----

= What is tinderbox =

In essence tinderbox is a perl script that processes mail and turns it into HTML. It expects to be mailed build logs from separate and de-coupled build machines. Tinderbox has a few elaborations over the most simple 'status' web-page, inasmuch that it integrates with bonsai - to correlate builds against commits, and it has some nice built in error-parsers to allow huge build logs to be condensed to just a few (possible) tricky sections.

Our [http://go-oo.org/tinderbox/ tinderbox] uses the [http://www.mozilla.org/tinderbox.html Tinderbox 2] from the mozilla project plus some small cosmetic changes. Additional documentation can be found there.

= Setting up a build slave =
To do this, you need to be able to build OO.o already; if you can't do this start here: [[Building]].

The framework that is described in the following sections can be used to build "new" and "Ready-for-QA" CWSs and MWSs of the 680er codeline. The source is fetched from cvs.

See [http://www.go-oo.org/tinderbox/ this] webpage for a list of the currently accepted tags. You will find the build logs (providing there are any) when you click on the corresponding tag.

== Requirements ==

A mininimal framework to build OOo CWSs and MWSs and sent the reports to the tinderbox at go-oo.org is created by the following files.

These three files from [http://go-ooo.org/tinder-scripts/ this] directory are needed to refresh the build tree and send the build log after the build:
'''(Files partially updated: 2006.07.02)'''
tin-main.pl
tinget.pl
tinsend.pm

In principle any build/preparation script can be used but the following two files (also from [http://go-ooo.org/tinder-scripts/ here]) work together with the main tinderbox slave script mentioned above (tin-main.pl):
'''(Files partially updated: 2006.06.25)'''
tinprep.sh
tinbuild.sh

If you want to use your own scripts instead make sure to adapt the lines that call tinprep.sh and tinbuild.sh in tin-main.pl.

In addition to these files you need to install the Sender.pm Perl module from CPAN. See the [[CPAN_install]] page for details about getting/installing perl modules.

== Configuration ==
A few files have to be adapted to match your local setup. Changes only have to be done in areas marked with:
"# -- End of Things to tweak --"

<ul>
<li>tin-main.pl These variables need to be adapted (Follow the example in the source):<pre>
$tinsend::FROMADDRESS
</pre>
For smtpservers that doesn't need authentification just enter the server name:
<pre>
$tinsend::SMTPAUTH = '';
$tinsend::SMTPSERVER = 'smtpserver.without_pw.org';
$tinsend::SMTPAUTHID = '';
$tinsend::SMTPAUTHPW = '';
</pre>
If the smtpserver needs authentification set $SMTPAUTH to 'LOGIN' and set your username and password:
<pre>
$tinsend::SMTPAUTH = 'LOGIN';
$tinsend::SMTPSERVER = 'smtpserver.without_pw.org';
$tinsend::SMTPAUTHID = 'userid';
$tinsend::SMTPAUTHPW = 'password';
</pre>
</li>
<li>tinbuild.sh Set the options to configure your OOo build.
</li>

<li>tinprep.sh OOo needs some things prepared before it can be build. Things like that go into this file.
</li>
</ul>

== Start the tinderbox build ==
The build is then started with:

./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

The first parameter sets the name the build identifies itself, the second gives the target directory the source is build in, the third sets which CWS/MWS is used (see [http://www.go-oo.org/tinderbox/ here] for allowed values), the fourth how the source is obtained/treated (checked out from cvs in this case) and the last one says that the buildlog is send to the tinderbox. The parameters are discussed in detail later in this document.

= Documentation =

The following part describes the used scripts and useful parameters. (The markup needs a brush-up.)

<pre>
tin-main.pl
Syntax (all five parameters are needed):
tin-main.pl buildstring src_path ws {co|up|cont|clean} {send|nosend} [buildshell]
buildstring - Name that will appear in the tinderbox
src_path - Pointing to source to be used
ws - Which workspace shall be build. It accepts CWSs names (from the
list in <http://go-oo.org/tinderbox/tags/tag-list>) or all MWSs
starting with ???680_m*.
co|up|cont|clean - Tells the script what to do with src_path. Fresh checkout,
update a current repo (this also deletes modified/extra files),
do nothing, just start/continue with current repo, and clean
removes all wntmsci10.pro before rebuilding.
send|nosend - send the logfile to the tinderbox (or not)
buildshell - Choose from tcsh, bash or 4nt which shell to use for the build.
This parameter is optional, the default is tcsh.

The main program that starts the build, captures the logfile and sends it to
the tinderbox.

Example: ./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

tinsend.pl
This module handles sending of mails with attachments. This was necessary
because the windows build logs are easily 30MB or more and in our early
setups this was just to much to be handled by some SMTP servers and also
for go-oo.org. See some documentation inline in that file.

tinget.pl
Syntax (all four parameters are needed):
tinget.pl ws buildlog src_path {co|up|cont|clean}
ws - See tinder-main.pl.
buildlog - logfile name (this is send to the tinderbox)
src_path - See tinder-main.pl.
{co|up|cont|clean} - See tinder-main.pl.

This script does the workspace (src_path) handling.

tinbuild.sh
Syntax:
tinbuild.sh ws buildlog src_path [buildshell]
Parameter see tinder-main.pl, buildshell is optional.

The actual build script that starts the build and captures the logfile.

tinprep.sh
Syntax:
tinprep.sh src_path [ws] [buildshell]
Parameter see tinder-main.pl, ws and buildshell are optional.

Prepare the workspace for the build
</pre>

= Alternative tinderbox script =

'''Please note that this script is independent of the framework mentioned above. Don't mix the instructions!'''

If you don't want to use the modular framework you can still use the former, not mail-compressing version. Get the [http://go-ooo.org/tinder-scripts/tinder-build tinder-build] script and edit it to suit your needs:

The script will get http://go-oo.org/tinderbox/tags/tag-list and build all of the included CWSs. You will want to change that.

Choose a buildname
$BUILDNAME = 'My BuildName';

This script already includes a build script. You have to work through this to adapt it to your needs.

'''Mailer''' - you need a mailer to send mail with tinder-build, check that you have sendmail configured right, or hack the script to use your mailer.
$MTA = '/usr/bin/mail';

= Problem - It sends fine but nothing shows up =

There are two issues that may cause this. First, the tinderbox web-pages are re-built every 10 minutes using a cron job; so wait for 11 before getting to concerned.

The second thing is more crucial, since the tinderbox organises the logs chronologically, it is vital to ensure that your system time is not ahead of the tinderbox's, and that it is in the same decade, week, hour, minute etc.

Finally, it's possible that someone else has sent in corrupt logs that are stopping the script completing. See [http://go-ooo.org/tinderbox/tinderbox.log here] if the mail arrived, [http://go-ooo.org/tinderbox/tinderbox2.log here] if there were errors processing it and [http://go-ooo.org/tinderbox/err-log here] for any potential error messages from the demon.

Tinderbox Setup

2006-06-26T20:05:14Z

Vq: Document new parameters

Disclaimer! I tested the tinderbox scripts that are described on this page only with W32-tcsh but they should work with any *NIX like system. They are to be considered of beta quality only. Patches are very much appreciated.

----

= What is tinderbox =

In essence tinderbox is a perl script that processes mail and turns it into HTML. It expects to be mailed build logs from separate and de-coupled build machines. Tinderbox has a few elaborations over the most simple 'status' web-page, inasmuch that it integrates with bonsai - to correlate builds against commits, and it has some nice built in error-parsers to allow huge build logs to be condensed to just a few (possible) tricky sections.

Our [http://go-oo.org/tinderbox/ tinderbox] uses the [http://www.mozilla.org/tinderbox.html Tinderbox 2] from the mozilla project plus some small cosmetic changes. Additional documentation can be found there.

= Setting up a build slave =
To do this, you need to be able to build OO.o already; if you can't do this start here: [[Building]].

The framework that is described in the following sections can be used to build "new" and "Ready-for-QA" CWSs and MWSs of the 680er codeline. The source is fetched from cvs.

See [http://www.go-oo.org/tinderbox/ this] webpage for a list of the currently accepted tags. You will find the build logs (providing there are any) when you click on the corresponding tag.

== Requirements ==

A mininimal framework to build OOo CWSs and MWSs and sent the reports to the tinderbox at go-oo.org is created by the following files.

These three files from [http://go-ooo.org/tinder-scripts/ this] directory are needed to refresh the build tree and send the build log after the build:
'''(Files partially updated: 2006.06.25)'''
tin-main.pl
tinget.pl
tinsend.pm

In principle any build/preparation script can be used but the following two files (also from [http://go-ooo.org/tinder-scripts/ here]) work together with the main tinderbox slave script mentioned above (tin-main.pl):
'''(Files partially updated: 2006.06.25)'''
tinprep.sh
tinbuild.sh

If you want to use your own scripts instead make sure to adapt the lines that call tinprep.sh and tinbuild.sh in tin-main.pl.

In addition to these files you need to install the Sender.pm Perl module from CPAN. See the [[CPAN_install]] page for details about getting/installing perl modules.

== Configuration ==
A few files have to be adapted to match your local setup. Changes only have to be done in areas marked with:
"# -- End of Things to tweak --"

<ul>
<li>tin-main.pl These variables need to be adapted (Follow the example in the source):<pre>
$tinsend::FROMADDRESS
</pre>
For smtpservers that doesn't need authentification just enter the server name:
<pre>
$tinsend::SMTPAUTH = '';
$tinsend::SMTPSERVER = 'smtpserver.without_pw.org';
$tinsend::SMTPAUTHID = '';
$tinsend::SMTPAUTHPW = '';
</pre>
If the smtpserver needs authentification set $SMTPAUTH to 'LOGIN' and set your username and password:
<pre>
$tinsend::SMTPAUTH = 'LOGIN';
$tinsend::SMTPSERVER = 'smtpserver.without_pw.org';
$tinsend::SMTPAUTHID = 'userid';
$tinsend::SMTPAUTHPW = 'password';
</pre>
</li>
<li>tinbuild.sh Set the options to configure your OOo build.
</li>

<li>tinprep.sh OOo needs some things prepared before it can be build. Things like that go into this file.
</li>
</ul>

== Start the tinderbox build ==
The build is then started with:

./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

The first parameter sets the name the build identifies itself, the second gives the target directory the source is build in, the third sets which CWS/MWS is used (see [http://www.go-oo.org/tinderbox/ here] for allowed values), the fourth how the source is obtained/treated (checked out from cvs in this case) and the last one says that the buildlog is send to the tinderbox. The parameters are discussed in detail later in this document.

= Documentation =

The following part describes the used scripts and useful parameters. (The markup needs a brush-up.)

<pre>
tin-main.pl
Syntax (all five parameters are needed):
tin-main.pl buildstring src_path ws {co|up|cont|clean} {send|nosend} [buildshell]
buildstring - Name that will appear in the tinderbox
src_path - Pointing to source to be used
ws - Which workspace shall be build. It accepts CWSs names (from the
list in <http://go-oo.org/tinderbox/tags/tag-list>) or all MWSs
starting with ???680_m*.
co|up|cont|clean - Tells the script what to do with src_path. Fresh checkout,
update a current repo (this also deletes modified/extra files),
do nothing, just start/continue with current repo, and clean
removes all wntmsci10.pro before rebuilding.
send|nosend - send the logfile to the tinderbox (or not)
buildshell - Choose from tcsh, bash or 4nt which shell to use for the build.
This parameter is optional, the default is tcsh.

The main program that starts the build, captures the logfile and sends it to
the tinderbox.

Example: ./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

tinsend.pl
This module handles sending of mails with attachments. This was necessary
because the windows build logs are easily 30MB or more and in our early
setups this was just to much to be handled by some SMTP servers and also
for go-oo.org. See some documentation inline in that file.

tinget.pl
Syntax (all four parameters are needed):
tinget.pl ws buildlog src_path {co|up|cont|clean}
ws - See tinder-main.pl.
buildlog - logfile name (this is send to the tinderbox)
src_path - See tinder-main.pl.
{co|up|cont|clean} - See tinder-main.pl.

This script does the workspace (src_path) handling.

tinbuild.sh
Syntax:
tinbuild.sh ws buildlog src_path [buildshell]
Parameter see tinder-main.pl, buildshell is optional.

The actual build script that starts the build and captures the logfile.

tinprep.sh
Syntax:
tinprep.sh src_path [ws] [buildshell]
Parameter see tinder-main.pl, ws and buildshell are optional.

Prepare the workspace for the build
</pre>

= Alternative tinderbox script =

'''Please note that this script is independent of the framework mentioned above. Don't mix the instructions!'''

If you don't want to use the modular framework you can still use the former, not mail-compressing version. Get the [http://go-ooo.org/tinder-scripts/tinder-build tinder-build] script and edit it to suit your needs:

The script will get http://go-oo.org/tinderbox/tags/tag-list and build all of the included CWSs. You will want to change that.

Choose a buildname
$BUILDNAME = 'My BuildName';

This script already includes a build script. You have to work through this to adapt it to your needs.

'''Mailer''' - you need a mailer to send mail with tinder-build, check that you have sendmail configured right, or hack the script to use your mailer.
$MTA = '/usr/bin/mail';

= Problem - It sends fine but nothing shows up =

There are two issues that may cause this. First, the tinderbox web-pages are re-built every 10 minutes using a cron job; so wait for 11 before getting to concerned.

The second thing is more crucial, since the tinderbox organises the logs chronologically, it is vital to ensure that your system time is not ahead of the tinderbox's, and that it is in the same decade, week, hour, minute etc.

Finally, it's possible that someone else has sent in corrupt logs that are stopping the script completing. See [http://go-ooo.org/tinderbox/tinderbox.log here] if the mail arrived, [http://go-ooo.org/tinderbox/tinderbox2.log here] if there were errors processing it and [http://go-ooo.org/tinderbox/err-log here] for any potential error messages from the demon.

Tinderbox Setup

2006-06-26T19:42:46Z

Vq: Minor changes in framework scripts

Disclaimer! I tested the tinderbox scripts that are described on this page only with W32-tcsh but they should work with any *NIX like system. They are to be considered of beta quality only. Patches are very much appreciated.

----

= What is tinderbox =

In essence tinderbox is a perl script that processes mail and turns it into HTML. It expects to be mailed build logs from separate and de-coupled build machines. Tinderbox has a few elaborations over the most simple 'status' web-page, inasmuch that it integrates with bonsai - to correlate builds against commits, and it has some nice built in error-parsers to allow huge build logs to be condensed to just a few (possible) tricky sections.

Our [http://go-oo.org/tinderbox/ tinderbox] uses the [http://www.mozilla.org/tinderbox.html Tinderbox 2] from the mozilla project plus some small cosmetic changes. Additional documentation can be found there.

= Setting up a build slave =
To do this, you need to be able to build OO.o already; if you can't do this start here: [[Building]].

The framework that is described in the following sections can be used to build "new" and "Ready-for-QA" CWSs and MWSs of the 680er codeline. The source is fetched from cvs.

See [http://www.go-oo.org/tinderbox/ this] webpage for a list of the currently accepted tags. You will find the build logs (providing there are any) when you click on the corresponding tag.

== Requirements ==

A mininimal framework to build OOo CWSs and MWSs and sent the reports to the tinderbox at go-oo.org is created by the following files.

These three files from [http://go-ooo.org/tinder-scripts/ this] directory are needed to refresh the build tree and send the build log after the build:
'''(Files partially updated: 2006.06.25)'''
tin-main.pl
tinget.pl
tinsend.pm

In principle any build/preparation script can be used but the following two files (also from [http://go-ooo.org/tinder-scripts/ here]) work together with the main tinderbox slave script mentioned above (tin-main.pl):
'''(Files partially updated: 2006.06.25)'''
tinprep.sh
tinbuild.sh

If you want to use your own scripts instead make sure to adapt the lines that call tinprep.sh and tinbuild.sh in tin-main.pl.

In addition to these files you need to install the Sender.pm Perl module from CPAN. See the [[CPAN_install]] page for details about getting/installing perl modules.

== Configuration ==
A few files have to be adapted to match your local setup. Changes only have to be done in areas marked with:
"# -- End of Things to tweak --"

<ul>
<li>tin-main.pl These variables need to be adapted (Follow the example in the source):<pre>
$tinsend::FROMADDRESS
</pre>
For smtpservers that doesn't need authentification just enter the server name:
<pre>
$tinsend::SMTPAUTH = '';
$tinsend::SMTPSERVER = 'smtpserver.without_pw.org';
$tinsend::SMTPAUTHID = '';
$tinsend::SMTPAUTHPW = '';
</pre>
If the smtpserver needs authentification set $SMTPAUTH to 'LOGIN' and set your username and password:
<pre>
$tinsend::SMTPAUTH = 'LOGIN';
$tinsend::SMTPSERVER = 'smtpserver.without_pw.org';
$tinsend::SMTPAUTHID = 'userid';
$tinsend::SMTPAUTHPW = 'password';
</pre>
</li>
<li>tinbuild.sh Set the options to configure your OOo build.
</li>

<li>tinprep.sh OOo needs some things prepared before it can be build. Things like that go into this file.
</li>
</ul>

== Start the tinderbox build ==
The build is then started with:

./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

The first parameter sets the name the build identifies itself, the second gives the target directory the source is build in, the third sets which CWS/MWS is used (see [http://www.go-oo.org/tinderbox/ here] for allowed values), the fourth how the source is obtained/treated (checked out from cvs in this case) and the last one says that the buildlog is send to the tinderbox. The parameters are discussed in detail later in this document.

= Documentation =

The following part describes the used scripts and useful parameters. (The markup needs a brush-up.)

<pre>
tin-main.pl
Syntax (all five parameters are needed):
tin-main.pl buildstring src_path ws {co|up|cont|clean} {send|nosend}
buildstring - Name that will appear in the tinderbox
src_path - Pointing to source to be used
ws - Which workspace shall be build. It accepts CWSs names (from the
list in <http://go-oo.org/tinderbox/tags/tag-list>) or all MWSs
starting with ???680_m*.
co|up|cont|clean - Tells the script what to do with src_path. Fresh checkout,
update a current repo (this also deletes modified/extra files),
do nothing, just start/continue with current repo, and clean
removes all wntmsci10.pro before rebuilding.
send|nosend - send the logfile to the tinderbox (or not)

The main program that starts the build, captures the logfile and sends it to
the tinderbox.

Example: ./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

tinsend.pl
This module handles sending of mails with attachments. This was necessary
because the windows build logs are easily 30MB or more and in our early
setups this was just to much to be handled by some SMTP servers and also
for go-oo.org. See some documentation inline in that file.

tinget.pl
Syntax (all four parameters are needed):
tinget.pl ws buildlog src_path {co|up|cont|clean}
ws - See tinder-main.pl.
buildlog - logfile name (this is send to the tinderbox)
src_path - See tinder-main.pl.
{co|up|cont|clean} - See tinder-main.pl.

This script does the workspace (src_path) handling.

tinbuild.sh
Syntax:
tinbuild.sh ws buildsys buildlog src_path
Parameter see tinder-main.pl, buildsys includes {cyg|4nt} but can also
handle several special cases.

The actual build script that starts the build and captures the logfile.

tinprep.sh
Syntax:
tinprep.sh src_path

Prepare the workspace for the build
</pre>

= Alternative tinderbox script =

'''Please note that this script is independent of the framework mentioned above. Don't mix the instructions!'''

If you don't want to use the modular framework you can still use the former, not mail-compressing version. Get the [http://go-ooo.org/tinder-scripts/tinder-build tinder-build] script and edit it to suit your needs:

The script will get http://go-oo.org/tinderbox/tags/tag-list and build all of the included CWSs. You will want to change that.

Choose a buildname
$BUILDNAME = 'My BuildName';

This script already includes a build script. You have to work through this to adapt it to your needs.

'''Mailer''' - you need a mailer to send mail with tinder-build, check that you have sendmail configured right, or hack the script to use your mailer.
$MTA = '/usr/bin/mail';

= Problem - It sends fine but nothing shows up =

There are two issues that may cause this. First, the tinderbox web-pages are re-built every 10 minutes using a cron job; so wait for 11 before getting to concerned.

The second thing is more crucial, since the tinderbox organises the logs chronologically, it is vital to ensure that your system time is not ahead of the tinderbox's, and that it is in the same decade, week, hour, minute etc.

Finally, it's possible that someone else has sent in corrupt logs that are stopping the script completing. See [http://go-ooo.org/tinderbox/tinderbox.log here] if the mail arrived, [http://go-ooo.org/tinderbox/tinderbox2.log here] if there were errors processing it and [http://go-ooo.org/tinderbox/err-log here] for any potential error messages from the demon.

CPAN install

2006-06-16T17:29:00Z

Vq: /* Troubleshooting */

=Short guide for CPAN downloads=
As you might need to install additional perl modules to build OOo 2.0 or to use the tinderbox script this document describes briefly how to access and use CPAN.

==What is CPAN?==
CPAN is the Comprehensive Perl Archive Network, a large collection of Perl software and documentation. You can begin exploring from either http://www.cpan.org/, http://www.perl.com/CPAN/ or any of the mirrors listed at http://www.cpan.org/SITES.html and http://mirror.cpan.org/.

Note that CPAN is also the name of a Perl module, CPAN.pm, which is used to download and install Perl software from the CPAN archive.

This page tells you only enough to use this Perl module to install additional perl modules. You may find the documentation for it by using perldoc CPAN via the command line or on the web at http://search.cpan.org/author/JHI/perl-5.8.0/lib/CPAN.pm.

==Install a module with CPAN.==

If you are behind a firewall set FTP_PASSIVE to 1.

$ export FTP_PASSIVE="1"

Start the CPAN module.

$ perl -MCPAN -e shell

If this is your first time you use this module you have to answer some questions of this module. Just follow the directions on your screen.

For example, if you want to install the Mail::Sender module do it like:

cpan> install Mail::Sender

Typing help gets you some online help.

cpan> help

And typing quit quits the module.

cpan> quit

This is everything you need to know to use the CPAN module.

==Troubleshooting==

'''Problem:''' Win32/Cygwin: /bin/sh: -c: line 0: unexpected EOF while looking for matching `"'

'''Solution:''' Either your LIB or INCLUDE environment variable ends with a trailing "\" (backslash). This backslash espaces a double quote used by certain makefiles to protect variables passed to the shell. The shell then can't find the matching double quote and dies. This happens notably with SOAP::Lite and other CWS cpan modules.

'''Note:''' If you really have the environment variables LIB and INCLUDE set better consider yourself a wizard that is able to deal with CPAN (compiling cygwin programs in general) problems as you are most propably mixing gcc and MSVC here. Don't set LIB and INCLUDE, the OOo build doesn't need them.

Windows

2006-05-10T18:31:30Z

Vq: /* Miscellaneous info */

== Welcome to OOo development for Windows ==

This is an initial attempt to fill out information for building on Windows.
If it ends up being complete, this notice can be removed! At the moment you'll have to piece together information from [[#See also|other pages]] with the changes here for doing it on Windows.

Most of this wiki assumes that you'll be using a reasonably current Linux system, as a time saving feature. While real hackers prefer [http://www.gnu.org Free software], if you're forced to build stuff for Windows, this is the place to be.

== Development Tools ==

There have been several different ways of building with more or less success...

The reference page to look at is [http://tools.openoffice.org/dev_docs/build_windows_tcsh.html Building under Windows with tcsh]

Other ways to build are documented below, the official way requires Visual C++ .NET 2003

=== Visual C++ .NET 2003 Professional ===

This is the full version of Visual C++. It is the official way to build OpenOffice.org.

=== Visual C++ .NET 2003 Standard (approx $109 price) ===

You can use the Standard version of Visual Studio to build OpenOffice but there are certain workarounds needed. The problem is that OO.o enables /O flags in Professional that conveniently cripples the compiler enough to hide some ugly hacks and bugs that have crept in over the years. Standard does not support optimizations so suddenly these beasts get out in the open. See [[BuildingMSVCStandard]]

=== Visual C++ Toolkit 2003 ===

[http://msdn.microsoft.com/visualc/vctoolkit2003/ Visual C++ Toolkit 2003] is not currently usable because it doesn't contain all the libraries required for building OpenOffice.org. See [http://www.openoffice.org/issues/show_bug.cgi?id=51145 Issue 51145] for progress on this issue.

TODO: fill in all the required libraries, and possible alternatives - in the issue.

=== MinGW ===

[http://www.mingw.org/ MinGW] is basically gcc for Windows, without requiring the POSIX compatibility layer that CygWin provides. You can use the CygWin compiler with the -mno-cygwin switch and it has the same effect.

MinGW is not officially supported at the moment, so it will probably take some work to get it

Work to build OpenOffice.org with MinGW is at [http://qa.openoffice.org/issues/show_bug.cgi?id=24588 issue 24588] ; however this mostly deals with OpenOffice.org 1.1 branch at the moment.

== Using vanilla source ==

While ooo-build has been developed to make building OOo less painful, you might also try to start out with the standard source code. After you download and unpack a vanilla ooo source tarball, running "configure" in the directory "config_office" will gladly complain about missing build-dependencies. The remaining build process is described in the document [http://tools.openoffice.org/dev_docs/build_windows_tcsh.html Building under Windows with tcsh]

== Using ooo-build ==

These are addenda to using ooo-build with the following command line:
./configure --with-win32

ooo-build should pick up all the other requirements for you automatically (reading them out of the registry)

=== Extra requirements ===

* Cygwin requires the cabextract package.

== Miscellaneous info ==

* csc.exe comes from the c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322 directory, you might need <tt>--with-csc-path</tt>.
* Beware of using <tt>/c/</tt> instead of <tt>/cygdrive/c/</tt>.
* Avoid trailing slashes in configure parameters. They sure cause problems for <tt>--with-psdk-home</tt>.
<ul>
<li>Using the latest cygwin releases (1.5.18/1.5.19) can lead to tcsh freezing in places - the build will appear to hang. You can fix this by running ''ls /proc/$nnn/fd'' where $nnn is the number of the process. Or just run
<pre>
ls /proc/*/fd
</pre>
to "unhang" the process. See [http://www.openoffice.org/issues/show_bug.cgi?id=51560 issue 51560] for more info...

Noone so far created a reproducible hang that doesn't require the whole OOo environment, and to make it worse, there are those who cannot reproduce the hang at all ( Works fine here ;) ([[User:Vq]]) ). Until someone provides a recipe to reproduce this problem with a '''small''' testcase we have to hope that the cygwin developers accidentally fix this problem.
</li>
</ul>
* With cygwin 1.5.18, makecab.exe hangs when run from the build process (but it works fine when run standalone). So you definitely want to use a snapshot and '''avoid cygwin 1.5.18''', unless you enjoy wasting half a week of your life debugging like I did ...
* With later Cygwin versions (various 1.5.19 and 1.5.20 snapshots) hangs have been noticed at least by me ([[User:TorLillqvist]]) at various stages of the build on a hyperthreading (Pentium 4) machine, while doing the same build using the exact same Cygwin version on a single-processor machine worked fine. So it might be a good idea to turn off hyperthreading.
* If you get errors like "too long line in ddf file" during the MSI installer build this is caused by too long filenames. Try setting your TEMP/TMP environment variable to something short like "C:\tmp". There is a 255 char line limit for dds files and class names like "InvalidAuthenticationMechanismException" push the envelope. Shaving of 10-15 chars puts us back just under the limit.
<ul>
<li> '''Avoid using winzip''' to extract the downloaded source archive. Observed problems include:
* CR-LF errors that can affect makefiles and cause compile errors
* Certain files unpacked into root folder, esp. likely when actual path is deeply nested (e.g. foo/bar/source/foo/java/org/x/y/z/w/LongFileName.hmm) which again causes mysterious compile errors.
Use the tar from Cygwin instead:
<pre>
tar xvzf OOo_2.0.2_src.tar.gz
</pre>
</li>
</ul>

== See also ==

* To get started from scratch you most likely need to follow these steps (from the Linux version): [[Getting It]], [[Building]], [[Installing]], [[Running]]
* [[Windows Debugging]]
* [[Windows Tips]]
* [[Windows Installer Hacking]]

[[Category: Porting]]

Windows

2006-04-12T19:06:38Z

Vq: /* Miscellaneous info */

== Welcome to OOo development for Windows ==

This is an initial attempt to fill out information for building on Windows.
If it ends up being complete, this notice can be removed! At the moment you'll have to piece together information from [[#See also|other pages]] with the changes here for doing it on Windows.

Most of this wiki assumes that you'll be using a reasonably current Linux system, as a time saving feature. While real hackers prefer [http://www.gnu.org Free software], if you're forced to build stuff for Windows, this is the place to be.

== Development Tools ==

There have been several different ways of building with more or less success...

The reference page to look at is [http://tools.openoffice.org/dev_docs/build_windows_tcsh.html Building under Windows with tcsh]

Other ways to build are documented below, the official way requires Visual C++ .NET 2003

=== Visual C++ .NET 2003 Professional ===

This is the full version of Visual C++. It is the official way to build OpenOffice.org.

=== Visual C++ .NET 2003 Standard (approx $109 price) ===

You can use the Standard version of Visual Studio to build OpenOffice but there are certain workarounds needed. The problem is that OO.o enables /O flags in Professional that conveniently cripples the compiler enough to hide some ugly hacks and bugs that have crept in over the years. Standard does not support optimizations so suddenly these beasts get out in the open. See [[BuildingMSVCStandard]]

=== Visual C++ Toolkit 2003 ===

[http://msdn.microsoft.com/visualc/vctoolkit2003/ Visual C++ Toolkit 2003] is not currently usable because it doesn't contain all the libraries required for building OpenOffice.org. See [http://www.openoffice.org/issues/show_bug.cgi?id=51145 Issue 51145] for progress on this issue.

TODO: fill in all the required libraries, and possible alternatives - in the issue.

=== MinGW ===

[http://www.mingw.org/ MinGW] is basically gcc for Windows, without requiring the POSIX compatibility layer that CygWin provides. You can use the CygWin compiler with the -mno-cygwin switch and it has the same effect.

MinGW is not officially supported at the moment, so it will probably take some work to get it

Work to build OpenOffice.org with MinGW is at [http://qa.openoffice.org/issues/show_bug.cgi?id=24588 issue 24588] ; however this mostly deals with OpenOffice.org 1.1 branch at the moment.

== Using vanilla source ==

While ooo-build has been developed to make building OOo less painful, you might also try to start out with the standard source code. After you download and unpack a vanilla ooo source tarball, running "configure" in the directory "config_office" will gladly complain about missing build-dependencies. The remaining build process is described in the document [http://tools.openoffice.org/dev_docs/build_windows_tcsh.html Building under Windows with tcsh]

== Using ooo-build ==

These are addenda to using ooo-build with the following command line:
./configure --with-win32

ooo-build should pick up all the other requirements for you automatically (reading them out of the registry)

=== Extra requirements ===

* Cygwin requires the cabextract package.

== Miscellaneous info ==

* csc.exe comes from the c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322 directory, you might need <tt>--with-csc-path</tt>.
* Beware of using <tt>/c/</tt> instead of <tt>/cygdrive/c/</tt>.
* Avoid trailing slashes in configure parameters. They sure cause problems for <tt>--with-psdk-home</tt>.
<ul>
<li>Using the latest cygwin release (1.5.18) can lead to tcsh freezing in places - the build will appear to hang. you can fix this by using the latest snapshot (e.g. 20051114) or running ''ls /proc/$nnn/fd'' where $nnn is the number of the process. Or just run
<pre>
ls /proc/*/fd
</pre>
to "unhang" the process. See [http://www.openoffice.org/issues/show_bug.cgi?id=51560 issue 51560] for more info...
</li>
</ul>
* With cygwin 1.5.18, makecab.exe hangs when run from the build process (but it works fine when run standalone). So you definitely want to use a snapshot and '''avoid cygwin 1.5.18''', unless you enjoy wasting half a week of your life debugging like I did ...
* With later Cygwin versions (various 1.5.19 and 1.5.20 snapshots) hangs have been noticed at least by me ([[User:TorLillqvist]]) at various stages of the build on a hyperthreading (Pentium 4) machine, while doing the same build using the exact same Cygwin version on a single-processor machine worked fine. So it might be a good idea to turn off hyperthreading.
* If you get errors like "too long line in ddf file" during the MSI installer build this is caused by too long filenames. Try setting your TEMP/TMP environment variable to something short like "C:\tmp". There is a 255 char line limit for dds files and class names like "InvalidAuthenticationMechanismException" push the envelope. Shaving of 10-15 chars puts us back just under the limit.
<ul>
<li> '''Avoid using winzip''' to extract the downloaded source archive. Observed problems include:
* CR-LF errors that can affect makefiles and cause compile errors
* Certain files unpacked into root folder, esp. likely when actual path is deeply nested (e.g. foo/bar/source/foo/java/org/x/y/z/w/LongFileName.hmm) which again causes mysterious compile errors.
Use the tar from Cygwin instead:
<pre>
tar xvzf OOo_2.0.2_src.tar.gz
</pre>
</li>
</ul>

== See also ==

* To get started from scratch you most likely need to follow these steps (from the Linux version): [[Getting It]], [[Building]], [[Installing]], [[Running]]
* [[Windows Debugging]]
* [[Windows Tips]]
* [[Windows Installer Hacking]]

[[Category: Porting]]

Tinderbox Setup

2006-04-12T17:35:26Z

Vq: Remove spam

Disclaimer! I tested the tinderbox scripts that are described on this page only with W32-tcsh but they should work with any *NIX like system. They are to be considered of beta quality only. Patches are very much appreciated.

----

= What is tinderbox =

In essence tinderbox is a perl script that processes mail, and turns it into HTML. It expects to be mailed build logs from separate and de-coupled build machines. Tinderbox has a few elaborations over the most simple 'status' web-page, inasmuch that it integrates with bonsai - to correlate builds against commits, and it has some nice built in error-parsers to allow huge build logs to be condensed to just a few (possible) tricky sections.

Our [http://go-oo.org/tinderbox/ tinderbox] uses the [http://www.mozilla.org/tinderbox.html Tinderbox 2] from the mozilla project plus some small cosmetic changes. Additional documentation can be found there.

= Setting up a build slave =
To do this, you need to be able to build OO.o already; if you can't do this start here: [[Building]].

The framework that is described in the following sections can be used to build "new" and "Ready-for-QA" CWSs and MWSs of the 680er codeline. The source is fetched from cvs.

See [http://www.go-oo.org/tinderbox/ this] webpage for a list of the currently accepted tags. You will find the build logs (providing there are any) when you click on the corresponding tag.

== Requirements ==

A mininimal framework to build OOo CWSs and MWSs and sent the reports to the tinderbox at go-oo.org is created by the following files.

These three files from [http://go-ooo.org/tinder-scripts/ this] directory are needed to refresh the build tree and send the build log after the build:
'''(Files partially updated: 2006.02.25)'''
tin-main.pl
tinget.pl
tinsend.pm

In principle any build/preparation script can be used but the following two files (also from [http://go-ooo.org/tinder-scripts/ here]) work together with the main tinderbox slave script mentioned above (tin-main.pl):
'''(Files partially updated: 2006.02.25)'''
tinprep.sh
tinbuild.sh

If you want to use your own scripts instead make sure to adapt the lines that call tinprep.sh and tinbuild.sh in tin-main.pl.

In addition to these files you need to install the Sender.pm Perl module from CPAN. See the CPAN link <http://go-ooo.org/cpan.html> for details about getting this module.

== Configuration ==
A few files have to be adapted to match your local setup. Changes only have to be done in areas marked with:
"# -- End of Things to tweak --"

<ul>
<li>tin-main.pl These variables need to be adapted (Follow the example in the source):<pre>
$tinsend::FROMADDRESS
</pre>
For smtpservers that doesn't need authentification just enter the server name:
<pre>
$tinsend::SMTPAUTH = '';
$tinsend::SMTPSERVER = 'smtpserver.without_pw.org';
$tinsend::SMTPAUTHID = '';
$tinsend::SMTPAUTHPW = '';
</pre>
If the smtpserver needs authentification set $SMTPAUTH to 'LOGIN' and set your username and password:
<pre>
$tinsend::SMTPAUTH = 'LOGIN';
$tinsend::SMTPSERVER = 'smtpserver.without_pw.org';
$tinsend::SMTPAUTHID = 'userid';
$tinsend::SMTPAUTHPW = 'password';
</pre>
</li>
<li>tinbuild.sh Set the options to configure your OOo build.
</li>

<li>tinprep.sh OOo needs some things prepared before it can be build. Things like that go into this file.
</li>
</ul>

== Start the tinderbox build ==
The build is then started with:

./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

The first parameter sets the name the build identifies itself, the second gives the target directory the source is build in, the third sets which CWS/MWS is used (see [http://www.go-oo.org/tinderbox/ here] for allowed values), the fourth how the source is obtained/treated (checked out from cvs in this case) and the last one says that the buildlog is send to the tinderbox. The parameters are discussed in detail later in this document.

= Documentation =

The following part describes the used scripts and useful parameters. (The markup needs a brush-up.)

<pre>
tin-main.pl
Syntax (all five parameters are needed):
tin-main.pl buildstring src_path ws {co|up|cont|clean} {send|nosend}
buildstring - Name that will appear in the tinderbox
src_path - Pointing to source to be used
ws - Which workspace shall be build. It accepts CWSs names (from the
list in <http://go-oo.org/tinderbox/tags/tag-list>) or all MWSs
starting with ???680_m*.
co|up|cont|clean - Tells the script what to do with src_path. Fresh checkout,
update a current repo (this also deletes modified/extra files),
do nothing, just start/continue with current repo, and clean
removes all wntmsci10.pro before rebuilding.
send|nosend - send the logfile to the tinderbox (or not)

The main program that starts the build, captures the logfile and sends it to
the tinderbox.

Example: ./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

tinsend.pl
This module handles sending of mails with attachments. This was necessary
because the windows build logs are easily 30MB or more and in our early
setups this was just to much to be handled by some SMTP servers and also
for go-oo.org. See some documentation inline in that file.

tinget.pl
Syntax (all four parameters are needed):
tinget.pl ws buildlog src_path {co|up|cont|clean}
ws - See tinder-main.pl.
buildlog - logfile name (this is send to the tinderbox)
src_path - See tinder-main.pl.
{co|up|cont|clean} - See tinder-main.pl.

This script does the workspace (src_path) handling.

tinbuild.sh
Syntax:
tinbuild.sh ws buildsys buildlog src_path
Parameter see tinder-main.pl, buildsys includes {cyg|4nt} but can also
handle several special cases.

The actual build script that starts the build and captures the logfile.

tinprep.sh
Syntax:
tinprep.sh src_path

Prepare the workspace for the build
</pre>

= Alternative tinderbox script =

'''Please note that this script is independent of the framework mentioned above. Don't mix the instructions!'''

If you don't want to use the modular framework you can still use the former, not mail-compressing version. Get the [http://go-ooo.org/tinder-scripts/tinder-build tinder-build] script and edit it to suit your needs:

The script will get http://go-oo.org/tinderbox/tags/tag-list and build all of the included CWSs. You will want to change that.

Choose a buildname
$BUILDNAME = 'My BuildName';

This script already includes a build script. You have to work through this to adapt it to your needs.

'''Mailer''' - you need a mailer to send mail with tinder-build, check that you have sendmail configured right, or hack the script to use your mailer.
$MTA = '/usr/bin/mail';

= Problem - It sends fine but nothing shows up =

There are two issues that may cause this. First, the tinderbox web-pages are re-built every 10 minutes using a cron job; so wait for 11 before getting to concerned.

The second thing is more crucial, since the tinderbox organises the logs chronologically, it is vital to ensure that your system time is not ahead of the tinderbox's, and that it is in the same decade, week, hour, minute etc.

Finally, it's possible that someone else has sent in corrupt logs that are stopping the script completing. See [http://go-ooo.org/tinderbox/tinderbox.log here] if the mail arrived, [http://go-ooo.org/tinderbox/tinderbox2.log here] if there were errors processing it and [http://go-ooo.org/tinderbox/err-log here] for any potential error messages from the demon.

Tinderbox Setup

2006-03-31T18:23:51Z

Vq: /* remove spam */

Disclaimer! I tested the tinderbox scripts that are described on this page only with W32-tcsh but they should work with any *NIX like system. They are to be considered of beta quality only. Patches are very much appreciated.

----

= What is tinderbox =

In essence tinderbox is a perl script that processes mail, and turns it into HTML. It expects to be mailed build logs from separate and de-coupled build machines. Tinderbox has a few elaborations over the most simple 'status' web-page, inasmuch that it integrates with bonsai - to correlate builds against commits, and it has some nice built in error-parsers to allow huge build logs to be condensed to just a few (possible) tricky sections.

Our [http://go-oo.org/tinderbox/ tinderbox] uses the [http://www.mozilla.org/tinderbox.html Tinderbox 2] from the mozilla project plus some small cosmetic changes. Additional documentation can be found there.

= Setting up a build slave =
To do this, you need to be able to build OO.o already; if you can't do this start here: [[Building]].

The framework that is described in the following sections can be used to build "new" and "Ready-for-QA" CWSs and MWSs of the 680er codeline. The source is fetched from cvs.

See [http://www.go-oo.org/tinderbox/ this] webpage for a list of the currently accepted tags. You will find the build logs (providing there are any) when you click on the corresponding tag.

== Requirements ==

A mininimal framework to build OOo CWSs and MWSs and sent the reports to the tinderbox at go-oo.org is created by the following files.

These three files from [http://go-ooo.org/tinder-scripts/ this] directory are needed to refresh the build tree and send the build log after the build:
'''(Files partially updated: 2006.02.25)'''
tin-main.pl
tinget.pl
tinsend.pm

In principle any build/preparation script can be used but the following two files (also from [http://go-ooo.org/tinder-scripts/ here]) work together with the main tinderbox slave script mentioned above (tin-main.pl):
'''(Files partially updated: 2006.02.25)'''
tinprep.sh
tinbuild.sh

If you want to use your own scripts instead make sure to adapt the lines that call tinprep.sh and tinbuild.sh in tin-main.pl.

In addition to these files you need to install the Sender.pm Perl module from CPAN. See the CPAN link <http://go-ooo.org/cpan.html> for details about getting this module.

== Configuration ==
A few files have to be adapted to match your local setup. Changes only have to be done in areas marked with:
"# -- End of Things to tweak --"

<ul>
<li>tin-main.pl These variables need to be adapted (Follow the example in the source):<pre>
$tinsend::FROMADDRESS
</pre>
For smtpservers that doesn't need authentification just enter the server name:
<pre>
$tinsend::SMTPAUTH = '';
$tinsend::SMTPSERVER = 'smtpserver.without_pw.org';
$tinsend::SMTPAUTHID = '';
$tinsend::SMTPAUTHPW = '';
</pre>
If the smtpserver needs authentification set $SMTPAUTH to 'LOGIN' and set your username and password:
<pre>
$tinsend::SMTPAUTH = 'LOGIN';
$tinsend::SMTPSERVER = 'smtpserver.without_pw.org';
$tinsend::SMTPAUTHID = 'userid';
$tinsend::SMTPAUTHPW = 'password';
</pre>
</li>
<li>tinbuild.sh Set the options to configure your OOo build.
</li>

<li>tinprep.sh OOo needs some things prepared before it can be build. Things like that go into this file.
</li>
</ul>

== Start the tinderbox build ==
The build is then started with:

./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

The first parameter sets the name the build identifies itself, the second gives the target directory the source is build in, the third sets which CWS/MWS is used (see [http://www.go-oo.org/tinderbox/ here] for allowed values), the fourth how the source is obtained/treated (checked out from cvs in this case) and the last one says that the buildlog is send to the tinderbox. The parameters are discussed in detail later in this document.

= Documentation =

The following part describes the used scripts and useful parameters. (The markup needs a brush-up.)

<pre>
tin-main.pl
Syntax (all five parameters are needed):
tin-main.pl buildstring src_path ws {co|up|cont|clean} {send|nosend}
buildstring - Name that will appear in the tinderbox
src_path - Pointing to source to be used
ws - Which workspace shall be build. It accepts CWSs names (from the
list in <http://go-oo.org/tinderbox/tags/tag-list>) or all MWSs
starting with ???680_m*.
co|up|cont|clean - Tells the script what to do with src_path. Fresh checkout,
update a current repo (this also deletes modified/extra files),
do nothing, just start/continue with current repo, and clean
removes all wntmsci10.pro before rebuilding.
send|nosend - send the logfile to the tinderbox (or not)

The main program that starts the build, captures the logfile and sends it to
the tinderbox.

Example: ./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

tinsend.pl
This module handles sending of mails with attachments. This was necessary
because the windows build logs are easily 30MB or more and in our early
setups this was just to much to be handled by some SMTP servers and also
for go-oo.org. See some documentation inline in that file.

tinget.pl
Syntax (all four parameters are needed):
tinget.pl ws buildlog src_path {co|up|cont|clean}
ws - See tinder-main.pl.
buildlog - logfile name (this is send to the tinderbox)
src_path - See tinder-main.pl.
{co|up|cont|clean} - See tinder-main.pl.

This script does the workspace (src_path) handling.

tinbuild.sh
Syntax:
tinbuild.sh ws buildsys buildlog src_path
Parameter see tinder-main.pl, buildsys includes {cyg|4nt} but can also
handle several special cases.

The actual build script that starts the build and captures the logfile.

tinprep.sh
Syntax:
tinprep.sh src_path

Prepare the workspace for the build
</pre>

= Alternative tinderbox script =

'''Please note that this script is independent of the framework mentioned above. Don't mix the instructions!'''

If you don't want to use the modular framework you can still use the former, not mail-compressing version. Get the [http://go-ooo.org/tinder-scripts/tinder-build tinder-build] script and edit it to suit your needs:

The script will get http://go-oo.org/tinderbox/tags/tag-list and build all of the included CWSs. You will want to change that.

Choose a buildname
$BUILDNAME = 'My BuildName';

This script already includes a build script. You have to work through this to adapt it to your needs.

'''Mailer''' - you need a mailer to send mail with tinder-build, check that you have sendmail configured right, or hack the script to use your mailer.
$MTA = '/usr/bin/mail';

= Problem - It sends fine but nothing shows up =

There are two issues that may cause this. First, the tinderbox web-pages are re-built every 10 minutes using a cron job; so wait for 11 before getting to concerned.

The second thing is more crucial, since the tinderbox organises the logs chronologically, it is vital to ensure that your system time is not ahead of the tinderbox's, and that it is in the same decade, week, hour, minute etc.

Finally, it's possible that someone else has sent in corrupt logs that are stopping the script completing. See [http://go-ooo.org/tinderbox/tinderbox.log here] if the mail arrived, [http://go-ooo.org/tinderbox/tinderbox2.log here] if there were errors processing it and [http://go-ooo.org/tinderbox/err-log here] for any potential error messages from the demon.

Tinderbox

2006-03-18T18:16:16Z

Vq: /* What is a Tinderbox */

''Welcome to the OpenOffice.org Tinderbox page!''

This Tinderbox Wiki page is designed to be used to inform about the OpenOffice.org tinderbox and coordinate ideas and resources about the further development of the tinderbox.

A Wiki is a type of website that anybody can edit but radical changes should be discussed on the tinderbox mailing list first.

= What is a Tinderbox =

A tinderbox allows developers to test their CWSs (Workspaces) on several architectures without the need of having access to all those architectures.

Setting up tinderbox builds with the standard toolchain and maybe the newest toolchain for all of the main platforms (x86 Linux, Solaris Sparc, and Windows) and allowing volunteer developers to see the build error logs and progress will finally make developers less afraid to commit anything (fixes or advancements) for fear of breaking something for other platforms.

In essence a tinderbox is a perl script that processes mail, and turns it into HTML. It expects to be mailed build logs from separate and de-coupled build machines. Tinderbox has a few elaborations over the most simple 'status' web-page, inasmuch that it integrates with bonsai - to correlate builds against commits, and it has some nice built in error-parsers to allow huge build logs to be condensed to just a few (possible) tricky sections.

Our tinderbox uses the [http://www.mozilla.org/tinderbox.html Tinderbox 2] from the mozilla project plus some small cosmetic changes. Additional documentation can be found there.

= Last Tinderbox results =
Click the [http://go-ooo.org/tinderbox/all_trees.express.html result overview] link to get the latest build results, or check the [http://go-oo.org/tinderbox/ tinderbox] link to get a list of the currently open tinderbox trees (CWSs and MWSs).

= Set up a Tinderbox client =
Follow the [[Tinderbox_Setup]] link to get information how to set up a tinderbox client.

= Tinderbox mailing list =

Topics related to the tinderbox should be discussed on the tinderbox@tools.openoffice.org [http://tools.openoffice.org/servlets/SummarizeList?listName=tinderbox mailing list] (Send a completely blank e-mail to tinderbox-subscribe@tools.openoffice.org address to subscribe).

= OpenOffice Tinderbox ToDo list =

* Improve this page
* Create <code>tools.openoffice.org/tinderbox.html</code> linking to this page
* Discuss/create framework to allow developers to request tinderbox builds for their CWSs
* Advertise the tinderbox and attract more tinderbox clients
* Define specifications which <code>configure</code> parameters have to be used, which languages should be enabled, etc.
* Provide a means to upload installation sets from a tinderbox build to a place that allows QA of these builds. See [http://qa.openoffice.org/issues/show_bug.cgi?id=38096 issue 38096].

Tinderbox

2006-03-04T02:55:15Z

Vq:

''Welcome to the OpenOffice.org Tinderbox page!''

This Tinderbox Wiki page is designed to be used to inform about the OpenOffice.org tinderbox and coordinate ideas and resources about the further development of the tinderbox.

A Wiki is a type of website that anybody can edit but radical changes should be discussed on the tinderbox mailing list first.

= What is a Tinderbox =

A tinderbox allows developers to test their CWSs (Workspaces) on several architectures without the need of having access to all those architectures.

In essence a tinderbox is a perl script that processes mail, and turns it into HTML. It expects to be mailed build logs from separate and de-coupled build machines. Tinderbox has a few elaborations over the most simple 'status' web-page, inasmuch that it integrates with bonsai - to correlate builds against commits, and it has some nice built in error-parsers to allow huge build logs to be condensed to just a few (possible) tricky sections.

Our tinderbox uses the [http://www.mozilla.org/tinderbox.html Tinderbox 2] from the mozilla project plus some small cosmetic changes. Additional documentation can be found there.

= Last Tinderbox results =
Click the [http://go-ooo.org/tinderbox/all_trees.express.html result overview] link to get the latest build results, or check the [http://go-oo.org/tinderbox/ tinderbox] link to get a list of the currently open tinderbox trees (CWSs and MWSs).

= Set up a Tinderbox client =
Follow the [[Tinderbox_Setup]] link to get information how to set up a tinderbox client.

= Tinderbox mailing list =

Topics related to the tinderbox should be discussed on the tinderbox@tools.openoffice.org [http://tools.openoffice.org/servlets/SummarizeList?listName=tinderbox mailing list] (Send a completely blank e-mail to tinderbox-subscribe@tools.openoffice.org address to subscribe).

= OpenOffice Tinderbox ToDo list =

* Improve this page
* Create <code>tools.openoffice.org/tinderbox.html</code> linking to this page
* Discuss/create framework to allow developers to request tinderbox builds for their CWSs
* Advertise the tinderbox and attract more tinderbox clients
* Define specifications which <code>configure</code> parameters have to be used, which languages should be enabled, etc.
* Provide a means to upload installation sets from a tinderbox build to a place that allows QA of these builds. See [http://qa.openoffice.org/issues/show_bug.cgi?id=38096 issue 38096].

Tinderbox

2006-03-04T00:39:21Z

Vq: Coordination of tinderbox efforts for OpenOffice.org

''Welcome to the OpenOffice.org Tinderbox page!''

This Tinderbox Wiki page is designed to be used to inform about the OpenOffice.org tinderbox and coordinate ideas and resources about the further development of the tinderbox.

A Wiki is a type of website that anybody can edit but radical changes should be discussed on the tinderbox mailing list first.

= What is a Tinderbox =

A tinderbox allows developers to test their CWSs (Workspaces) on several architectures without the need of having access to all those architectures.

In essence a tinderbox is a perl script that processes mail, and turns it into HTML. It expects to be mailed build logs from separate and de-coupled build machines. Tinderbox has a few elaborations over the most simple 'status' web-page, inasmuch that it integrates with bonsai - to correlate builds against commits, and it has some nice built in error-parsers to allow huge build logs to be condensed to just a few (possible) tricky sections.

Our tinderbox uses the [http://www.mozilla.org/tinderbox.html Tinderbox 2] from the mozilla project plus some small cosmetic changes. Additional documentation can be found there.

= Last Tinderbox results =
Click the [http://go-ooo.org/tinderbox/all_trees.express.html result overview] link to get the latest build results, or check the [http://go-oo.org/tinderbox/ tinderbox] link to get a list of the currently open tinderbox trees (CWSs and MWSs).

= Set up a tinderbox client =
Follow the [[Tinderbox_Setup]] link to get information how to set up a tinderbox client.

= Tinderbox mailing list =

Topics related to the tinderbox should be discussed on the tinderbox@tools.openoffice.org [http://tools.openoffice.org/servlets/SummarizeList?listName=tinderbox mailing list] (Send a completely blank e-mail to tinderbox-subscribe@tools.openoffice.org address to subscribe).

= OpenOffice Tinderbox ToDo list =

* Improve this page
* Create <code>tools.openoffice.org/tinderbox.html</code> linking to this page
* Discuss/create framework to allow developers to request tinderbox builds for their CWSs
* Advertise the tinderbox and attract more tinderbox clients

Debug Build Problems

2006-02-28T22:05:53Z

Vq:

OOo can be build on several different operating systems with various configurations. Therefore it is sometimes hard to locate the actual problem when build problems arise. This page provides some guidelines which information might be necessary to solve the problem.

* Always build from a clean sources Independent from using cvs or unpacking a source archive from the download page. Whenever you changing the version (e.g. a different snapshot, Release Candidate or Release version) always remove the old sources and the solver directory completely and unpack/checkout the new version. (There might be files leftover in the source archive from the previous version that a “cvs up” or unpacking of the new source version will not remove.)

* Always use “dmake >& mybuild.log” or “build >& mybuild.log” This captures the build log and also warnings that might lead to the error. After you found a build problem do not only enter that directory and enter “build” again. This will not rebuild the whole module, and therefore you won't get a complete logfile, only the last failing command. If you want to produce a useful log first remove the object file directory (usually wntmsci10.pro, unxlngi6.pro or so.) and then enter “build” again. When submitting a bug report attach the logfile to the issue.

* Provide all switches you used to configure your build environment It is very helpful to show the command line switches you used to configure your build environment. These can be found retroactively in the first lines of '''"config_office/config.log"'''. When submitting a bug report attach this file to the issue.

* Provide information about your environment variables At least the value of the PATH variable is required. Use <code>echo $PATH</code> to get its value, you might be asked about other values.

* Provide the build environment script All environment variables that are used by the OOo build process are set by a script (e.g. '''winenv.set''' or '''unxenv.set'''). When submitting a bug report please attach this file to the issue.

Tinderbox Setup

2006-02-26T16:43:53Z

Vq: /* Requirements */

Disclaimer! I tested the tinderbox scripts that are described on this page only with W32-tcsh but they should work with any *NIX like system. They are to be considered of beta quality only. Patches are very much appreciated.

----

= What is tinderbox =

In essence tinderbox is a perl script that processes mail, and turns it into HTML. It expects to be mailed build logs from separate and de-coupled build machines. Tinderbox has a few elaborations over the most simple 'status' web-page, inasmuch that it integrates with bonsai - to correlate builds against commits, and it has some nice built in error-parsers to allow huge build logs to be condensed to just a few (possible) tricky sections.

Our [http://go-oo.org/tinderbox/ tinderbox] uses the [http://www.mozilla.org/tinderbox.html Tinderbox 2] from the mozilla project plus some small cosmetic changes. Additional documentation can be found there.

= Setting up a build slave =
To do this, you need to be able to build OO.o already; if you can't do this start here: [[Building]].

The framework that is described in the following sections can be used to build "new" and "Ready-for-QA" CWSs and MWSs of the 680er codeline. The source is fetched from cvs.

See [http://www.go-oo.org/tinderbox/ this] webpage for a list of the currently accepted tags. You will find the build logs (providing there are any) when you click on the corresponding tag.

== Requirements ==

A mininimal framework to build OOo CWSs and MWSs and sent the reports to the tinderbox at go-oo.org is created by the following files.

These three files from [http://go-ooo.org/tinder-scripts/ this] directory are needed to refresh the build tree and send the build log after the build:
'''(Files partially updated: 2006.02.25)'''
tin-main.pl
tinget.pl
tinsend.pm

In principle any build/preparation script can be used but the following two files (also from [http://go-ooo.org/tinder-scripts/ here]) work together with the main tinderbox slave script mentioned above (tin-main.pl):
'''(Files partially updated: 2006.02.25)'''
tinprep.sh
tinbuild.sh

If you want to use your own scripts instead make sure to adapt the lines that call tinprep.sh and tinbuild.sh in tin-main.pl.

In addition to these files you need to install the Sender.pm Perl module from CPAN. See the CPAN link <http://go-ooo.org/cpan.html> for details about getting this module.

== Configuration ==
A few files have to be adapted to match your local setup. Changes only have to be done in areas marked with:
"# -- End of Things to tweak --"

<ul>
<li>tin-main.pl These variables need to be adapted (Follow the example in the source):<pre>
$tinsend::FROMADDRESS
</pre>
For smtpservers that doesn't need authentification just enter the server name:
<pre>
$tinsend::SMTPAUTH = '';
$tinsend::SMTPSERVER = 'smtpserver.without_pw.org';
$tinsend::SMTPAUTHID = '';
$tinsend::SMTPAUTHPW = '';
</pre>
If the smtpserver needs authentification set $SMTPAUTH to 'LOGIN' and set your username and password:
<pre>
$tinsend::SMTPAUTH = 'LOGIN';
$tinsend::SMTPSERVER = 'smtpserver.without_pw.org';
$tinsend::SMTPAUTHID = 'userid';
$tinsend::SMTPAUTHPW = 'password';
</pre>
</li>
<li>tinbuild.sh Set the options to configure your OOo build.
</li>

<li>tinprep.sh OOo needs some things prepared before it can be build. Things like that go into this file.
</li>
</ul>

== Start the tinderbox build ==
The build is then started with:

./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

The first parameter sets the name the build identifies itself, the second gives the target directory the source is build in, the third sets which CWS/MWS is used (see [http://www.go-oo.org/tinderbox/ here] for allowed values), the fourth how the source is obtained/treated (checked out from cvs in this case) and the last one says that the buildlog is send to the tinderbox. The parameters are discussed in detail later in this document.

= Documentation =

The following part describes the used scripts and useful parameters. (The markup needs a brush-up.)

<pre>
tin-main.pl
Syntax (all five parameters are needed):
tin-main.pl buildstring src_path ws {co|up|cont|clean} {send|nosend}
buildstring - Name that will appear in the tinderbox
src_path - Pointing to source to be used
ws - Which workspace shall be build. It accepts CWSs names (from the
list in <http://go-oo.org/tinderbox/tags/tag-list>) or all MWSs
starting with ???680_m*.
co|up|cont|clean - Tells the script what to do with src_path. Fresh checkout,
update a current repo (this also deletes modified/extra files),
do nothing, just start/continue with current repo, and clean
removes all wntmsci10.pro before rebuilding.
send|nosend - send the logfile to the tinderbox (or not)

The main program that starts the build, captures the logfile and sends it to
the tinderbox.

Example: ./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

tinsend.pl
This module handles sending of mails with attachments. This was necessary
because the windows build logs are easily 30MB or more and in our early
setups this was just to much to be handled by some SMTP servers and also
for go-oo.org. See some documentation inline in that file.

tinget.pl
Syntax (all four parameters are needed):
tinget.pl ws buildlog src_path {co|up|cont|clean}
ws - See tinder-main.pl.
buildlog - logfile name (this is send to the tinderbox)
src_path - See tinder-main.pl.
{co|up|cont|clean} - See tinder-main.pl.

This script does the workspace (src_path) handling.

tinbuild.sh
Syntax:
tinbuild.sh ws buildsys buildlog src_path
Parameter see tinder-main.pl, buildsys includes {cyg|4nt} but can also
handle several special cases.

The actual build script that starts the build and captures the logfile.

tinprep.sh
Syntax:
tinprep.sh src_path

Prepare the workspace for the build
</pre>

= Alternative tinderbox script =

'''Please note that this script is independent of the framework mentioned above. Don't mix the instructions!'''

If you don't want to use the modular framework you can still use the former, not mail-compressing version. Get the [http://go-ooo.org/tinder-scripts/tinder-build tinder-build] script and edit it to suit your needs:

The script will get http://go-oo.org/tinderbox/tags/tag-list and build all of the included CWSs. You will want to change that.

Choose a buildname
$BUILDNAME = 'My BuildName';

This script already includes a build script. You have to work through this to adapt it to your needs.

'''Mailer''' - you need a mailer to send mail with tinder-build, check that you have sendmail configured right, or hack the script to use your mailer.
$MTA = '/usr/bin/mail';

= Problem - It sends fine but nothing shows up =

There are two issues that may cause this. First, the tinderbox web-pages are re-built every 10 minutes using a cron job; so wait for 11 before getting to concerned.

The second thing is more crucial, since the tinderbox organises the logs chronologically, it is vital to ensure that your system time is not ahead of the tinderbox's, and that it is in the same decade, week, hour, minute etc.

Finally, it's possible that someone else has sent in corrupt logs that are stopping the script completing. See [http://go-ooo.org/tinderbox/tinderbox.log here] if the mail arrived, [http://go-ooo.org/tinderbox/tinderbox2.log here] if there were errors processing it and [http://go-ooo.org/tinderbox/err-log here] for any potential error messages from the demon.

Debug Build Problems

2006-02-16T15:10:52Z

Vq:

OOo can be build on several different operating systems with various configurations. Therefore it is sometimes hard to locate the actual problem when build problems arise. This page provides some guidelines which information might be necessary to solve the problem.

* Always build from a clean sources Independent from using cvs or unpacking a source archive from the download page. Whenever you changing the version (e.g. a different snapshot, Release Candidate or Release version) always remove the old sources and the solver directory completely and unpack/checkout the new version. (There might be files leftover in the source archive from the previous version that a “cvs up” or unpacking of the new source version will not remove.)

* Always use “dmake >& mybuild.log” or “build >& mybuild.log” This captures the build log and also warnings that might lead to the error. After you found a build problem do not only enter that directory and enter “build” again. This will not rebuild the whole module, and therefore you won't get a complete logfile, only the last failing command. If you want to produce a useful log first remove the object file directory (usually wntmsci10.pro, unxlngi6.pro or so.) and then enter “build” again. When submitting a bug report attach the logfile to the issue.

* Provide all switches you used to configure your build environment It is very helpful to show the command line switches you used to configure your build environment. These can be found retroactively in the first lines of '''"config_office/config.log"'''. When submitting a bug report attach this file to the issue.

* Provide the build environment script All environment variables that are used by the OOo build process are set by a script (e.g. '''winenv.set''' or '''unxenv.set'''). When submitting a bug report please attach this file to the issue.

BuildingMSVCStandard

2006-02-13T19:45:15Z

Vq: /* Code changes */

== Code changes ==

What hides these issues when using Professional is more agressive inlining. Even if they all manifest with standard, they are actually separate and distinct issues. I've summarized the changes here and I'll add a patch once I've verified the impact of these changes. '''You have to do these changes before compiling'''.

Update: These are all the changes required to compile OO.o. I'm now working on a patch. --[[User:KaiB|KaiB]] 22:30, 13 January 2006 (CET)

Update: These or different changes with the same effect are implemented in m156 and will also be included in OOo 2.0.2.
--[[User:Vq|Vq]] 14:41, 13 February 2006 (EST)

=== '''sj2/util/makefile.mk''': add the SVTOOLLIB library ===

SHL1STDLIBS= \
$(VCLLIB) \
$(UNOTOOLSLIB) \
$(TOOLSLIB) \
$(CPPULIB) \
$(SALLIB) \
+$(SVTOOLLIB)

The required library was just missing from the makefile.

=== '''basic/source/apps/dialogs.cxx''' ===

1. Comment out the lines shown here starting from line 43:

//HACK( #define protected public )
//#define protected public // Kleine Schweinerei um an FreeResource ranzukommen
#ifndef _TOOLS_RC_HXX //autogen
#include <tools/rc.hxx>
#endif
//#undef protected

2. Comment out the line shown here (line 238):

aConfig.EnablePersistence( FALSE );
// aTabCtrl.FreeResource();
FreeResource();

Redefining the reserved keyword in spot 1 results in the linker trying to find a public FreeResource method while the actual one compiled into the library is protected. The error pops up in a totally unrelated module and halts the build. Spot 2 is the place that requires this workaround.

In [http://www.openoffice.org/issues/show_bug.cgi?id=58352 Issue 58352] there is a commit log of the changes needed to solve the problem and not workaround it. The fix is on CWS warnings01. (Gregor Hartmann is the basic/source/app maintainer)

=== '''tools/source/stream/stream.cxx''' (line 66): Define ENABLE_STRING_STREAM_OPERATORS to compile the stream operators into the library: ===

#define ENABLE_BYTESTRING_STREAM_OPERATORS
+#define ENABLE_STRING_STREAM_OPERATORS
#include <stream.hxx>

Simple change to ensure that the deprecated stream functions are still compiled into the library. The proper long term fix is to change the call sites and remove the requirement altogether.

User:Cloph

2006-02-03T02:52:24Z

Vq: /* Summary */

= Tinderbox =
Collecting things that could be improved....

== Timezone ==
Tinderbox should not use "local" time by default to display the results, but UTC instead. People are more familiar with mapping their local time to UTC than to mess with another "local" time..

== Indication whether the buildstatus is still valid ==
Currently, there is no automated way to check whether the result of a build still is valid. There could have been changes to the cws in the meantime (less likely for the milestones, but very likely if you build the cwsses). Even a ready-for-qa cws can be set to new again and have some files changed in the meantime.
So it would be great if tinderbox would be able to automatically
* notify the tinder-admin of the buildhost (via e-mail)
* highlight the status-column accordingly - either with a questionmark or using some color
* optionally provide a different tag-list with the additional info "unchanged since last build"

== False positives: errors ==
=== Summary ===
Things that are added to the ignore-list of tinderbox's Error_Parse.pm:

($line =~ m/^checking exception type/) ||
($line =~ m/^checking for a sed that does not truncate output/) ||
($line =~ m/exception\.(hpp|htm|html|cpp)/) ||
($line =~ m/deprecated-list\.html/) ||
($line =~ m#/(stlport|inc/stl)/exception#) ||
($line =~ m/^idlc: compile ´Exception.idl´/) ||
($line =~ m#com/sun/star/uno/Exception\.(idl|hdl|hpp)#) ||
($line =~ m#slo/Exception.o#) ||
($line =~ m#inc/cppunit/Exception.h#) ||

=== Details ===
* checking exception type... dwarf2
* checking for a sed that does not truncate output... /bin/sed
($line =~ m/^checking exception type/) ||
($line =~ m/^checking for a sed that does not truncate output/) ||

* boost-1.30.2/boost/filesystem/exception.hpp
* boost-1.30.2/boost/graph/exception.hpp
* boost-1.30.2/boost/numeric/ublas/exception.hpp
* boost-1.30.2/libs/filesystem/doc/exception.htm
* boost-1.30.2/libs/filesystem/src/exception.cpp
* boost-1.30.2/libs/graph/doc/exception.html

($line =~ m/exception\.(hpp|htm|html|cpp)/) ||

* inflating: hsqldb/doc/src/deprecated-list.html
* rhino1_5R4/docs/apidocs/deprecated-list.html
* db-4.2.52.NC/docs/java/deprecated-list.html

($line =~ m/deprecated-list\.html/) ||

* STLport-4.5/stlport/exception
* STLport-4.5/stlport/exception.h
* COPY: ../unxlngi4.pro/inc/stlport/exception -> /home/cl/programming/shadow/solver/680/unxlngi4.pro/inc/stl/exception
* COPY: ../unxlngi4.pro/inc/stlport/exception.h -> /home/cl/programming/shadow/solver/680/unxlngi4.pro/inc/stl/exception.h
* tr -d "\015" < /home/cl/programming/shadow/solver/680/unxlngi4.pro/inc/stl/exception > ../../unxlngi4.pro/bin/odkcommon/include/stl/exception
* tr -d "\015" < /home/cl/programming/shadow/solver/680/unxlngi4.pro/inc/stl/exception.h > ../../unxlngi4.pro/bin/odkcommon/include/stl/exception.h

($line =~ m#/(stlport|inc/stl)/exception#) ||

* idlc: compile ´Exception.idl´ ...

($line =~ m/^idlc: compile ´Exception.idl´/) ||

* COPY: ../com/sun/star/uno/Exception.idl -> /home/cl/programming/shadow/solver/680/unxlngi4.pro/idl/com/sun/star/uno/Exception.idl
* COPY: ../unxlngi4.pro/inc/com/sun/star/uno/Exception.hdl -> /home/cl/programming/shadow/solver/680/unxlngi4.pro/inc/com/sun/star/uno/Exception.hdl
* COPY: ../unxlngi4.pro/inc/com/sun/star/uno/Exception.hpp -> /home/cl/programming/shadow/solver/680/unxlngi4.pro/inc/com/sun/star/uno/Exception.hpp
* adding: com/sun/star/uno/Exception.class (deflated 43%)
* tr -d "\015" < /home/cl/programming/shadow/solver/680/unxlngi4.pro/idl/com/sun/star/uno/Exception.idl > ../../unxlngi4.pro/bin/odkcommon/idl/com/sun/star/uno/Exception.idl
* ./../../unxlngi4.pro/bin/odkidl/idl/com/sun/star/uno/Exception.idl ...

($line =~ m#com/sun/star/uno/Exception\.(idl|hdl|hpp)#) ||

* Making: ../../unxlngi4.pro/slo/Exception.obj
* g++ -Wuninitialized -fmessage-length=0 -c -I. -I. -I../inc -I../../inc -I../../unx/inc -I../../unxlngi4.pro/inc -I. -I/home/cl/programming/shadow/solver/680/unxlngi4.pro/inc/stl -I/home/cl/programming/shadow/solver/680/unxlngi4.pro/inc/external -I/home/cl/programming/shadow/solver/680/unxlngi4.pro/inc -I/home/cl/programming/shadow/solenv/unxlngi4/inc -I/home/cl/programming/shadow/solenv/inc -I/home/cl/programming/shadow/res -I/home/cl/programming/shadow/solver/680/unxlngi4.pro/inc/stl -I/home/cl/programming/shadow/solenv/inc/Xp31 -I/usr/java/j2sdk1.4.1_02/include -I/usr/java/j2sdk1.4.1_02/include/linux -I/usr/java/j2sdk1.4.1_02/include/native_threads/include -I/usr/X11R6/include -I. -I../../res -I. -O1 -pipe -mcpu=pentiumpro -Wno-ctor-dtor-privacy -include preinclude.h -fexceptions -fno-enforce-eh-specs -fpic -DLINUX -DUNX -DVCL -DGCC -DC300 -DINTEL -DCVER=C300 -D_USE_NAMESPACE -DGLIBC=2 -DX86 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/include/c++/3.2.3 -DSUPD=680 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DEXCEPTIONS_ON -DCUI -DSOLAR_JAVA -DSRC680=SRC680 -DSHAREDLIB -D_DLL_ -DMULTITHREAD -o ../../unxlngi4.pro/slo/Exception.o /home/cl/programming/shadow/testshl2/source/cppunit/Exception.cpp
* if ( -e ../../unxlngi4.pro/slo/Exception.o) touch ../../unxlngi4.pro/slo/Exception.obj
* ar -r ../../unxlngi4.pro/lib/libcppunitli.a ../../unxlngi4.pro/slo/SourceLine.o ../../unxlngi4.pro/slo/Exception.o ../../unxlngi4.pro/slo/NotEqualException.o ../../unxlngi4.pro/slo/TestFailure.o ../../unxlngi4.pro/slo/joblist.o ../../unxlngi4.pro/slo/t_print.o ../../unxlngi4.pro/slo/signaltest.o ../../unxlngi4.pro/slo/Asserter.o ../../unxlngi4.pro/slo/TestCase.o ../../unxlngi4.pro/slo/TestSuite.o ../../unxlngi4.pro/slo/TestAssert.o ../../unxlngi4.pro/slo/TestFactoryRegistry.o ../../unxlngi4.pro/slo/cmdlinebits.o ../../unxlngi4.pro/slo/t_print.o ../../unxlngi4.pro/slo/tresregister.o ../../unxlngi4.pro/slo/tresstatewrapper.o ../../unxlngi4.pro/slo/registertestfunction.o
* ../unxlngi4.pro/slo/Exception.o \
* Making: ../../../unxlngi4.pro/slo/Exception.obj
* g++ -Wuninitialized -fmessage-length=0 -c -I. -I. -I../inc -I../../inc -I../../../inc -I../../../unx/inc -I../../../unxlngi4.pro/inc -I. -I/home/cl/programming/shadow/solver/680/unxlngi4.pro/inc/stl -I/home/cl/programming/shadow/solver/680/unxlngi4.pro/inc/external -I/home/cl/programming/shadow/solver/680/unxlngi4.pro/inc -I/home/cl/programming/shadow/solenv/unxlngi4/inc -I/home/cl/programming/shadow/solenv/inc -I/home/cl/programming/shadow/res -I/home/cl/programming/shadow/solver/680/unxlngi4.pro/inc/stl -I/home/cl/programming/shadow/solenv/inc/Xp31 -I/usr/java/j2sdk1.4.1_02/include -I/usr/java/j2sdk1.4.1_02/include/linux -I/usr/java/j2sdk1.4.1_02/include/native_threads/include -I/usr/X11R6/include -I. -I../../../res -I. -O1 -pipe -mcpu=pentiumpro -Wno-ctor-dtor-privacy -include preinclude.h -fexceptions -fno-enforce-eh-specs -fpic -DLINUX -DUNX -DVCL -DGCC -DC300 -DINTEL -DCVER=C300 -D_USE_NAMESPACE -DGLIBC=2 -DX86 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/include/c++/3.2.3 -DSUPD=680 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DEXCEPTIONS_ON -DCUI -DSOLAR_JAVA -DSRC680=SRC680 -DSHAREDLIB -D_DLL_ -DMULTITHREAD -o ../../../unxlngi4.pro/slo/Exception.o
* if ( -e ../../../unxlngi4.pro/slo/Exception.o) touch ../../../unxlngi4.pro/slo/Exception.obj
* echo unxlngi4.pro/slo/Array.o unxlngi4.pro/slo/Blob.o unxlngi4.pro/slo/Boolean.o unxlngi4.pro/slo/CallableStatement.o unxlngi4.pro/slo/Class.o unxlngi4.pro/slo/Clob.o unxlngi4.pro/slo/Connection.o unxlngi4.pro/slo/DatabaseMetaData.o unxlngi4.pro/slo/Date.o unxlngi4.pro/slo/DriverManager.o unxlngi4.pro/slo/DriverPropertyInfo.o unxlngi4.pro/slo/Exception.o unxlngi4.pro/slo/InputStream.o unxlngi4.pro/slo/JDriver.o unxlngi4.pro/slo/Object.o unxlngi4.pro/slo/PreparedStatement.o unxlngi4.pro/slo/Reader.o unxlngi4.pro/slo/Ref.o unxlngi4.pro/slo/ResultSet.o unxlngi4.pro/slo/ResultSetMetaData.o unxlngi4.pro/slo/SQLException.o unxlngi4.pro/slo/SQLWarning.o unxlngi4.pro/slo/Statement.o unxlngi4.pro/slo/String.o unxlngi4.pro/slo/Throwable.o unxlngi4.pro/slo/Timestamp.o unxlngi4.pro/slo/jservices.o unxlngi4.pro/slo/tools.o | xargs -n1 > ../../../unxlngi4.pro/slb/jdbc.lib

* gcc -z combreloc -z defs -Wl,-rpath,´$ORIGIN´ -shared -Wl,-O1 -Wl,--version-script ../../../unxlngi4.pro/misc/jdbc_jdbc2.map -L../../../unxlngi4.pro/lib -L../lib -L/home/cl/programming/shadow/solenv/unxlngi4/lib -L/home/cl/programming/shadow/solver/680/unxlngi4.pro/lib -L/home/cl/programming/shadow/solenv/unxlngi4/lib -L/usr/java/j2sdk1.4.1_02/lib -L/usr/java/j2sdk1.4.1_02/jre/lib/i386 -L/usr/java/j2sdk1.4.1_02/jre/lib/i386/client -L/usr/java/j2sdk1.4.1_02/jre/lib/i386/native_threads -L/usr/X11R6/lib ../../../unxlngi4.pro/slo/Array.o ../../../unxlngi4.pro/slo/Blob.o ../../../unxlngi4.pro/slo/Boolean.o ../../../unxlngi4.pro/slo/CallableStatement.o ../../../unxlngi4.pro/slo/Class.o ../../../unxlngi4.pro/slo/Clob.o ../../../unxlngi4.pro/slo/Connection.o ../../../unxlngi4.pro/slo/DatabaseMetaData.o ../../../unxlngi4.pro/slo/Date.o ../../../unxlngi4.pro/slo/DriverManager.o ../../../unxlngi4.pro/slo/DriverPropertyInfo.o ../../../unxlngi4.pro/slo/Exception.o ../../../unxlngi4.pro/slo/InputStream.o ../../../unxlngi4.pro/slo/JDriver.o ../../../unxlngi4.pro/slo/Object.o ../../../unxlngi4.pro/slo/PreparedStatement.o ../../../unxlngi4.pro/slo/Reader.o ../../../unxlngi4.pro/slo/Ref.o ../../../unxlngi4.pro/slo/ResultSet.o ../../../unxlngi4.pro/slo/ResultSetMetaData.o ../../../unxlngi4.pro/slo/SQLException.o ../../../unxlngi4.pro/slo/SQLWarning.o ../../../unxlngi4.pro/slo/Statement.o ../../../unxlngi4.pro/slo/String.o ../../../unxlngi4.pro/slo/Throwable.o ../../../unxlngi4.pro/slo/Timestamp.o ../../../unxlngi4.pro/slo/jservices.o ../../../unxlngi4.pro/slo/tools.o ../../../unxlngi4.pro/slo/jdbc2_version.o ../../../unxlngi4.pro/slo/jdbc2_description.o -o ../../../unxlngi4.pro/lib/libjdbc2.so -luno_cppu -luno_cppuhelpergcc3 -lvos3gcc3 -luno_sal -ljvmaccessgcc3 -ldbtools680li -ljvmfwk -lcomphelp4gcc3 -ldl -lpthread -lm -Wl,-Bdynamic -lstlport_gcc -lstdc++

($line =~ m#slo/Exception.o#) ||

* COPY: ../inc/cppunit/Exception.h -> /home/cl/programming/shadow/solver/680/unxlngi4.pro/inc/cppunit/Exception.h
/home/cl/programming/shadow/connectivity/source/drivers/jdbc/Exception.cxx

($line =~ m#inc/cppunit/Exception.h#) ||

2005-12-31T00:05:57Z

Vq:

Tinderbox Setup

2005-12-23T04:39:33Z

Vq:

Disclaimer! I tried the tinderbox sripts that are described on this page only with W32-tcsh so far. They are to be considered of beta quality only. Patches are very much appreciated.

= What is tinderbox =

In essence tinderbox is a perl script that processes mail, and turns it into HTML. It expects to be mailed build logs from separate and de-coupled build machines. Tinderbox has a few elaborations over the most simple 'status' web-page, inasmuch that it integrates with bonsai - to correlate builds against commits, and it has some nice built in error-parsers to allow huge build logs to be condensed to just a few (possible) tricky sections.

= Setting up a build slave =
To do this, you need to be able to build OO.o already; if you can't do this start here: [[Building]].

The framework that is described in the following sections can be used to build "new" and "Ready-for-QA" CWSs and MWSs of the 680er codeline. See [http://www.go-oo.org/tinderbox/ this] webpage for a list of the currently accepted tags. You will find the build logs (providing there are any) when you click on the corresponding tag.

== Requirements ==

[http://go-ooo.org/tinder-scripts/ This] directory contains a mininimal framework to build OOo CWSs and MWSs
and sent the reports to the tinderbox at go-oo.org.

You need to get the following files from that directory:
tin-main.pl
tinprep.sh
tinbuild.sh
tinget.pl
tinsend.pm

In addition to these files you need to install the Sender.pm Perl module from CPAN. See the CPAN link <http://go-ooo.org/cpan.html> for details about getting this module.

== Configuration ==
A few files have to be adapted to match your local setup. Changes only have to be done in areas marked with:
"# -- End of Things to tweak --"

<ul>
<li>tin-main.pl These variables need to be adapted (Follow the example in the source):<pre>
$tinsend::FROMADDRESS
$tinsend::SMTPAUTH
$tinsend::SMTPSERVER
$tinsend::SMTPAUTHID
$tinsend::SMTPAUTHPW
</pre>
</li>
<li>tinbuild.sh Set the options to configure your OOo build.
</li>

<li>tinprep.sh OOo needs some things prepared before it can be build. Things like that go into this file.
</li>
</ul>

== Start the tinderbox build ==
The build is then started with:

./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

The first parameter sets the name the build identifies itself, the second gives the target directory the source is build in, the third sets which CWS/MWS is used, the fourth how the source is obtained/treated (checked out from cvs in this case) and the last one says that the buildlog is send to the tinderbox. The parameters are discussed in detail later in this document.

= Documentation =

The following part describes the used scripts and useful parameters. (The markup needs a brush-up.)

<pre>
tin-main.pl
Syntax (all five parameters are needed):
tin-main.pl buildstring src_path ws {co|up|cont|clean} {send|nosend}
buildstring - Name that will appear in the tinderbox
src_path - Pointing to source to be used
ws - Which workspace shall be build. It accepts CWSs names (from the
list in <http://go-oo.org/tinderbox/tags/tag-list>) or all MWSs
starting with ???680_m*.
co|up|cont|clean - Tells the script what to do with src_path. Fresh checkout,
update a current repo (this also deletes modified/extra files),
do nothing, just start/continue with current repo, and clean
removes all wntmsci10.pro before rebuilding.
send|nosend - send the logfile to the tinderbox (or not)

The main program that starts the build, captures the logfile and sends it to
the tinderbox.

Example: ./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

tinsend.pl
This module handles sending of mails with attachments. This was necessary
because the windows build logs are easily 30MB or more and in our early
setups this was just to much to be handled by some SMTP servers and also
for go-oo.org. See some documentation inline in that file.

tinget.pl
Syntax (all four parameters are needed):
tinget.pl ws buildlog src_path {co|up|cont|clean}
ws - See tinder-main.pl.
buildlog - logfile name (this is send to the tinderbox)
src_path - See tinder-main.pl.
{co|up|cont|clean} - See tinder-main.pl.

This script does the orkspace (src_path) handling.

tinbuild.sh
Syntax:
tinbuild.sh ws buildsys buildlog src_path
Parameter see tinder-main.pl, buildsys includes {cyg|4nt} but can also
handle several special cases.

The actual build script that starts the build and captures the logfile.

tinprep.sh
Syntax:
tinprep.sh src_path

Prepare the workspace for the build
</pre>

Tinderbox Setup

2005-12-23T04:27:40Z

Vq:

= What is tinderbox =

In essence tinderbox is a perl script that processes mail, and turns it into HTML. It expects to be mailed build logs from separate and de-coupled build machines. Tinderbox has a few elaborations over the most simple 'status' web-page, inasmuch that it integrates with bonsai - to correlate builds against commits, and it has some nice built in error-parsers to allow huge build logs to be condensed to just a few (possible) tricky sections.

= Setting up a build slave =
To do this, you need to be able to build OO.o already; if you can't do this start here: [[Building]].

== Requirements ==

[http://go-ooo.org/tinder-scripts/ This] directory contains a mininimal framework to build OOo CWSs and MWSs
and sent the reports to the tinderbox at go-oo.org.

You need to get the following files from that directory:
tin-main.pl
tinprep.sh
tinbuild.sh
tinget.pl
tinsend.pm

In addition to these files you need to install the Sender.pm Perl module from CPAN. See the CPAN link <http://go-ooo.org/cpan.html> for details about getting this module.

== Configuration ==
A few files have to be adapted to match your local setup. Changes only have to be done in areas marked with:
"# -- End of Things to tweak --"

<ul>
<li>tin-main.pl These variables need to be adapted (Follow the example in the source):<pre>
$tinsend::FROMADDRESS
$tinsend::SMTPAUTH
$tinsend::SMTPSERVER
$tinsend::SMTPAUTHID
$tinsend::SMTPAUTHPW
</pre>
</li>
<li>tinbuild.sh Set the options to configure your OOo build.
</li>

<li>tinprep.sh OOo needs some things prepared before it can be build. Things like that go into this file.
</li>
</ul>

== Start the tinderbox build ==
The build is then started with:

./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

The first parameter sets the name the build identifies itself, the second gives the target directory the source is build in, the third sets which CWS/MWS is used, the fourth how the source is obtained/treated (checked out from cvs in this case) and the last one says that the buildlog is send to the tinderbox. The parameters are discussed in detail later in this document.

= Documentation =

The following part describes the used scripts and useful parameters. (The markup needs a brush-up.)

<pre>
tin-main.pl
Syntax (all five parameters are needed):
tin-main.pl buildstring src_path ws {co|up|cont|clean} {send|nosend}
buildstring - Name that will appear in the tinderbox
src_path - Pointing to source to be used
ws - Which workspace shall be build. It accepts CWSs names (from the
list in <http://go-oo.org/tinderbox/tags/tag-list>) or all MWSs
starting with ???680_m*.
co|up|cont|clean - Tells the script what to do with src_path. Fresh checkout,
update a current repo (this also deletes modified/extra files),
do nothing, just start/continue with current repo, and clean
removes all wntmsci10.pro before rebuilding.
send|nosend - send the logfile to the tinderbox (or not)

The main program that starts the build, captures the logfile and sends it to
the tinderbox.

Example: ./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

tinsend.pl
This module handles sending of mails with attachments. This was necessary
because the windows build logs are easily 30MB or more and in our early
setups this was just to much to be handled by some SMTP servers and also
for go-oo.org. See some documentation inline in that file.

tinget.pl
Syntax (all four parameters are needed):
tinget.pl ws buildlog src_path {co|up|cont|clean}
ws - See tinder-main.pl.
buildlog - logfile name (this is send to the tinderbox)
src_path - See tinder-main.pl.
{co|up|cont|clean} - See tinder-main.pl.

This script does the orkspace (src_path) handling.

tinbuild.sh
Syntax:
tinbuild.sh ws buildsys buildlog src_path
Parameter see tinder-main.pl, buildsys includes {cyg|4nt} but can also
handle several special cases.

The actual build script that starts the build and captures the logfile.

tinprep.sh
Syntax:
tinprep.sh src_path

Prepare the workspace for the build
</pre>

Debug Build Problems

2005-12-16T17:33:58Z

Vq: Useful hints to help debug a build problem

OOo can be build on several different operating systems with various configurations. Therefore it is sometimes hard to locate the actual problem when build problems arise. This page provides some guidelines which information might be necessary to solve the problem.

* Always build from a clean sources Independent from using cvs or unpacking a source archive from the download page. Whenever you changing the version (e.g. a different snapshot, Release Candidate or Release version) always remove the old sources and the solver directory completely and unpack/checkout the new version. (There might be files leftover in the source archive from the previous version that a “cvs up” or unpacking of the new source version will not remove.)

* Always use “dmake >& mybuild.log” or “build >& mybuild.log” This captures the build log and also warnings that might lead to the error. After you found a build problem do not only enter that directory and enter “build” again. This will not rebuild the whole module, and therefore you won't get a complete logfile, only the last failing command. If you want to produce a useful log first remove the object file directory (usually wntmsci10.pro, unxlngi6.pro or so.) and then enter “build” again. When submitting a bug report attach the logfile to the issue.

* Provide all switches you used to configure your build environment It is very helpful to show the command line switches you used to configure your build environment. These can be found retroactively in the first lines of "config_office/config.log". When submitting a bug report attach this file to the issue.

* Provide the build environment script All environment variables that are used by the OOo build process are set by a script (e.g. winenv.set or unxenv.set). When submitting a bug report please attach this file to the issue.

Building with ooobuild

2005-12-16T17:06:17Z

Vq:

== Vanilla Up-stream builds ==

See the [http://tools.openoffice.org#Build tools] project for build guides for various platforms.

Also for OS/X see [[MacOSXBuildInstructions]]

== ooo-build builds ==

<center>
'''If you are looking for additional building tips for Windows check [[Windows |this]] page first.'''
</center>
----
 

=== configure ===


The build process is pretty complicated; you have a choice
of commands now; although running both won't actually hurt:

./autogen.sh # only for the CVS version
./configure # the packaged version


This will guess which branch snapshot you want to build; if
you have other ideas use the --with-tag option; eg.
<code>--with-tag=src680-m65</code> for a legacy branch.


If for some reason you have a 31337 multi-threaded computer,
with great slabs of RAM; you'll want to use --with-num-cpus=8
etc. NB. it's not clever to force the build to swap like a
demented pawnbroker by using an artificially high number; C++
compilation is seriously memory hungry.


In particular, building SRC680 requires a recent jdk & a
version of apache-ant. If you use a Novell system, just do:
<code>sudo rug in apache-ant</code>, alternatively download
a package from [http://www.rpmfind.net/linux/rpm2html/search.php?query=apache-ant&submit=Search+..." rpmfind.net] or failing that see [http://ant.apache.org/bindownload.cgi Ant download]
& set the ANT environment variable
appropriately before configuring.


=== Requirements ===

If you don't have a working Java VM (i.e. any runtime), you should pass <code>--with-java=no</code> to either <code>autogen.sh</code> or <code>configure</code>.

You need the Archive/Zip module for Perl. (perl-Archive-Zip on RPM-based distributions, libarchive-zip-perl on dpkg-based distributions)

You need the development package for Python (this would be python-devel on RPM-based distributions).

You need curl and curl-devel.

You need odbc_config to be present. On SUSE systems, this is in the unixODBC-devel package.

You need libsndfile and libsndfile-devel.

If you don't have a recent enough openldap, pass <code>--disable-openldap</code> to <code>autogen.sh</code> or <code>configure</code>.

You need neon and neon-devel.

You need qt3 and qt3-devel, or if you don't have the KDE development packages, pass <code>--disable-kde</code> to <code>autogen.sh</code> or <code>configure</code>.

You need mozilla-nss-devel.

=== download ===


By the time you've upgraded your system to the point that it
has all the packages you need to start building OO.o (mozilla etc. etc.) you're almost at the point that you
can download the bulk of the source. To do this, after a
successful configure simply type: <code>./download</code> and wait.


If for whatever reason this fails, you can verify your download
by fetching the equivalent .md5 file & comparing it to
the result of <code>md5sum <archive></code>. The source
archives are http://go-ooo.org/packages/SRC680
- put the source in ooo-build/src.


=== make ===


This is the taxing bit - type <code>make</code> and don't forget
to press enter. Quite possibly you want to log the output, so
why not <code>make 2>&1 | tee /tmp/log</code>.


Since ooo-build wraps the actual OO.o configuration &
build process, there are a number of internal config checks that
also need to pass. For a first time build it's well worth staying
near the console while everything unpacks, and the internal
configure runs; if that completes without incident - you're
usually into the heavy-duty thumb twiddling.


== See also ==

*[[Installing]]