ReleaseStatus Minutes 2009-02-09 IRC log

Conversation with #oooreleases at 9. Februar 2009 14:58:37 MET on ja_@irc.freenode.net (irc)
(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.
(15:38:51) _rene_: FrankS: currently, you don't see at all that this stuff is heavily patched.
(15:39:11) _rene_: FrankS: with the "normal" approach you have many benefits
(15:39:15) FrankS: I see that it is - what I don't see is the problem in being that way
(15:39:22) _rene_: - you have pristine sources
(15:39:28) FrankS: I do not yet understand the liblayout problem
(15:39:28) _rene_: - you see the exact patch you apply
(15:39:36) FrankS: is liblayout also taken from the system, or from within the OOo source tree?
(15:39:37) _rene_: - you get a clean build of the lib
(15:39:57) _rene_: FrankS: system-jfreereport takes all the jars from the system.
(15:40:17) _rene_: and the vanilla liblayout does not build against the other new versions
(15:40:20) FrankS: including liblayout? So how is it it cannot build with the committed jfreereport, if that's not used?
(15:40:31) FrankS: Ah - we have liblayout in vanila?
(15:40:32) FrankS: Right?
(15:40:54) _rene_: what I did to test --with-system-jfreereport was: updating all the debs with he jars
(15:40:57) _rene_: from vanilla.
(15:41:14) _rene_: but the uptodate liblayout does not build with the uptodate libformula etc.
(15:41:32) _rene_: it does somehow with your beyond help patched internal version, though
(15:41:39) FrankS: "uptodate" with respect to which repositoryx - your system or OOo's?
(15:41:51) _rene_: sf.net/jfreereport
(15:42:05) _rene_: took the versions from there which the internal jfreereport claims to use
(15:42:17) FrankS: So you say the liblayout/jfreereport downloaded from sf.net do not work together?
(15:42:21) FrankS: How is this a problem of OOo?
(15:42:29) FrankS: How is it we at OOo broke this?
(15:42:32) _rene_: that it works for your tree
(15:42:38) _rene_: and for that patched it heavily
(15:42:45) _rene_: and that is not seeable at all
(15:42:59) FrankS: yes, because we use a version other than the one from sf.net - why's that a problem of OOo if your distro insists on using the broken version from sf.net?
(15:43:16) FrankS: the only item which you continue to bring up is whether or not too see the differences
(15:43:20) _rene_: it's not seeable at all that you basically exchanged all of the libs to something completely different
(15:43:29) FrankS: I still fail to see the problem with that
(15:43:30) _rene_: FrankS: we insist on using the official version.
(15:43:37) FrankS: which is broken, as you yourself said
(15:43:37) _Nesshof_: FrankS: _rene_what about a phone call to continue this discussion offline ?
(15:43:42) _rene_: FrankS: well, I can live with patching it
(15:43:49) _rene_: FrankS: BUT WE DO NOT HAVE A PATCH
(15:43:57) FrankS: well, I can't unless I know how much of an effort this is
(15:43:58) _rene_: FrankS: because the stuff is hidden in the re-packaged zips
(15:44:11) FrankS: I'll write you a Perl script comparing the versions
(15:44:12) _rene_: FrankS: if we had pristine source + patch we could see what's patched
(15:44:17) FrankS: if you need those to create your debs
(15:44:26) FrankS: yes, that's the first time you mention this
(15:44:30) FrankS: it doesn't make it more important
(15:44:39) FrankS: s/first/forth/
(15:44:58) _rene_: yeah, let's completely ignore distro needs
(15:44:58) FrankS: sf-version doesn't work, but you insist on using it
(15:45:03) FrankS: that's not an OOo problem
(15:45:08) _rene_: what was the issue with OOo vs. GoOO again?
(15:45:10) FrankS: we offer you using an version which works - great
(15:45:12) _rene_: FrankS: no, I don't.
(15:45:30) FrankS: (15:43:30) _rene_: FrankS: we insist on using the official version.
(15:45:32) _rene_: FrankS: I insist on a solution where you can see in-tree (not me, but all packagers) what is done
(15:45:46) _rene_: FrankS: I could do liblayout-java and liblayout-java-ooo
(15:45:48) of_sun: Can't this be discussed in a dev channel?
(15:45:53) stefan_b: Offline phone call sounds feasible, too.
(15:46:14) _rene_: of_sun: no, because we discuss a blocker. and phone doesn't work, I am at wor
(15:46:18) _rene_: not-OOo-related at all.
(15:46:39) stefan_b: OK, there is tools like private chat. Ever tried?
(15:46:44) _rene_: FrankS: but for that split, I need a patch. and the normal way of building stuff provides that
(15:47:05) _rene_: FrankS: what is so special on jfreereport that you can't do stuff like hsqldb? or the other libs?
(15:47:25) _rene_: FrankS: what is so special there that you can't add a pristine tarball + patch or the branch?
(15:47:27) FrankS: but, if there were a release "lib-foo-ooo" on sf.net (this is what Ocke proposed), you would get the same for free, without us touching anything in this late phase
(15:47:30) stefan_b: What about a 15 min break for all but FrankS and _rene_?
(15:47:48) ***FrankS needs to be off in 10 minutes
(15:48:02) stefan_b: OK, type faster :-)
(15:48:07) _Nesshof_: FrankS: we should stay with our established processes
(15:48:09) _rene_: FrankS: will we get that in the next days so I can start packaging them and test rptfix04? if not, we need a solution for *the next days*
(15:48:10) FrankS: *even* faster ....
(15:48:23) _Nesshof_: official release source tar balls with patches
(15:48:49) FrankS: let me repeat: I do not know how much of an effort this would be, as the changes were *big*
(15:48:52) FrankS: let me repeat II:
(15:49:00) FrankS: but, if there were a release "lib-foo-ooo" on sf.net (this is what Ocke proposed), you would get the same for free, without us touching anything in this late phase
(15:49:13) _rene_: wrong
(15:49:16) _rene_: I still need them asap
(15:49:26) _rene_: to *test* the build with those libs
(15:49:29) FrankS: hmm? You could get this download by tomorrow
(15:49:37) FrankS: you could get the patch by tomorrow, *at the earliest*
(15:49:58) _rene_: because neither you or oj did even care about a clean build or even system-jfreereport.
(15:50:03) FrankS: yes
(15:50:04) FrankS: yes
(15:50:05) FrankS: yes
(15:50:07) FrankS: repeat it
(15:50:10) FrankS: that won't solve our problem
(15:50:14) _rene_: FrankS: no problem.
(15:50:18) FrankS: let's try solving the problem, okay?
(15:50:22) FrankS: not sueing us
(15:50:29) _rene_: FrankS: I have no problem with repeating facts :)
(15:50:33) _rene_: anyway
(15:50:40) FrankS: I have, if they distract us from the real problems
(15:50:46) _rene_: I can live with those tarballs *now*, as a compromise
(15:50:55) _rene_: but *IF* you do that
(15:51:05) _rene_: please do it cleanly for 3.1.1 or 3.2
(15:51:20) _rene_: vanilla release tarball + patch
(15:51:25) FrankS: *deal*
(15:52:19) _rene_: FrankS: qhy did those changes not get into vanilla jfreereport?
(15:52:44) FrankS: ask me something easier
(15:52:48) _rene_: FrankS: what's the reason? why can't you just do your stuff there and upse whatever release you need from them?
(15:52:59) _rene_: FrankS: instead of heavily patching them?
(15:52:59) FrankS: or, better: ask Ocke
(15:53:12) FrankS: i'm just his substitute here because he's already off ...
(15:53:12) _rene_: no I don't, he won't care about technical crap
(15:53:16) _rene_: been there, done that
(15:53:23) FrankS: that's no patches, that's a separate development branch
(15:53:28) _rene_: why?
(15:53:52) _rene_: .oO ( why does that remins me of Sun telling me I should not do go-oo but vanilla )
(15:54:13) _rene_: and *then* you do the same with jfreereport libs :)
(15:54:23) FrankS: I can try to find out the "why", but I'm not *that* deep in ocke's project
(15:54:29) FrankS: probably shitty politics :)
(15:54:38) FrankS: anyway, that's not really "release status meeting" anymore
(15:54:47) _rene_: wrong, it is
(15:54:57) _rene_: we discuss how we can get a cws which contains a blocker ready
(15:55:05) _rene_: s/blocker/blocker fix/
(15:55:08) FrankS: I thought we have the solution?
(15:55:18) FrankS: (15:50:46) _rene_: I can live with those tarballs *now*, as a compromise
(15:55:20) ***MechtiIde read it with interest
(15:55:33) FrankS: (15:51:05) _rene_: please do it cleanly for 3.1.1 or 3.2
(15:55:38) _rene_: ok, then we discuss about to solve it correctlly for the future (3.1.1/3.2)
(15:55:38) FrankS: (15:51:25) FrankS: *deal*
(15:55:50) _rene_: that#s still on-topic here :)
(15:55:59) _rene_: especially for 3.1.1 :)
(15:56:01) FrankS: (15:51:20) _rene_: vanilla release tarball + patch
(15:56:08) FrankS: (15:51:25) FrankS: *deal*
(15:56:26) FrankS: where's the need for further discussions?
(15:56:43) ***rtimm has a deja vu ...
(15:56:50) _rene_: that we should try to clean it up to not need a invasive patch
(15:57:01) _rene_: that we should try to be able top use vanilla.
(15:57:35) FrankS: sure, patches are Bad (TM)
(15:57:37) _rene_: FrankS: you == Sun accuse us go-oo'isians of exactly what you're doing right now with jfreereport. I think that's discussion-worthy.
(15:57:49) FrankS: nonetheless the existence/size of the patch depends on pentaho's release strategy
(15:57:51) FrankS: which is not under our control
(15:58:06) FrankS: sigh
(15:58:09) _rene_: FrankS: then just send the patch, wait till it's iontegrated and depend on that version. that's how it works :)
(15:58:22) _rene_: that's what you expect us to do, too :)
(15:58:33) FrankS: _rene_, that's off-topic for this particular meeting, and my time is over
(15:58:40) FrankS: my daughter will not appreciate /me coming too late
(15:58:51) _rene_: FrankS: ok, I want the tarballs *tonight*
(15:58:59) FrankS: I want a world of piece
(15:59:02) _rene_: FrankS: so I can start packaging them and try.
(15:59:12) FrankS: Ocke has the contact to the developers, I probably won't reach him 'til tomorrow
(15:59:19) FrankS: s/piece/peace/
(15:59:23) _rene_: FrankS: well, every day later will delay rptfix04. and note a buil dto just reportbuilder/reportdesign takes says
(15:59:29) _rene_: days
(15:59:35) FrankS: noted
(15:59:39) FrankS: I can't change the situation
(15:59:51) FrankS: (15:59:12) FrankS: Ocke has the contact to the developers, I probably won't reach him 'til tomorrow
(15:59:52) _rene_: you can - for the future
(16:00:34) _rene_: I will maybe just disable the SRB until this is cleaned up, not decided yet. will decide later.
(16:00:40) _rene_: just now, I want the cws be clean.
(16:01:01) FrankS: your decision - unless do don't disable it in the without-system-jfreereport case
(16:01:08) FrankS: s/do/you/
(16:01:39) _rene_: that could also be an option. temporarily use system-jfreerpeport
(16:01:47) _rene_: but that bloats up the oxt so massively.... :-(
(16:02:16) _rene_: (http://packages.debian.org/experimental/openoffice.org-report-builder is how it looks like currently for 3.0.1..)
(16:02:24) _rene_: only 665k
(16:02:36) FrankS: are we done?
(16:02:56) _rene_: FrankS: I'll file an issue for the clean solution (P1)
(16:03:10) _rene_: FrankS: and add it as a blocker for 3.1.1 once that issue is created
(16:03:26) _rene_: otherwise, yes, we're done :)
(16:03:30) FrankS: I'll reprio to P2 - P1 implies "to be fixed in the next build" by definition, which is m1/m2 - let's be serious
(16:03:33) FrankS: okay, fine
(16:03:33) FrankS: by
(16:03:36) FrankS: bye
(16:03:41) FrankS heißt jetzt FrankS_away
(16:03:47) _rene_: FrankS: we can play ping-pong, I'll always set it back to P1
(16:04:16) _rene_: FrankS_away: after the release "the next build" is ok ;-)
(16:05:13) ***_Nesshof_ is looking forward to read the minutes ;-)
(16:05:26) _Nesshof_: rtimm: RE duties this week ?
(16:05:36) ***_Nesshof_ 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:11:17) ml2: bye
(16:12:51) ja_: bye