ReleaseStatus Minutes 2009-02-09 IRC log

From Apache OpenOffice Wiki
Revision as of 15:12, 9 February 2009 by JoostAndrae (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

(14:58:37) kai_a [n=Kai_Ahre@i577AA07B.versanet.de] hat den Raum betreten.
(14:58:42) ja_: Hi all
(15:00:29) volkerme [n=chatzill@77-21-35-10-dynip.superkabel.de] hat den Raum betreten.
(15:00:48) UweL [n=chatzill@nat/sun/x-1359bb9b38782ec6] hat den Raum betreten.
(15:01:48) _Nesshof_: moin
(15:01:56) blauwal [n=jr93709@sd-socks-197.staroffice.de] hat den Raum betreten.
(15:01:57) stefan_b: Moin!
(15:02:40) _Nesshof_: lets start with 3.1 release status
(15:03:00) _Nesshof_: blauwal: do you know the status of m1 ?
(15:03:55) blauwal: _Nesshof_: still "in progress"
(15:04:07) _Nesshof_: nomination and integration of cws is nowadays a bit slow
(15:04:41) _Nesshof_: svn diff and merge operation are much more slower than expected
(15:05:00) _Nesshof_: so not all nominated cws got into m1
(15:05:54) FrankS: bug build for m1 is already ongoing?
(15:06:03) _Nesshof_: for cws dv07 I discovered some new strings, that string already got translated in the database, so that an export into pootle will not result in new strings
(15:06:24) FrankS: -g+t
(15:07:34) FrankS: I'm asking 'cause
(15:07:47) _Nesshof_: FrankS: see blauwals statement above
(15:07:52) FrankS: the deadline for exceptional fixes" is this week
(15:08:05) FrankS: this doesn't answer the question
(15:08:14) FrankS: will m1 be built with the currently integrated CWSes only?
(15:08:21) _Nesshof_: FrankS: blauwal should know the answer
(15:08:25) FrankS: or will the remaining nominated CWSes be integrated before building?
(15:08:47) _rene_: 14:34 < _Nesshof_> so it will get into m2 (hopefully)
(15:08:51) _Nesshof_: remaining nominated cws will go into m2
(15:08:55) _rene_: so: no :)
(15:09:02) FrankS: The fact that two of our (Bases) major CWSes (dba31h abd dba31g) are not yet integrated doesn't really fit to the "deadline for exceptional fixes"
(15:09:21) FrankS: How are we expected to find exceptional problems when we won't even have a build in time?
(15:09:28) FrankS: That's ... weird
(15:09:41) _rene_: FrankS: dba31g is in m1.
(15:10:00) FrankS: EIS shows "nominated"
(15:10:06) FrankS: either EIS or you is wrong :)
(15:10:14) _rene_: then look at the clone for OOO310...
(15:10:25) _rene_: or just EIS' overview for m1 :)
(15:10:28) FrankS: argh
(15:10:30) ***FrankS is wrong
(15:10:35) FrankS: sorry
(15:10:38) blauwal: FrankS: see :-)
(15:11:00) FrankS: okay, this leaves me with dba31h, and the same question
(15:11:16) FrankS: how does a build which does not even contain all CWSes fit to the "deadline for exceptional fixes" being in three days?
(15:11:32) FrankS: do we assume all those CWSes don't introduce any problems?
(15:11:41) rtimm [n=Ruediger@nat/sun/x-35838fba878e85e7] hat den Raum betreten.
(15:12:13) _rene_: FrankS: we have the same issue with rptfix04. which is a blocker but it#s jfgreereport module is so hosed up......
(15:12:15) _Nesshof_: FrankS: lol
(15:12:48) FrankS: _rene_: I'd like to separate this topic, and clarify the more fundamental problem first, please
(15:13:04) _Nesshof_: FrankS: for the exceptional fixes feadline I will take the date of approval
(15:13:18) FrankS: _Nesshof_: so what?
(15:13:24) _rene_: _Nesshof_: that still is in 3 days
(15:13:25) FrankS: If the CWSes introduce problems, they're not yet known
(15:13:34) FrankS: so the CWSes with their fixes are not yet approved
(15:13:47) _rene_: _Nesshof_: fs has a point. you can't know then before people have m2 in their hands
(15:13:54) _rene_: which is when? next week?
(15:13:59) FrankS: m2 won't be finished before next week, so any problem-fixes won't be approved in three days
(15:14:06) _rene_: *nods*
(15:14:13) blauwal: _rene_: hopefully end of this week
(15:14:28) _Nesshof_: FrankS: _rene_ then we are in stopper mode
(15:14:49) FrankS: what's the difference between a stopper fix and an "exceptional code fix"?
(15:14:57) _Nesshof_: I assume if a cws causes problem that then it will become a stopper
(15:15:05) FrankS: "assume"?
(15:15:12) blauwal: FrankS: Stopper need to be agreed upon
(15:15:17) blauwal: FrankS: in this meeting
(15:15:26) _Nesshof_: blauwal is right
(15:15:49) _Nesshof_: exceptional code freeze tries to limit the amount of cws
(15:16:02) _Nesshof_: but not every contained issue is a stopper
(15:16:10) FrankS: I see
(15:16:16) FrankS: which is sad
(15:16:40) FrankS: because that leaves us with CWSes *ready before code freeze* being available to the public only 2 weeks before last CWS integration
(15:16:47) FrankS: which is unfortunate, to say at least
(15:17:43) FrankS: but be it, we probably do not want discuss moving the release date, do we?
(15:17:57) blauwal: FrankS: I think this is unavoidable in a train model with quarterly releases
(15:18:03) SunNF_ [n=Nils@wlan-sun.staroffice.de] hat den Raum betreten.
(15:18:03) FrankS: so, just for the record: The timing for this release is very ... unfortunate
(15:18:11) FrankS: hmm
(15:18:27) _Nesshof_: FrankS: noted
(15:18:41) FrankS: the conclusion is that releasing versions with potentially a lot of known bugs is "unavoidable" - I don't like this term, really :)
(15:18:50) FrankS: be it. period.
(15:19:17) _rene_: FrankS: no news :/
(15:19:23) _Nesshof_: does dba31h stopper issues
(15:19:25) _Nesshof_: ?
(15:19:32) _Nesshof_: ;-)
(15:19:36) _rene_: yes :)
(15:19:38) FrankS: If I knew, I wouldn't tell you :)
(15:19:53) blauwal: FrankS: see ._9
(15:20:00) FrankS: alone the fact that due to QA resource problems, we had two parallel CWSes, is a potential problem
(15:20:21) FrankS: but that's a different topic
(15:20:32) _rene_: that's not a problem of the release team or showver, that's a problem of the QA :)
(15:20:42) _rene_: s/showver/whoever/
(15:20:57) _rene_: .oO ( how did I manage to typo i that way? sigh )
(15:22:21) _Nesshof_: localization35 also will get a bit delayed
(15:22:42) _Nesshof_: we are waiting for localization of arabic UI a little bit
(15:23:05) _rene_: will it get into m2?
(15:23:17) _rene_: or m3?
(15:23:17) _Nesshof_: blauwal: rtimm: do you have a more detailed status for localization ?
(15:23:58) blauwal: _Nesshof_: moment, please
(15:24:19) _Nesshof_: due date in EIS still is Feb. 9, is this still valid ?
(15:24:33) blauwal: _Nesshof_: we are still waiting for strings ... we hope to start with it tomorrow
(15:24:52) blauwal: _Nesshof_: additionally there is now one language with a three letter ISO code
(15:24:55) _Nesshof_: ja_: have you got feedback for latest arabic snapshot ?
(15:25:20) blauwal: _Nesshof_: thus will break at least in two places
(15:25:24) _Nesshof_: blauwal: which language, do we expect trouble with this ?
(15:25:44) ja_: _Nesshof_: I got just one comment within my blog but ot was nothing new
(15:25:56) blauwal: _Nesshof_: it's one language from India ... which one exactly I can't rememmber just now.
(15:26:07) blauwal: s/rememmber/remember/
(15:26:39) _Nesshof_: blauwal: do we already have fixes for those breakages ?
(15:27:00) _Nesshof_: otherwise I would recommend to postpone that language
(15:27:04) blauwal: _Nesshof_: not yet, Vladimir is contemplating a workaround
(15:28:30) _Nesshof_: blauwal: once arabic translation for arabic has arrived we should start with loc%35, and leave that Indian language out if that does not build
(15:29:14) _Nesshof_: _rene_:status of rptfix04 ?
(15:29:24) sophi: _Nesshof_: I think it's papiamento
(15:30:14) FrankS: _Nesshof_: an answer from either you or _rene_ to Ocke's last mail about rptfix04 would answer your question :)
(15:30:17) blauwal: _Nesshof_: it's Dogri (dgo)
(15:30:25) blauwal: _Nesshof_: two other will follow
(15:30:40) FrankS: Ocke asked whether it would address your concerns if Pentaho made the SVN snapshot publicly available for download
(15:30:42) _rene_: FrankS: no.
(15:30:59) _rene_: FrankS: it does not help. take pristine sources and add a patch
(15:31:04) _rene_: like any other external module
(15:31:22) FrankS: Okay, let's talk about moving the release date, then
(15:31:29) FrankS: but beforehand: please elaborate your "no"
(15:31:33) FrankS: "no" is too simple to accept
(15:31:34) _Nesshof_: FrankS: we should stay with our established processes
(15:31:44) FrankS: yes
(15:31:46) _rene_: well, it's not my problem if you did crap from the start and then don't have time to clean up your mess
(15:32:15) _rene_: as _Nesshof_ said, the correct and established way is NOT to just create own zips of whatever and put it into download
(15:32:16) FrankS: sigh
(15:32:22) FrankS: yes
(15:32:25) FrankS: this was a failure
(15:32:28) _rene_: but to take upstreams tarballs and patch them if needed
(15:32:33) _rene_: so fix it.
(15:32:56) _Nesshof_: FrankS: is there any need for rptfix04 for the 3.1 release ?
(15:32:58) FrankS: What Ocke proposed and asked, but what nobody of you took time to answer (this way letting a few more days pass by)
(15:33:00) _rene_: should be easy for oj to dp
(15:33:03) _rene_: do
(15:33:08) FrankS: is how we could match the definition of "upstream" here
(15:33:23) FrankS: I am not sure if that's easy
(15:33:37) FrankS: as you yourself wrote, so you should know, there are *a lot* of changes
(15:33:44) FrankS: so it might not be that easy
(15:33:46) _rene_: upstream = pentahos tar.gz/.zip from sf.net/jfreereport
(15:33:47) FrankS: that's why Ocke's question
(15:33:51) _rene_: not my problem, to be honest
(15:33:57) FrankS: now read Ocke's mail, again
(15:34:11) FrankS: If the branch we would use were put online there: would that be "upstream"
(15:34:15) FrankS: by my definition: yes
(15:34:15) _rene_: you added the changes, not me. you broke --with-system-jfreereport
(15:34:59) FrankS: let's not count who broke what - not sure who would win :)
(15:35:07) _rene_: FrankS: by mine not. how do you get a mapping between pristine upstream dnd that branch? how do you get a mapping OOo<->branch?
(15:35:29) _rene_: FrankS: how do you repair --with-system-jfreereport to look whether it's the correct branch?
(15:35:50) _rene_: FrankS: and should I really package all the libs two times? One time vanilla, one time the branch? :)
(15:35:57) FrankS: by naming the release "jfreereport-whatever-x.y.z" and adjusting configure? Come on.
(15:36:08) _rene_: FrankS: for that, I need a diff on top of the vanilla ones.
(15:36:48) FrankS: for my understanding: --with-system-jfreereport takes the jfreereport installed in the system, and patches it?
(15:36:55) FrankS: right or wrong?
(15:36:57) _rene_: no
(15:36:59) FrankS: but?
(15:37:00) _rene_: it takes the jars.
(15:37:07) _rene_: and "links" with them
(15:37:13) FrankS: so they're unpatched
(15:37:13) FrankS: ?
(15:37:14) _rene_: (Class-Path: to them)
(15:37:18) _rene_: yes
(15:37:30) _rene_: unless you provide patched ones
(15:37:30) FrankS: Then what would it actually *change* if we had pristine+patch?
(15:37:44) FrankS: You would still use the pristing/unpatched ones
(15:37:46) _rene_: that one sees what you need to do to make it work with OOo
(15:37:56) _rene_: FrankS: the pristine ones do not work at all right now
(15:38:18) FrankS: yes, and this will continue to be, even with the change you request
(15:38:19) _rene_: FrankS: if you actually read the mail I wrote. liblayout does not build with all the newer pristine ones
(15:38:38) _rene_: FrankS: yes, but then you see what's patched. And either take the changes over or leave it. has to leave now
(16:05:42) blauwal: _Nesshof_: Kurt (kz) will finish m1
(16:05:45) _rene_: _Nesshof_: I want that on the ESC on 03.09. please.
(16:05:49) rtimm: Kurt currently is doing m1
(16:05:55) blauwal: _Nesshof_: Ivo (ihi) is in for m2
(16:05:58) ***ja_ just wrote one short paragraph about this discussion
(16:06:11) _rene_: _Nesshof_: that such broken things will not happen again. non-pristine sources (- non-free stuff) -> reject
(16:06:11) _Nesshof_: _rene_: np
(16:06:13) rtimm: Oliver (obo) will do next milestone on DEV300
(16:06:33) _Nesshof_: rtimm: blauwal thanks
(16:06:34) ja_: rtimm: m42 ?
(16:06:45) _Nesshof_: ja_: no m42 this week
(16:07:03) _Nesshof_: we will focus on 3.1
(16:07:16) _Nesshof_: anything else for today ?
(16:07:46) rtimm: ja_: see above - obo will do next milestone on DEV300, but not this week
(16:07:59) _Nesshof_: by
(16:08:06) rtimm: bye bye
(16:08:10) blauwal: bye(14:58:20) Mitschnitt gestartet. Zukünftige Nachrichten dieser Unterhaltung werden mitgeschnitten.
(14:58:37) kai_a [n=Kai_Ahre@i577AA07B.versanet.de] hat den Raum betreten.
(14:58:42) ja_: Hi all
(15:00:29) volkerme [n=chatzill@77-21-35-10-dynip.superkabel.de] hat den Raum betreten.
(15:00:48) UweL [n=chatzill@nat/sun/x-1359bb9b38782ec6] hat den Raum betreten.
(15:01:48) _Nesshof_: moin
(15:01:56) blauwal [n=jr93709@sd-socks-197.staroffice.de] hat den Raum betreten.
(15:01:57) stefan_b: Moin!
(15:02:40) _Nesshof_: lets start with 3.1 release status
(15:03:00) _Nesshof_: blauwal: do you know the status of m1 ?
(15:03:55) blauwal: _Nesshof_: still "in progress"
(15:04:07) _Nesshof_: nomination and integration of cws is nowadays a bit slow
(15:04:41) _Nesshof_: svn diff and merge operation are much more slower than expected
(15:05:00) _Nesshof_: so not all nominated cws got into m1
(15:05:54) FrankS: bug build for m1 is already ongoing?
(15:06:03) _Nesshof_: for cws dv07 I discovered some new strings, that string already got translated in the database, so that an export into pootle will not result in new strings
(15:06:24) FrankS: -g+t
(15:07:34) FrankS: I'm asking 'cause
(15:07:47) _Nesshof_: FrankS: see blauwals statement above
(15:07:52) FrankS: the deadline for exceptional fixes" is this week
(15:08:05) FrankS: this doesn't answer the question
(15:08:14) FrankS: will m1 be built with the currently integrated CWSes only?
(15:08:21) _Nesshof_: FrankS: blauwal should know the answer
(15:08:25) FrankS: or will the remaining nominated CWSes be integrated before building?
(15:08:47) _rene_: 14:34 < _Nesshof_> so it will get into m2 (hopefully)
(15:08:51) _Nesshof_: remaining nominated cws will go into m2
(15:08:55) _rene_: so: no :)
(15:09:02) FrankS: The fact that two of our (Bases) major CWSes (dba31h abd dba31g) are not yet integrated doesn't really fit to the "deadline for exceptional fixes"
(15:09:21) FrankS: How are we expected to find exceptional problems when we won't even have a build in time?
(15:09:28) FrankS: That's ... weird
(15:09:41) _rene_: FrankS: dba31g is in m1.
(15:10:00) FrankS: EIS shows "nominated"
(15:10:06) FrankS: either EIS or you is wrong :)
(15:10:14) _rene_: then look at the clone for OOO310...
(15:10:25) _rene_: or just EIS' overview for m1 :)
(15:10:28) FrankS: argh
(15:10:30) ***FrankS is wrong
(15:10:35) FrankS: sorry
(15:10:38) blauwal: FrankS: see :-)
(15:11:00) FrankS: okay, this leaves me with dba31h, and the same question
(15:11:16) FrankS: how does a build which does not even contain all CWSes fit to the "deadline for exceptional fixes" being in three days?
(15:11:32) FrankS: do we assume all those CWSes don't introduce any problems?
(15:11:41) rtimm [n=Ruediger@nat/sun/x-35838fba878e85e7] hat den Raum betreten.
(15:12:13) _rene_: FrankS: we have the same issue with rptfix04. which is a blocker but it#s jfgreereport module is so hosed up......
(15:12:15) _Nesshof_: FrankS: lol
(15:12:48) FrankS: _rene_: I'd like to separate this topic, and clarify the more fundamental problem first, please
(15:13:04) _Nesshof_: FrankS: for the exceptional fixes feadline I will take the date of approval
(15:13:18) FrankS: _Nesshof_: so what?
(15:13:24) _rene_: _Nesshof_: that still is in 3 days
(15:13:25) FrankS: If the CWSes introduce problems, they're not yet known
(15:13:34) FrankS: so the CWSes with their fixes are not yet approved
(15:13:47) _rene_: _Nesshof_: fs has a point. you can't know then before people have m2 in their hands
(15:13:54) _rene_: which is when? next week?
(15:13:59) FrankS: m2 won't be finished before next week, so any problem-fixes won't be approved in three days
(15:14:06) _rene_: *nods*
(15:14:13) blauwal: _rene_: hopefully end of this week
(15:14:28) _Nesshof_: FrankS: _rene_ then we are in stopper mode
(15:14:49) FrankS: what's the difference between a stopper fix and an "exceptional code fix"?
(15:14:57) _Nesshof_: I assume if a cws causes problem that then it will become a stopper
(15:15:05) FrankS: "assume"?
(15:15:12) blauwal: FrankS: Stopper need to be agreed upon
(15:15:17) blauwal: FrankS: in this meeting
(15:15:26) _Nesshof_: blauwal is right
(15:15:49) _Nesshof_: exceptional code freeze tries to limit the amount of cws
(15:16:02) _Nesshof_: but not every contained issue is a stopper
(15:16:10) FrankS: I see
(15:16:16) FrankS: which is sad
(15:16:40) FrankS: because that leaves us with CWSes *ready before code freeze* being available to the public only 2 weeks before last CWS integration
(15:16:47) FrankS: which is unfortunate, to say at least
(15:17:43) FrankS: but be it, we probably do not want discuss moving the release date, do we?
(15:17:57) blauwal: FrankS: I think this is unavoidable in a train model with quarterly releases
(15:18:03) SunNF_ [n=Nils@wlan-sun.staroffice.de] hat den Raum betreten.
(15:18:03) FrankS: so, just for the record: The timing for this release is very ... unfortunate
(15:18:11) FrankS: hmm
(15:18:27) _Nesshof_: FrankS: noted
(15:18:41) FrankS: the conclusion is that releasing versions with potentially a lot of known bugs is "unavoidable" - I don't like this term, really :)
(15:18:50) FrankS: be it. period.
(15:19:17) _rene_: FrankS: no news :/
(15:19:23) _Nesshof_: does dba31h stopper issues
(15:19:25) _Nesshof_: ?
(15:19:32) _Nesshof_: ;-)
(15:19:36) _rene_: yes :)
(15:19:38) FrankS: If I knew, I wouldn't tell you :)
(15:19:53) blauwal: FrankS: see ._9
(15:20:00) FrankS: alone the fact that due to QA resource problems, we had two parallel CWSes, is a potential problem
(15:20:21) FrankS: but that's a different topic
(15:20:32) _rene_: that's not a problem of the release team or showver, that's a problem of the QA :)
(15:20:42) _rene_: s/showver/whoever/
(15:20:57) _rene_: .oO ( how did I manage to typo i that way? sigh )
(15:22:21) _Nesshof_: localization35 also will get a bit delayed
(15:22:42) _Nesshof_: we are waiting for localization of arabic UI a little bit
(15:23:05) _rene_: will it get into m2?
(15:23:17) _rene_: or m3?
(15:23:17) _Nesshof_: blauwal: rtimm: do you have a more detailed status for localization ?
(15:23:58) blauwal: _Nesshof_: moment, please
(15:24:19) _Nesshof_: due date in EIS still is Feb. 9, is this still valid ?
(15:24:33) blauwal: _Nesshof_: we are still waiting for strings ... we hope to start with it tomorrow
(15:24:52) blauwal: _Nesshof_: additionally there is now one language with a three letter ISO code
(15:24:55) _Nesshof_: ja_: have you got feedback for latest arabic snapshot ?
(15:25:20) blauwal: _Nesshof_: thus will break at least in two places
(15:25:24) _Nesshof_: blauwal: which language, do we expect trouble with this ?
(15:25:44) ja_: _Nesshof_: I got just one comment within my blog but ot was nothing new
(15:25:56) blauwal: _Nesshof_: it's one language from India ... which one exactly I can't rememmber just now.
(15:26:07) blauwal: s/rememmber/remember/
(15:26:39) _Nesshof_: blauwal: do we already have fixes for those breakages ?
(15:27:00) _Nesshof_: otherwise I would recommend to postpone that language
(15:27:04) blauwal: _Nesshof_: not yet, Vladimir is contemplating a workaround
(15:28:30) _Nesshof_: blauwal: once arabic translation for arabic has arrived we should start with loc%35, and leave that Indian language out if that does not build
(15:29:14) _Nesshof_: _rene_:status of rptfix04 ?
(15:29:24) sophi: _Nesshof_: I think it's papiamento
(15:30:14) FrankS: _Nesshof_: an answer from either you or _rene_ to Ocke's last mail about rptfix04 would answer your question :)
(15:30:17) blauwal: _Nesshof_: it's Dogri (dgo)
(15:30:25) blauwal: _Nesshof_: two other will follow
(15:30:40) FrankS: Ocke asked whether it would address your concerns if Pentaho made the SVN snapshot publicly available for download
(15:30:42) _rene_: FrankS: no.
(15:30:59) _rene_: FrankS: it does not help. take pristine sources and add a patch
(15:31:04) _rene_: like any other external module
(15:31:22) FrankS: Okay, let's talk about moving the release date, then
(15:31:29) FrankS: but beforehand: please elaborate your "no"
(15:31:33) FrankS: "no" is too simple to accept
(15:31:34) _Nesshof_: FrankS: we should stay with our established processes
(15:31:44) FrankS: yes
(15:31:46) _rene_: well, it's not my problem if you did crap from the start and then don't have time to clean up your mess
(15:32:15) _rene_: as _Nesshof_ said, the correct and established way is NOT to just create own zips of whatever and put it into download
(15:32:16) FrankS: sigh
(15:32:22) FrankS: yes
(15:32:25) FrankS: this was a failure
(15:32:28) _rene_: but to take upstreams tarballs and patch them if needed
(15:32:33) _rene_: so fix it.
(15:32:56) _Nesshof_: FrankS: is there any need for rptfix04 for the 3.1 release ?
(15:32:58) FrankS: What Ocke proposed and asked, but what nobody of you took time to answer (this way letting a few more days pass by)
(15:33:00) _rene_: should be easy for oj to dp
(15:33:03) _rene_: do
(15:33:08) FrankS: is how we could match the definition of "upstream" here
(15:33:23) FrankS: I am not sure if that's easy
(15:33:37) FrankS: as you yourself wrote, so you should know, there are *a lot* of changes
(15:33:44) FrankS: so it might not be that easy
(15:33:46) _rene_: upstream = pentahos tar.gz/.zip from sf.net/jfreereport
(15:33:47) FrankS: that's why Ocke's question
(15:33:51) _rene_: not my problem, to be honest
(15:33:57) FrankS: now read Ocke's mail, again
(15:34:11) FrankS: If the branch we would use were put online there: would that be "upstream"
(15:34:15) FrankS: by my definition: yes
(15:34:15) _rene_: you added the changes, not me. you broke --with-system-jfreereport
(15:34:59) FrankS: let's not count who broke what - not sure who would win :)
(15:35:07) _rene_: FrankS: by mine not. how do you get a mapping between pristine upstream dnd that branch? how do you get a mapping OOo<->branch?
(15:35:29) _rene_: FrankS: how do you repair --with-system-jfreereport to look whether it's the correct branch?
(15:35:50) _rene_: FrankS: and should I really package all the libs two times? One time vanilla, one time the branch? :)
(15:35:57) FrankS: by naming the release "jfreereport-whatever-x.y.z" and adjusting configure? Come on.
(15:36:08) _rene_: FrankS: for that, I need a diff on top of the vanilla ones.
(15:36:48) FrankS: for my understanding: --with-system-jfreereport takes the jfreereport installed in the system, and patches it?
(15:36:55) FrankS: right or wrong?
(15:36:57) _rene_: no
(15:36:59) FrankS: but?
(15:37:00) _rene_: it takes the jars.
(15:37:07) _rene_: and "links" with them
(15:37:13) FrankS: so they're unpatched
(15:37:13) FrankS: ?
(15:37:14) _rene_: (Class-Path: to them)
(15:37:18) _rene_: yes
(15:37:30) _rene_: unless you provide patched ones
(15:37:30) FrankS: Then what would it actually *change* if we had pristine+patch?
(15:37:44) FrankS: You would still use the pristing/unpatched ones
(15:37:46) _rene_: that one sees what you need to do to make it work with OOo
(15:37:56) _rene_: FrankS: the pristine ones do not work at all right now
(15:38:18) FrankS: yes, and this will continue to be, even with the change you request
(15:38:19) _rene_: FrankS: if you actually read the mail I wrote. liblayout does not build with all the newer pristine ones
(15:38:38) _rene_: FrankS: yes, but then you see what's patched. And either take the changes over or leave it. has to leave now
(16:05:42) blauwal: _Nesshof_: Kurt (kz) will finish m1
(16:05:45) _rene_: _Nesshof_: I want that on the ESC on 03.09. please.
(16:05:49) rtimm: Kurt currently is doing m1
(16:05:55) blauwal: _Nesshof_: Ivo (ihi) is in for m2
(16:05:58) ***ja_ just wrote one short paragraph about this discussion
(16:06:11) _rene_: _Nesshof_: that such broken things will not happen again. non-pristine sources (- non-free stuff) -> reject
(16:06:11) _Nesshof_: _rene_: np
(16:06:13) rtimm: Oliver (obo) will do next milestone on DEV300
(16:06:33) _Nesshof_: rtimm: blauwal thanks
(16:06:34) ja_: rtimm: m42 ?
(16:06:45) _Nesshof_: ja_: no m42 this week
(16:07:03) _Nesshof_: we will focus on 3.1
(16:07:16) _Nesshof_: anything else for today ?
(16:07:46) rtimm: ja_: see above - obo will do next milestone on DEV300, but not this week
(16:07:59) _Nesshof_: by
(16:08:06) rtimm: bye bye
(16:08:10) blauwal: bye
(16:08:13) UweL: bye
(16:08:16) blauwal hat den Raum verlassen ("Leaving").
(16:08:18) UweL hat den Raum verlassen (quit: "ChatZilla 0.9.83 [Firefox 3.0.5/2008120122]").
(16:08:55) stefan_b: Bye!
(16:08:13) UweL: bye
(16:08:16) blauwal hat den Raum verlassen ("Leaving").
(16:08:18) UweL hat den Raum verlassen (quit: "ChatZilla 0.9.83 [Firefox 3.0.5/2008120122]").
(16:08:55) stefan_b: Bye!

Personal tools