ReleaseStatus Minutes 2008-03-10 IRC log

(14:59:25) ja_: hi
(14:59:51) paveljanik: Hi
(15:00:01) _Nesshof_ [n=mh@nat/sun/x-8ee222da17f5b44f] hat den Raum betreten.
(15:00:10) _Nesshof_: moin
(15:00:49) Fridrich: moin
(15:01:33) volkerme: Moin
(15:01:34) bettina-h: moin
(15:02:06) _Nesshof_: review of 2.4 issues :
(15:02:10) _Nesshof_: are we done ?
(15:02:20) _rene__: first I want to know why rc4 is not uploaded yet
(15:02:26) _Nesshof_: m10 has been built and ja_ is preparing the upload
(15:02:44) _Nesshof_: _rene_ ja_ just returned from cebit
(15:04:09) _Nesshof_: so the new estimated release date would be March 18th ?
(15:05:24) Fridrich: ok
(15:05:39) _Nesshof_: anything else regarding the 2.4 release ?
(15:06:06) _Nesshof_: 3.0 release:
(15:06:20) _Nesshof_: ui/feature freeze was last week
(15:06:34) _Nesshof_: handover for translation is planned for Thursday
(15:06:50) _Nesshof_: not all of the feature cws have been integrated yet
(15:06:57) _Nesshof_: because of conflicts
(15:07:06) _rene__: and some are RfQA ;-)
(15:07:12) _rene__: .oO ( presenter* )
(15:07:21) _Nesshof_: rtimm: do you know of the current status of the build
(15:07:45) rtimm: _Nesshof_: not precisely
(15:08:06) _Nesshof_: _rene_: my plan was to have the current milestone completed asap so that we can do another round in time before the translation handover
(15:08:23) rtimm: On unix like systems Oliver seems nearly done
(15:08:51) rtimm: but he did not even touch windows, AFAIK. So if we have platform specific issues there they are yet to discover
(15:09:30) rtimm: perhaps we can get 'ready for CWs use' tomorrow evening
(15:09:34) rtimm: (just guessing)
(15:10:18) _Nesshof_: rtimm: that would be IMHO the latestet possibilty to get the remaoning stuff integrated in time for translation hand over
(15:10:32) blauwal [n=jr93709@sd-socks-197.staroffice.de] hat den Raum betreten.
(15:10:33) _Nesshof_: otherwise the l10n community will kill us ;-)
(15:10:59) rtimm: is it a big difference *who* is killing us?
(15:11:09) paveljanik: ;-)
(15:11:52) _Nesshof_: who else should do ?
(15:12:58) rtimm: QA, if we just integrate to keep schedules. Or developers, if we wrongly resolve merge conflicts ourselves. Or ...
(15:13:35) _Nesshof_: thorstenziehm: do you expect that we'll get the approval for the remaining cws until tomorrow
(15:13:36) rtimm: other parts of the community because milestone quality decereases so much
(15:13:36) _Nesshof_: ?
(15:14:28) thorstenziehm: _Nesshof_ : not really. some of the CWS we got late last week, and there is some testing need
(15:14:28) _Nesshof_: rtimm: what is your suggestion to do ?
(15:15:13) rtimm: kill program manager ;-)
(15:15:24) thorstenziehm: _rtimm_ : we never kill the RE team, we kill the developers :-)
(15:15:43) ***rtimm has no real suggestion
(15:15:54) rtimm: thorstenziehm: :-)
(15:16:34) _Nesshof_: I see two (or three alternatives):
(15:16:56) _Nesshof_: drop some of the remaining cws which will not make approval until tomorrow
(15:17:15) _Nesshof_: delay the translation handover for at least one more week
(15:17:39) _Nesshof_: paveljanik: what would be the reaction of our l10n communities ?
(15:17:42) ***_rene__ votes for alternative 2
(15:17:58) Fridrich: +1 from me too
(15:17:58) stefan_b [n=Stefan@nat/sun/x-f159273d1c1f5e87] hat den Raum betreten.
(15:18:02) ***blauwal agrees
(15:18:09) paveljanik: _Nesshof_: no issue. If they want to translate, they already do - I do not expect 100000 strings in delayed cwses...
(15:18:22) paveljanik: so, +1 for second alternative as well
(15:18:33) _Nesshof_: if we delay translation handover we need to shift release dates for Beta and Final
(15:18:34) blauwal: +1 for delayed handover
(15:19:10) thorstenziehm: +1 for alternative 2, because the features do not have so much translation in it; most of the translation issues are handed over some weeks ago
(15:19:47) thorstenziehm: but this could mean, that we will have a delay of one week for Beta too? Or do we want to hold the timeline there?
(15:20:47) Fridrich: delaying beta one week should not be really such a drama
(15:21:22) ja_: If it is possible for the localization teams then I'd vote for the second alternative.
(15:23:01) ***_Nesshof_ just called rafaella
(15:23:40) _Nesshof_: she we be on vacation if we delay one more week but she then expects also just one week of delay for translation then
(15:24:01) ***_Nesshof_ is looking at the schedule
(15:24:50) _Nesshof_: we the would be on April 24th for last cws integration for beta
(15:25:09) _Nesshof_: and estimated release for 3.0 would then be May 8th
(15:25:57) _Nesshof_: ok, all in agreement to delay 1 week ?
(15:26:15) ja_: +1
(15:26:20) bettina-h: +1
(15:26:21) paveljanik: +1
(15:26:24) _rene__: s/3.0/beta/
(15:26:27) _rene__: +1
(15:26:35) rtimm: +1
(15:26:57) _rene__: paveljanik: will you be able to QA hyphenexternal by then? It's a simple cws...
(15:27:12) paveljanik: _rene_: no, as I already said, I can't verify it.
(15:27:18) blauwal: +1
(15:27:23) _rene__: of course you can. build it -> builds -> done.
(15:27:24) _Nesshof_: every one read the proposal : http://wiki.services.openoffice.org/wiki/IssueHandling
(15:27:57) _rene__: and check whether hyph_en-US.dic ends up in the installset
(15:29:23) paveljanik: _rene_: it does already, so your cws is useless
(15:29:57) _rene__: this is no, it's not. it fixes a bug
(15:30:23) _rene__: the hyh_en-US.dic currently has no license statement at all
(15:30:32) _rene__: so per copyright law "all rights reserved"
(15:30:43) _rene__: so you're not even allowed to distribute it
(15:30:43) _Nesshof_: any opinion to introduce the new owner unassigned ?
(15:30:52) _rene__: that's what this cws fixes
(15:31:07) _Nesshof_: _rene_, paveljanik can you please clarify offline ?
(15:31:18) _rene__: _Nesshof_: no, I want it here.
(15:31:27) _rene__: _Nesshof_: I want it archived and in the minutes
(15:31:27) paveljanik: _Nesshof_: I'd prefer per-project "unassigned" like issues@project - some projects even use it already.
(15:31:32) stefan_b: _rene_, paveljanik let us talk about that in qa chat.
(15:31:56) paveljanik: general "unassigned" user is a no go IMHO
(15:32:22) _rene__: _Nesshof_: or at least in some archived channel
(15:32:42) _rene__: (then again, any channel I am in is archived anyway on my hd....)
(15:32:56) _Nesshof_: _rene_: please do as suggested in QA, I also am interested in the result
(15:33:27) _Nesshof_: paveljanik: what's the problem with general unassigned user ?
(15:33:48) _Nesshof_: do you prefer a maiiling list instead ?
(15:34:07) _rene__: it'll provoke the "requirements black hole" effect. didn't we have that already a few meetings ago?
(15:34:12) paveljanik: people do not feel the responsibility of it. Yes, project leads could feel responsible, but...
(15:34:34) _Nesshof_: unfortunalty we can't assign issue to a mailing list but only to users
(15:34:56) _rene__: stefan_b: #qa.openoffice.org?
(15:35:30) _rene__: stefan_b: please log it (my client at home is not in the channel, so it doesn't get automatically logged there)
(15:36:53) _Nesshof_: The situation currently is worse:
(15:37:34) _Nesshof_: The is also no responsibilty, only a "seem to be responsibilty" one
(15:37:49) _Nesshof_: my goal is to get more transparent:
(15:38:14) _Nesshof_: if there is no real assignment to resolved that issue, that should be documented in IZ
(15:38:38) ***Fridrich opposes to an institutionalized black-hole
(15:38:44) _Nesshof_: and of course the goal should be that important issue always should have an owner
(15:40:11) _Nesshof_: Fridrich: no it is not a black whole, in doubt the project owner or somebody else from the project will care about those issues if they are really important issues
(15:40:15) Fridrich: why not to call it trash and tell the bug reporter: the issue you just created was thrown into a trash
(15:40:45) _Nesshof_: Fridrich: trash would mean that it is intended not to care about those
(15:41:08) _Nesshof_: unassigned is an ivititation to other to grab that issue and work on it
(15:41:37) _Nesshof_: Fridrich: but you're partly right: in the moment they are traeted like trash and I would like to change that
(15:41:58) _Nesshof_: Fridrich: or do you consider the current situation as good
(15:42:13) _Nesshof_: also the mozilla project made good expereinces with that model
(15:42:38) _rene__: yeah, right
(15:42:42) thorstenziehm: _Fridrich_ : with owner 'unassgin' everybody know than that nobody is working on such issue, currently everybody think that all issues which are assigned to e.g. OS will be fixed by OS. But this isn't possible with more than ... perhaps 1000 issues in sum
(15:42:44) _rene__: because of that they still use myspell
(15:42:47) Fridrich: _Nesshof_: you know as well as I know that entropy is not going to increase without putting an energy
(15:42:49) _rene__: very good experience :P
(15:44:04) Fridrich: adding an institutionalized black-hole is not going to solve the issues, just put them even further off the radars, but I am not anal about it and you do what you want
(15:45:11) _Nesshof_: Fridrich: and what is anyboday doing about the 900 issues lying at os he will never more look at
(15:45:44) _Nesshof_: at least if it is transparent that this issue is currently in a black hole, you can do anything about it
(15:45:58) Fridrich: anyway, do what you want, I cannot really care less
(15:46:24) stefan_b: I already regard all "P4 assigned to Developer XYZ" issues as "in the black hole". But that is because I know about his prios.
(15:47:12) stefan_b: Others do not, believing that "Later" is somewhere within a human life span :-)
(15:49:35) _Nesshof_: Fridrich: I will note this as a -0 ;-)
(15:50:01) _Nesshof_: _rene_: you're still with a -1 ?
(15:50:27) volkerme: I think it will make it more clear which issues are really on schedule. Project leads/owners will take care which work is carried out next, no difference to now, imho. So +1
(15:50:58) paveljanik: volkerme: its clear from the target ;-)
(15:51:16) paveljanik: the real issue is that people can't handle issues.
(15:51:29) thorstenziehm: +1, because all new incoming issues will go throw the QA and perhaps throw developer hand, before it is set to owner 'unassign', so nothing will change in losing important bugs
(15:51:31) _rene__: _Nesshof_: yes. I know how requirements ended up as a black hole even for important stuff
(15:51:55) _rene__: _Nesshof_: I do *NOT* want to have that for other important stuff which bogusly get prioritized as a P4 or so
(15:52:02) _Nesshof_: paveljanik: yes, if your intray is full of hundreds of issues, you will have difficulties to do proper priorization
(15:52:31) _Nesshof_: _rene_: but this will not be addressed via issuezilla
(15:52:47) paveljanik: _Nesshof_: agreed. Then use issues@sw as the default owner instead of mru...
(15:52:53) paveljanik: and not mru
(15:53:01) paveljanik: (mru as an random example)
(15:53:01) _Nesshof_: _rene_ for that problem I would suggest another solutution
(15:53:04) bettina-h: _Nesshof_ MBA is not reachable for giving a state about the requirements having been worked on.
(15:53:07) _rene__: _Nesshof_: where else? If people don't even look at their issues in IZ or bogusly change values?
(15:53:16) _rene__: _Nesshof_: where else should that be handled than where it happens?
(15:53:37) Fridrich: _rene__: you are fighting against a steam-roll, so be careful
(15:53:48) _Nesshof_: lets do a quarterly review of issues per project for people from QA, port, distros, dev, and users list and work on a list of the really important issues
(15:54:08) _Nesshof_: these than will be used by project lead for priorization
(15:54:28) _Nesshof_: or can be reviewed by ESC in case we find no resources for these issues
(15:54:59) _Nesshof_: that wouldd IMHO work better than just letting the priorization of issue to just one delveoper
(15:55:46) _Nesshof_: Fridrich: _rene_: If you stay at your -1, I will leave it unchanged
(15:56:21) _Nesshof_: Fridrich: but I'm fighting for that, because I think that this will lead to a better product
(15:56:45) _Nesshof_: Fridrich: please convince me, that not changing it we improve the situation
(15:56:45) Fridrich: _Nesshof_: I like your confidence :)
(15:56:52) _rene__: _Nesshof_: and I am fighting against that because I do not belive requirements lead to a better product at all
(15:57:02) _rene__: _Nesshof_: and I do not want to have that for other issues, too
(15:57:28) _rene__: _Nesshof_: in contrast, it let important issues for users (who do not use IZ!) unfixed for years
(15:57:40) _Nesshof_: _rene_: but right now it doesn't matter if the owner is requiremnts or bh
(15:58:03) _Nesshof_: _rene_ what we need is to get to a proceeding on how to deal with those issues
(15:58:14) _rene__: correct. it's an alias. *b*lack *h*ole ;-)
(15:58:24) paveljanik: _rene_: ;-)))
(15:58:31) _Nesshof_: _rene_: our problem is that there is no common understanding, what the important issues are
(15:58:47) paveljanik: and who will work on them.
(15:59:28) paveljanik: I think that such issues should be processed, entered e.g. into wiki and marked as THANKS, fixed.
(15:59:37) paveljanik: then we can work on prioritizing them in Wiki.
(15:59:42) bettina-h: _rene_ watch your tone :)
(15:59:57) paveljanik: bettina-h: but its not your fault...
(16:00:35) _Nesshof_: _rene_ bettina and I understand your frustation but please be so constructive to work on how to improve the situation
(16:01:14) _Nesshof_: _rene_ it is not bettina's job to work on the priorization, it's the job of the members of the specific project
(16:01:21) ja_: volkerme is right. Using an unassigned user makes the real assignment of issues more transparent. +1
(16:03:12) _rene__: _Nesshof_: and why do stuff then still go to her and vanish in the black hole?
(16:03:16) _rene__: s/do/does/
(16:03:47) blauwal: Having heard all arguments ... +0.9 ...
(16:03:52) _rene__: _Nesshof_: or are you going to abandon that "requirements" thing?
(16:04:35) _Nesshof_: _rene_ I want to fill the requirements thing with life
(16:05:18) _Nesshof_: _rene_ maybe you're right, we should fill the current black holes with life and should introduce "unassigned" and "requirements" in the second step
(16:05:23) bettina-h: _rene_it does not. I have no problem to repeat it for you. Lists with rfes have been passed over to dev project leads. It depends on their planning. it still does and makes sense. And, also repeated, with those lists I passed over the viewing of rfes.
(16:05:51) _rene__: bettina-h: and I repeat for you: There's still lotsof cruft in "requirements"/bh
(16:06:01) _rene__: bettina-h: NEVER even touched
(16:06:49) bettina-h: That's the reason why we will put them on one owner.
(16:06:59) _rene__: bettina-h: I don't deny *some* things came out of it, yes, sometimes in years something does. that doesn't change rhe overall statistics
(16:07:57) _Nesshof_: _rene_: so you also vote against frequent reviews of those issue in the projects ?
(16:08:11) _rene__: no, I am in favour of that
(16:08:19) _rene__: what I am not in favour is another black hole
(16:08:57) _Nesshof_: can we than agree upon the establishing of those reviews in the main projects and discuss the issue handling then again ?
(16:09:00) thorstenziehm: I do not understand the big problem with the owner 'unasign'. The process to handle defects will not be changed. First a defect goes to a QA person and he decided which owner gets the defect. And in most cases it will be first a developer, who can decide if it is an 'unassign' issue or not.
(16:09:04) _rene__: (or continuing the existing one, how you see it)
(16:09:28) thorstenziehm: features are a different handling since years! and will be a different handling for the next years, I think :-(
(16:10:24) _rene__: thorstenziehm: yeah, right, and often bugs just get declares features bogusly and pushed into said black hole.
(16:10:33) _Nesshof_: ok, we're over our regular time, lets close the meeting for today
(16:10:35) _rene__: thorstenziehm: where they eventually reappear after some light years
(16:11:18) _rene__: thorstenziehm: if we have that "unassigned" thing those also would probably land there :(
(16:11:59) stefan_b: The simple assumption "What gets reported gets adressed too" can never come true. Given the ratio of bug/feature WRITERS and "able developers"... :-(
(16:12:41) stefan_b: Beside this, the IMPORTANCE of a defect of feature is a very personal thing. Sometimes.
(16:13:17) _rene__: yeah, I know, have that problem in the Debian BTS, too
(16:13:21) thorstenziehm: _rene_ : do you have another idea to handle requirement, then propose it. I do not know, how to get as much user experience guys to work on all their issues. For requirements are more people involved beside QA and DEV. That is the big problem.
(16:13:30) mdamboldt: I clearly vote +1 after reading thru the discussion. There are so many benfits!!!
(16:13:36) _rene__: but then again, my "job" is doing the packages, not necessarily upstream development
(16:14:01) thorstenziehm: _rene_ : then I do not understand your problem!
(16:14:26) _rene__: I just know that many (important) *bugs* or *important features* are unprocessed for years
(16:14:41) _rene__: users want/need them, though
(16:14:57) _rene__: or they are security-related (e.g. the current mozilla situation)
(16:15:05) thorstenziehm: then give us a list, and we can work on that list before introducing the 'unassign' thing
(16:15:12) ***ja_ is thinking if storing rfe's within a different system like the ooo wiki or similar would be better because there is no assignment to a user in wiki otoh we have this history of a huge amount of rfe's within IZ. These 'non handled' issues need to be reassigned to a 'virtual user' that clearly states that nobody has picked this rfe for implementation.
(16:15:16) _rene__: in stead, you do usless stuff like PDF import
(16:15:38) _rene__: PDF is a read-only format for exchange.
(16:16:32) _rene__: (and yes, I know users request PDF import, but.....)
(16:17:37) Fridrich: _rene__: and if the user is called jim parkinson :-)
(16:17:46) blauwal: _rene_: other peoples mileage may vary ...
(16:17:53) stefan_b: _rene_, Good news is that beside things you consider important, many UNIMPORTANT things lay around as well :-)
(16:17:59) stefan_b: Who decides what is important? Personal preferences, Corporate interests... There are so many different SYSTEMS involved in the OOo project...
(16:18:29) stefan_b: ..that WHATEVER approach is always "well-worth to talk about it.".
(16:18:47) mdamboldt heißt jetzt mdamboldt_away
(16:19:58) stefan_b: And if the "user" is a developer who can do it, he can implement "almost" whatever he wants.
(16:20:53) stefan_b: In QA, when people nag about "the world soon stops turning if this s not implemented" (Or even worse: "I WILL GO BACK MICROSOFT"...
(16:21:08) stefan_b: ...then we tell them : Bring up a developer and you will get it.
(16:21:41) stefan_b: This tends to silent the outcries in most cases.