ReleaseStatus Minutes 2008-01-07 IRC log

(14:59:09) ja_: hi
(14:59:53) _Nesshof_: moin
(14:59:58) TrainedMonkey: hello
(15:00:14) bettina-h: Hi
(15:00:58) mdamboldt: Hi
(15:01:27) blauwal: Hi
(15:01:37) paveljanik: Hi
(15:01:37) kso [n=kso@nat/sun/x-ca7b056a7a3f8c0a] hat den Raum betreten.
(15:03:21) _Nesshof_: thorstenziehm: do you want something to say about the amount issue for 2.4
(15:03:48) thorstenziehm: should I? :-)
(15:04:12) thorstenziehm: We have round about 70 CWS open for OOo 2.4
(15:04:37) _Nesshof_: code freeze will be in two weeks
(15:05:06) _Nesshof_: looks like that we need to drop some cws for te release
(15:05:22) thorstenziehm: we have to select the MUST HAVES for this release
(15:06:39) _rene_: _Nesshof_: hyphenexternal is a must imho, it fixes a license problem. hunspellexternal fixes the maintainability of the spellchecker. (some random, not distinuishable version in the tree -> distinguishable external version). the latter just got delayed by QA of hunspell2 and someone still needs to look after both for Windows...
(15:07:27) _Nesshof_: many of them have no due date or a due date in the past
(15:07:52) _Nesshof_: the amount of cws seems feasable if we sort out these cws :-)
(15:08:36) _Nesshof_: _rene_: agrred
(15:09:58) _Nesshof_: kso: can we care about the due dates please, this would leave to a better estimation whether we are able to make it or not
(15:10:24) thorstenziehm: _rene_ : what do you mean with someone have to look for Windows? Should my team do this, or is this only for RE? when will this CWSes be 'ready for QA'?
(15:11:04) _rene_: thorstenziehm: when someone makes them build on Windows.
(15:11:41) ***_rene_ has no clue about Windows building and (import) libs on Windows
(15:12:11) _rene_: thorstenziehm: I don't mind who does (vq wanted to, but I guess he's busy) but someone needs to :)
(15:12:41) _rene_: _Nesshof_: the hunspell version is the same (1.1.12), so there shouldn't be a problem from that side
(15:12:49) ***_rene_ did that extra
(15:14:12) _rene_: s/extra/intentionally/
(15:14:16) TrainedMonkey: after, when we finish the cws stuff, I have one little question/suggestion in "any-other-business"
(15:14:54) _Nesshof_: TrainedMonkey: ok
(15:18:59) TrainedMonkey: is there something going on in back-channels, it looks very quiet here
(15:19:53) _Nesshof_: no, AI for thorstenziehm, kso and me to go over the list of cws and sort some cws out
(15:20:58) _Nesshof_: any other items ?
(15:22:16) TrainedMonkey: _Nesshof_: I was having a little discussion with myself about how we can improve the tinderbox red-status handling
(15:22:38) TrainedMonkey: _Nesshof_: according what I understood is that normally one asks the developer.
(15:22:48) _Nesshof_: TrainedMonkey: any you have some ideas
(15:22:50) _Nesshof_: ?
(15:23:35) TrainedMonkey: _Nesshof_: the normal and easies answer is that it is a local problem. Nevertheless, Christian Lohmaier has quite a good overview a bout that kind of problems, One could ask him what he things about that
(15:23:43) xiuzhi [n=Administ@125.96.14.147] hat den Raum betreten.
(15:24:17) _Nesshof_: we are open to proposals
(15:24:40) TrainedMonkey: _Nesshof_: generally cloph knows whether it is a local problem or not
(15:25:03) rtimm: TrainedMonkey: does Christian know about this recommendation? Can get quite disturbing for him ...
(15:25:13) TrainedMonkey: _Nesshof_: so asking him would be a good practice. He doesn't scale well, I know, but...
(15:25:29) TrainedMonkey: rtimm: I don't think more than integration of broken CWS
(15:25:31) _Nesshof_: TrainedMonkey: looks like a single point of failuere
(15:26:01) cloph [n=cl@ppp-88-217-36-35.dynamic.mnet-online.de] hat den Raum betreten.
(15:26:39) TrainedMonkey: cloph: I just proposed asking you as a standard procedure of handling red-tinderbox status CWSes
(15:26:45) TrainedMonkey: cloph: what do you think about it
(15:26:53) TrainedMonkey: cloph: as a fallback solution
(15:27:16) cloph: What do you mean with "me as stabdard procedure"?
(15:27:49) TrainedMonkey: cloph: I mean, currently: a red status -> ask develper and believe what they say
(15:28:16) TrainedMonkey: cloph: future practice, ask developer and if the answer is that it is a local problem of the tinderbox, ask cloph
(15:28:20) _rene_: .oO ( and often what they say is wrong )
(15:28:42) blauwal: _rene_: yes and often it's true.
(15:29:04) _rene_: blauwal: I didn't say otherwise. :)
(15:29:21) cloph: TrainedMonkey: OK - I'm maintaining most of the (real) tinderboxes anyway.
(15:29:30) TrainedMonkey: cloph: the idea is that you are someone who is able to know whether there is a local problem or not
(15:29:47) TrainedMonkey: _Nesshof_: what do you think in the light of cloph's answer?
(15:29:54) rtimm: There are times when no CWS gets all tinderbox stati green. So it may happen that that cloph gets quite busy answering those questions.
(15:30:19) cloph: yes, I will most likely be able to tell whether the problem is with the cws or the bots/tinderboxes.
(15:30:36) _Nesshof_: TrainedMonkey: hmmmm
(15:30:53) TrainedMonkey: only 4 m, not big doubt there?
(15:31:09) cloph: Yes, unfortunately some of the buildbots aren't well-maintained. I'll ask Shaun to remove them from the "report to tinderbox" list, so that those results won't appear on tinderbox
(15:31:12) _Nesshof_: I think this might be a topic for the tinderbox group first
(15:31:15) _rene_: blauwal: but often it's just sun vs. community env which breaks.
(15:31:29) _Nesshof_: blauwal: do you know how that group is going ?
(15:31:31) TrainedMonkey: _Nesshof_: or having an external contributor sharing gate-keeping is bad?
(15:31:34) blauwal: _rene_: and often it's just a cwsresync for integration etc
(15:31:35) _rene_: blauwal: and I don't believe that, if all tinderboxes are red, it's a local problem of the tinderbox
(15:31:49) _Nesshof_: TrainedMonkey: no, no problem with that
(15:31:53) cloph: _rene_: ?
(15:31:58) _rene_: blauwal: or cwsresyncs on files alone making the cws inconsistent :)
(15:32:06) _rene_: cloph: dba24d? ;)
(15:32:11) cloph: If all are read there is an easy answer: Either the cws is really broken
(15:32:11) TrainedMonkey: let's not start to create committees to discuss issues that can be discussed and solved in 5 minutes
(15:32:15) _Nesshof_: TrainedMonkey: it's the problem if there is just one person acting as gateway
(15:32:16) cloph: or there is a new module
(15:32:20) _rene_: cloph: exactly
(15:32:25) cloph: (or an infrastructure problem like anoncvs downtime)
(15:32:35) TrainedMonkey: _Nesshof_: only as fall-back solution I mean
(15:32:36) cloph: In all cases, the problem is not within the bots/tinderboxes
(15:32:49) _rene_: cloph: read again. I did say exactly what you said.
(15:33:03) TrainedMonkey: _Nesshof_: I am expecting the developer to be responsible and fix bugs she can reproduce
(15:33:34) cloph: Ah, the comma was not meant to divide your sentence in two thoughts... - sorry for the misunderstanding.
(15:33:53) blauwal: _Nesshof_: Ause and Kurt give the bots/tinderboxes a lot of attention
(15:34:42) TrainedMonkey: _Nesshof_: I found some times real breakages that 15 minutes of investigation was able to solve
(15:35:05) TrainedMonkey: _Nesshof_: but in the comments of the CWSes was ( breakage not related to the CWS)
(15:35:41) blauwal: TrainedMonkey: there is also a timing factor to consider. Someone makes a comment, later there is a real porblem
(15:35:48) cloph: Yes, and often no comment at all, but cws already nominated... Those cws then cost the most effort :-(
(15:36:09) rtimm: TrainedMonkey: just to be shure: you are talking about all tinderbox statis beeing red, or just any?
(15:36:21) _Nesshof_: as we will not integrate all 70 cws in the next two weeks I'm open to try this out the next 10 days
(15:36:28) TrainedMonkey: rtimm: sometimes there are all, sometimes only x86_64 ...
(15:36:49) rtimm: TrainedMonkey: and in what case you would ask cloph?
(15:37:23) TrainedMonkey: if there is a breakage of a tinderbox where the base milestone is building well and no explanation of the breakage
(15:37:43) cloph: A quick overview: If the Mac X11 one is read, the Fedora and the O3 one are green, then it is very, very likely a warnings=errrors issue (only the mac one has it turned on, and uses gcc4.0.1 that sometimes is a but too cautious)
(15:38:32) _rene_: so it's a non-issue ;-)
(15:38:34) ***_rene_ hides
(15:38:38) cloph: If the Fedora box breaks, but the others are OK, then it is most likely a 64 bit issue (integer types or similar) - or might be a problem with gij (the other ones use Sun/Apple java)
(15:39:22) TrainedMonkey: yeah, fedora will break with umlauts in java files and encoding being not utf8
(15:39:39) rtimm: Where can I see master milestone reference (i.e. if it is red, too)?
(15:39:43) TrainedMonkey: but many community distro build will too, so that is easy to fix an dimportant
(15:39:44) blauwal: TrainedMonkey: should break on other platforms, too ...
(15:39:52) _Nesshof_: cloph: what about doing the next nomination round together ?
(15:40:01) cloph: For now, you can ignore the edgy buildbot, that is one of the unreliable ones. - if the windows one breaks, you got the expert in-house.
(15:40:38) ja_: .
(15:41:07) thorstenziehm: _Nesshof_ : But when and who should inform Cloph? the QA representative, the developer, in state 'new' befor sending to 'ready for QA' or when it is 'ready for QA' or before 'nomination?
(15:41:47) thorstenziehm: for me it's not clear, how the process should work
(15:42:12) TrainedMonkey: thorstenziehm: cloph is quite offten putting comments without being asked into CWSes that deserve it, just not to ignore them
(15:42:13) _Nesshof_: thorstenziehm: ask cloph and TrainedMonkey for their suggestion
(15:42:24) cloph: thorstenziehm: I should only be contacted if in doubt, not for all cases.
(15:42:40) _Nesshof_: I would say: the earlier the better ...
(15:42:48) _Nesshof_: but latest before nomination
(15:42:54) cloph: Like developer really has a look at the log and is unsure why it breaks/cannot find a problem. Then ask me.
(15:43:08) TrainedMonkey: thorstenziehm: the procedure could be: see the tinderbox status of the base milestone and of the CWS, if they differ and no explanation, ask cloph
(15:43:25) thorstenziehm: TrainedMonkey, cloph : oftne the comments are after setting the CWS in state 'approved by QA'
(15:43:44) cloph: In general: it should be: ask the person that is listed at the very top in the lox as tinderbox administrator. But as unfortunately the builbot sets the same one for all buildbots, this only works for the real tinderboxes.
(15:43:49) TrainedMonkey: thorstenziehm: that is the problem if QA sets it AbQA with red tinderbox :-P
(15:44:01) cloph: thorstenziehm: You refer to my comments?
(15:44:23) cloph: Sure, I have a look that are about to get integrated, then I take action to prevent a broken master (well, I at least try)
(15:44:51) cloph: For the others, I still hope that devs/QA will have a look at the breaker and fix the errors themselves, without the need for an extra comment.
(15:45:12) thorstenziehm: TrainedMonkey : My QA team shouldn't accept a CWS in state 'Ready for QA with a red tinderboy status. In our process (also documented on OOo) the developer has to give a comment ever a tinderbox is red! But this isn't done by every QA rep in the community.
(15:45:19) thorstenziehm: cloph : yes
(15:45:52) TrainedMonkey: thorstenziehm: that is what we are trying to fight now. We have all interest to have a high quality product
(15:46:41) thorstenziehm: TrainedMonkey : you are welcome :-)
(15:46:58) TrainedMonkey: thorstenziehm: :-)I
(15:47:48) TrainedMonkey: thorstenziehm: it was simply always so for me at least, never mind what other might tell you. Nevertheless, I will never stop teasing QA either :-)
(15:50:28) cloph: I would prefer if the devs (when they write a comment at all) wouldn't just write "not related to the cws", but "breaks because of <reason for break>, not related to cws" - that way it is easier to tell whether they did understand the log correctly or not.. If it breaks because of an unrelated error, don't hesitate to contact me! (unless it breaks because of a new module, that is nothing I can account for in the buildscript)
(15:51:30) cloph: But false positives are rare for the abovementioned bots... Nevertheless if they occur, let me know, so that I can avoid flagging the build as broken in that case.
(15:53:20) cloph: (you might have noticed that some of the Mac results are flagged orange, that's where I workarounded such a "false" build-breaker)
(15:53:58) rtimm: cloph: could you provide that info about known good bots somewhere where easy to find? At best together with a link to reference master milestone builds.
(15:54:24) rtimm: cloph: I neveer can remember whether a given milestone has problems for platform xyz or not
(15:55:47) cloph: As a rule of thumb: All milestones no longer listed did buid fine on the listed bots. If not, a cws based on that cws is skipped. For example, the o3-bot skips all cws based on m237, since that one just is too broken in that case.
(15:56:23) cloph: You only need to look for the master status for new master milestones. The last three milestones are listed on http://tinderbox.go-oo.org/ready_for_QA.express.html
(15:57:58) _Nesshof_: so, what are the next steps to do ?
(16:00:32) _Nesshof_: none ?
(16:01:05) ***_Nesshof_ will contact cloph if doing the next nomination round
(16:01:25) _Nesshof_: anything else for today ?
(16:01:32) ja_: How can the tinderbox status caption be green but have 80 errors ?
(16:02:02) TrainedMonkey: ja_: care about colour only
(16:03:31) cloph: Just have a look at the brief log and you'll see what is counted as error.
(16:03:50) cloph: error not being the same as build-breaker...
(16:05:17) cloph: but as TrainedMonkey wrote: If it is green (or orange or grey), you don't have to bother. Only red ones need to be looked at.
(16:05:32) cloph: (if it is grey, you should consider a resync, but that's another story :-P)
(16:05:42) ja_: The status should be more self explanatory
(16:06:01) cloph: Well "red" = bad, "green" = good
(16:06:30) TrainedMonkey: basically, what we are trying is to diminish breakages, We cannot prevent some problems slip through, but we can make them highly unlikely
(16:06:44) TrainedMonkey: perfect is the worst enemy of very good :-)
(16:08:59) rtimm: _Nesshof_: nothing else from my side.
(16:09:23) TrainedMonkey: neither from mine
(16:09:24) _Nesshof_: ok, then lets close meeting for today
(16:09:34) TrainedMonkey: _Nesshof_: you have the keys
(16:09:39) rtimm: for your information: RE on duty for SRC680 m242 is Oliver (obo). OOH680 m2 will be mine (rt)
(16:09:47) TrainedMonkey: :-)
(16:09:51) TrainedMonkey: rtimm: thanks
(16:10:05) _rene_: rtimm: just ooc, when will you do s/SRC680/DEV300/ ?
(16:10:20) TrainedMonkey: good question, surprising from _rene_
(16:10:26) rtimm: _rene_: not determined yet.
(16:10:39) blauwal: _rene_: The prerequisite has been integrated. So it won't take that long
(16:10:52) rtimm: One prerequisite was CWS supdremove which just got integrated.
(16:11:05) rtimm: blauwal: :-)
(16:12:11) TrainedMonkey: blauwal: on completely unrelated note, with deprecating of certain compilers, we can extend the new boost to the new compilers and also try to avoid to have a forest of stlport versions
(16:12:53) blauwal: TrainedMonkey: well the problem is MacOSX (old) and gcc-3.3.x and OS/2
(16:13:15) blauwal: TrainedMonkey: I hope these platform could switch to a newer gcc
(16:13:22) TrainedMonkey: yeah, that is why I am thinking about progressive elimination.
(16:13:31) _rene_: do we really still need to support Panther?
(16:13:32) TrainedMonkey: blauwal: whenever we can and it builds well
(16:13:53) blauwal: TrainedMonkey: I was more thinking on eliminating stlport on DEV300 for good (with exception Solaris)
(16:14:27) TrainedMonkey: blauwal: yeah, would be very nice, but maybe you will find a wall because of some hypothetical extensions that are c++ and binary only
(16:15:09) blauwal: TrainedMonkey: don't think so. There is some usage of slist, rope and hashmap but I think we can manage taht
(16:15:14) _rene_: my personal opionion on this is: let's no care, this is a major version, we can break compat. third party binary-only things then need to be updated. so what?
(16:15:29) TrainedMonkey: blauwal: why we don't rewrite OOo in plain C only, it would be much easier to create new language bindings :-)
(16:15:40) _rene_: of course, in a minor release this is something else, but this is a major release...
(16:15:58) TrainedMonkey: blauwal: and even sun studio would be able to compile it if no STL is needed
(16:16:00) TrainedMonkey: :-P
(16:16:05) ja_: TrainedMonkey: do you volunteer ?
(16:16:11) rtimm: TrainedMonkey: shall I write an issue and assign it to you?
(16:16:16) _rene_: it doesn't make sense to keep legacy stuff until eternity
(16:16:26) TrainedMonkey: ja_: rtimm: do, I will start, you will debug it
(16:16:38) rtimm: :-/
(16:16:48) TrainedMonkey: ja_: rtimm: but I start it only if blauwal fixes the binfilter warnings
(16:17:10) TrainedMonkey: Sankt Niemerlei is next month I think
(16:17:11) blauwal: TrainedMonkey: no chance :)
(16:18:00) TrainedMonkey: blauwal: but I believe that all gcc platforms can manage the absence of stlport
(16:18:07) TrainedMonkey: blauwal: and win32 maybe too
(16:18:11) blauwal: TrainedMonkey: that's what i said
(16:18:12) ***rtimm thinks it's better to stop now ...
(16:18:48) blauwal: and SunStudio's native STL is STLport
(16:19:18) TrainedMonkey: blauwal: yeah, I saw it on Nevada. But how it is on 2.7, 2.8?
(16:19:31) blauwal: Since aeons
(16:19:51) blauwal: Anyway we will switch to SunStudio 12
(16:20:01) TrainedMonkey: blauwal: there it will be OK then
(16:20:05) blauwal: Ok got to leave. Bye!"
(16:20:13) TrainedMonkey: y
(16:20:18) ja_: bye
(16:20:19) TrainedMonkey: b y e
(16:20:21) blauwal hat den Raum verlassen ("Leaving").
(16:20:26) rtimm: bye
(16:20:34) bettina-h: bye