[02:30] ping hggdh [02:33] nullack, pong [03:16] bdmurray: do you have a list of all the wiki pages you need to update for each new Hug Day? I've come across a couple so far during my w.u.c/Bugs review [03:39] Anyone know if this bug should be closed? https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/269656 [03:39] Launchpad bug 269656 in firefox-3.0 "AN IRRELEVANT LICENSE IS PRESENTED TO YOU FREE-OF-CHARGE ON STARTUP" [High,Confirmed] [03:41] jesseboi: I'd suggest against it. [03:41] Too early? [03:42] I mean it does seem like a moot point now doesn't it?: http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/120b0b6241b74538 [03:53] that is a good point for closing that bug... but i think you'll have to wait until its implemented and set as fix released [03:54] but maybe post that link and set as Fix Committed? [03:54] [03:56] On second thought though... they say "Open source version of FF". So I'm not sure if they mean the unbranded version (IceWeasel) or what? Is there a Closed Source version of Firefox? [03:57] i've always thought FF was open source to Ubuntu (hence why its in ubuntu) [03:57] would break ubuntu promise if it wasn't IMO [03:59] It just seems like they've got their words mixed up. I guess clarity should be sought. [03:59] agreed [03:59] sleep time for me [03:59] nite room [04:00] nite! [04:09] greg-g: just in my head - bugsquad header, desktop team header and bugday [04:13] bdmurray: cool, just making sure/wondering if you wanted one :) [04:14] greg-g: what are you reviewing? [04:15] the changes jorge/pedro made [04:15] pedro sent me an email asking for a review/look over [04:17] bdmurray: I emailed jorge/pedro my comments. Really just one (it was for the Fixing Bugs page, suggested possibly adding a suggestion to look at other bug tackers, especially upstream, for work in progress) [04:17] greg-g: cool, isn't it pretty? ;) [04:18] very, the new images really make a difference :) [04:18] ping bdmurray [04:18] nullack: hi [04:19] bdmurray : evening for you, we can talk later [06:06] * Hobbsee wonders who exactly sent out the hug day mail this time. [06:20] Hobbsee, that would be Dereck (Awsoonn) as always [06:21] nellery: ahh, i'd not seen the irc nick conversion, thanks. [06:21] nellery: can i strangle him? :) [06:21] Hobbsee: heh, why? [06:21] nellery: well, i don't particularly appreciate attempts to get around email filters. [06:22] i have filters for a reason - for whatever reason, i don't want to read the mail. [06:22] why then, must they attempt to get around it? [06:23] was it the topic? [06:23] Fellow Ubuntu Lovers! [06:23] Its me again, giving your spam filters the slip, and you know what that [06:23] means, this week's HUG DAY! [06:24] yeah, they changed the topic, so it wasn't the usual "[B|H]ug Day: " subject line. [06:24] I'm not sure if Dereck has ever used that as his standard topic [06:25] * Hobbsee is fairly sure that it has been like that, as she's not recieved the mails every month, for a few months now. [06:26] I think before it was just "Hug Day!!" [06:26] ah, his last few were "Hug Day!!" [06:26] subject was "Hug Day!!" most of the time [06:26] HA! [06:26] heh [06:26] would adding a * to the beginning of the filter work? [06:27] nellery: well, i was matching on ?ug Day, which worked. [06:27] nellery: yes, it should work. i'm just trying not to filter more widely than i have to [06:27] Hobbsee: but what about Rug Day? You're going to miss Rug day! ;) [06:28] although i'm now trying to filter on any X-Launchpad* header, which i seem to have failed about again [06:28] greg-g: oh dear :P [06:28] greg-g: i'm sure it'll be mentioned on irc. I don't need 5 mails telling me about it :) [06:28] it would probably be 3 ;) [06:28] i used to often get more than 3. [06:28] i'd get k-devel, u-motu, u-devel, u-d-a, and u-bugs, at least. [06:29] yea, it's been narrowed down to -users, -devel-annouce, -bugsquad, and -news-team [06:29] Hobbsee: the mailing list list is good now, right? [06:29] greg-g: for the most part, i don't see it :) [06:29] greg-g: i've had 1 mail so far, and the other will be in u-d-a queue. [06:29] * persia doesn't see any value whatsoever in sending to all of u-m u-d-a, and u-d. Anyone subscribed to u-m and u-d ought also be subscribed to u-d-a [06:30] persia: you'd have thought so. [06:30] nellery: that's much better. [06:30] * persia wants nested inheritance for mailing list subscriptions to enforce that [06:30] persia: now *that* would be cool. [06:32] Hobbsee: Indeed. Something like (((u-d-a) u-d) u-m) and (((u-d-a) u-qa) u-b) would be two I'd like to see, just as a start. [06:32] persia: yeah... [06:32] Probably also (((u-d-a) u-d) u-d-d) [06:32] Hobbsee: So, you're good with list management software, right? [06:33] persia: well, i can use listadmin :P [06:33] Cool, so you can set this up, right? [06:33] * Hobbsee hmmm. [06:33] does mailman even support that currently? [06:34] No idea. I avoid reading mail, let alone administering it [06:35] i've not seen a setting for it [06:35] but mailman is somewhat like launchpad. [06:35] You could add one :) [06:35] full of options, but totally difficult to remember where each option is, or navigate it in a logical sense. [08:11] <\sh> morning [08:12] * thekorn hands \sh some gummi bears and chocolate [08:12] hi \sh ;) [08:13] <\sh> nullack: please don't touch assigned bugs (especially when they are already in progress) anymore...don't nominate development releases on bugs, because development releases are the main tracked one..if the bug report deals also with a problem occuring on other releases, nominate those [08:13] <\sh> nullack: furthermore, please update the bugsquad documentation accordingly...so I don't have to come around and complain again... [08:14] <\sh> nullack: thank you for your cooperation...kind regards, \sh :) [08:18] speaking of assigned bugs...i s hould do that dput merge. [08:19] \sh Which assigned bugs are you referring too? [08:20] <\sh> nullack: bug #246911 [08:20] Launchpad bug 246911 in ia32-libs "[Wishlist] please add libnspr4-0d to ia32-libs" [Wishlist,In progress] https://launchpad.net/bugs/246911 [08:21] \sh I dont see what the issue with nominating for release is [08:21] \sh I spoke with Brian about it, it was accepted the process isnt ideal [08:22] nullack: everything you do causes another mail. [08:22] I dont consider that an issue [08:23] well, that's probably part of your problem. [08:23] <\sh> nullack: the process is totally crap...intrepid e.g. is the development release, any bug filed is being tracked for the latest development release...only when a bug, which is being fixed in the development release is also occuring or happning in other releases older then the development release, you nominate those releases, not the development release.. [08:23] Hobbsee Its not my problem [08:24] <\sh> nullack: furthermore, you deal with bugs already assigned to other people...that's not a good behaviour [08:24] nullack: i think i'll start forwarding all my unwanted bugmail to you then. [08:24] then you can see just how annoying it gets. [08:24] Umm. Just as information perhaps assistive to discussion, the nominations aren't used for tracking the releases by the release managers. There are milestones for that. [08:24] Hobbsee Your being unnecessarily combative [08:24] nullack: as are you, saying that it's OK to spam people. [08:24] or cause useless mails. [08:24] Hobbsee: Grow up please, if your subscribed to it, youll get mail on it [08:25] OK. Stop. This is getting into ad-hominem. [08:25] * Hobbsee sighs, notes code of conduct. [08:25] So, there are two issues at hand. [08:25] Firstly, those working on an issue usually already have most of the information, and don't want additional notifications for things that cause them to have to press extra buttons in LP in order to proceed. [08:26] Secondly, those attempting to track the state of a release want to be able to identify what bugs ought be targetted to a given release. [08:26] Have I represented both desires correctly? [08:26] \sh: ? nullack? Hobbsee ? [08:26] nullack: if you haven't found this out yet, there are implicit subscriptions. So any often these mails, often multiple per bug, are coming from teams, not people - which can't be unsubscribed from. [08:27] nullack: so while your idea should work in theory - unsubscribe if you don't want it - it doesn't work in practice. [08:27] * Hobbsee also notes that you should go somewhere else, if you're wanting to personally attack those who don't agree with you. [08:28] The facts are, the release nomination facility is there [08:28] Hobbsee It's more than once that I see you have a go at people [08:28] persia: yes, reasonably. [08:28] Hobbsee: Like yesterday with your crazy girl comment to the woman who came here [08:28] nullack: leave emma out of this. she's a special case. [08:28] Hobbsee: I know your young, but please try, ok [08:28] \sh: nullack? [08:29] persia: I spoke with Brian about the problems with release nominations for those who cant milestone [08:29] nullack: OK. So? [08:30] nullack: Have I accurately represented your use case? [08:30] persia: Which is what led to the email I sent about how to raise awarness of bugs [08:30] nullack: please do not persist in these personal attacks. [08:30] Hobbsee: Im not attacking, Im giving feedback [08:30] Hobbsee: And Id remind you of the same, thanks [08:30] nullack: telling me that i'm young is not giving feedback. It's discrimination, among other things. [08:31] Hobbsee: nullack: Please concentrate on the substantive issue, rather than the history of the discussion. [08:31] nullack: Have I represented your use case correctly? [08:31] persia No [08:31] nullack: OK. What is your use case? [08:31] persia: Its understood that nomination process is not perfect [08:32] nullack: Sure. What are you trying to accomplish? [08:32] persia: Which is why I developed the email after working with Brian [08:32] persia: A mechanism for bug squadders and not bug controllers to raise awarness [08:32] persia: Because the nomination thing has problems [08:33] OK. To whom is this awareness being raised? [08:33] persia: Brian suggested to send it to the QA and Bug Squad mailing lists [08:33] persia: Which I did [08:33] \sh I would appreciate you engaging me in a better way next time [08:34] \sh: Im not your wipping toy to instruct to do doco [08:34] nullack: Sure. I'm still not understanding what you are trying to accomplish. I suspect there is a solution that meets the needs of all parties to this discussion, but I need to know the goal in order to make a suggestion. [08:34] nullack: Would it be fair to say that you're after a button to press which says "I believe that fixing this bug should be a priority for Intrepid"? [08:34] Yes Chris, but thats a longer term issue that as Brian said, isnt there now [08:35] nullack: Is that an accurate represenation of your goal, or is there an intermediate goal you are seeking first? [08:35] Which is why I sent out the email on raising bug awarness [08:35] persia : Its longer term cos it requires dev effort to implement, and Brian raised concerns about noise in such a facility [08:36] OK. [08:36] \sh: Is it the noise that is causing your complaint? [08:36] persia : so the process I emailed about was seen as a solution till then [08:37] nullack: either way, an assigned, and in-progress or above bug should also remain the property of whoever it's assigned to, as they're cleraly dealing with it. [08:37] Hobbsee: Is it the noise that is causing your defence of \sh's complaint? [08:37] Hobbsee: I dont agree [08:37] nullack: which your mail doesn't contain - is it possible for you to add that to your mails? [08:38] Hobbsee: No, because I dont agree [08:38] persia: yes. [08:38] nullack: why? [08:38] OK. [08:38] Hobbsee: Because the issue of whos working on it is not the issue at hand in this case [08:38] nullack: Is a list of these nominated-for-intrepid-but-not-approved bugs generated anywhere, or used for anything? [08:38] nullack: let me put it another way - if someone's working on it already, then why does it need the bugsquad to put it up as a bug that needs to be fixed before release? [08:38] Hobbsee: The process need is about being able to get it onto the release teams IRC meeting for those that arent in bug control [08:39] nullack: Ah. That's entirely different. Does the release team have a procedure that looks at bugs in this state? [08:39] persia: The release team has a number of processes that can manage the timing issues with it [08:40] persia: To give better history [08:40] * persia notices that Hobbsee is a member of ubuntu-release [08:40] persia: I sent a contribution to the QA Team's status report for the release team meeting [08:40] nullack: if someone's already working on it, then it's *more* than likely that it is going to be finished by the release. Also, remember that the developers are *also* QA people, and have thus already made the judgement call about whether it should be on the release team radar. [08:40] nullack: OK. I can see that. I think the process needs wider discussion. [08:40] persia: And the feedback was, thats some good stuff and its scary we didnt do this sooner [08:40] nullack: why should the bugsquad duplicate effort here, and step on toes of other qa members? [08:41] I think I share Brian's concern about the noise, especially with developer complaints. [08:41] persia: So the obvious question then becomes, whats the optimal way to do so, which I asked, got no response, so I asked Brian directly [08:41] Essentially, if we generate a QA process that annoys developers, we'll have fewer developers. [08:41] persia++, and this seems to be happening more and more frequently. [08:41] nullack: Right. So would it not be possible for those not in bug control to ask those in bug control to make the adjustment in this channel? [08:41] persia: Perhaps then Developers need to consider their attitude with these things [08:42] nullack: We have all sorts of people. I don't think there is a general answer for attitudes for anyone. [08:42] Hobbsee: Your point doesnt change the situation [08:42] Since most people are volunteers, we need to make it enjoyable, or we'll not have the volunteers. [08:42] nullack: why not? [08:42] Hobbsee: Its not about the developers, thats why [08:43] nullack: it's not solely about the qa team, either. [08:43] Hobbsee: No, its also about what gets released [08:43] nullack: I disagree. Much of our infrastructure, is all about helping the developers. [08:43] ultimately, the bugs are waiting there for the developers to fix, and the release to happen as a result. [08:43] RAOF: Thats fine and I support helping Developers ofcourse [08:44] <\sh> persia: it's the noise..and the disturbance of my own bugwork...I don't touch other bugs when they are assigned to someone (status wise) and I tend to think that other people don't touch my bugs while I'm working on it (status wise) [08:44] The issue at hand is that not all bugs that should be are being recognised for release nomination or milestoning [08:44] * persia asserts the lack of useful means to distinguish members of the development team from members of the QA teams. [08:44] \sh You dont own the bug, your working on it, its different [08:45] nullack: do you think that all bugs, whether main or universe, should be on the ubuntu-release radar, if they're to be fixed before release? [08:45] And I object with the notion that working on release issues is "noise" [08:45] \sh: OK. That makes sense. Might there be an exception for release targeting? [08:45] Its insulting [08:45] nullack: Working on release issues *isn't* noise. Generating unwanted bugmail may be perceived as noise. [08:45] That's why we need a procedure that works for everyone. [08:46] What Brian meant by noise is different [08:46] <\sh> persia: if it's an RC, yes...but universepackage bugs are mostly not RC candidates (forgetting the MIRs) [08:46] nullack: What do you think Brian meant? [08:46] Its not a developers right to claim ownership of a bug if they are assigned to it, ask no one else to touch it and then direct me to do doco [08:47] Thats just plain wrong [08:47] maybe not the last part. [08:47] but the first part - why not? [08:47] they're the one fixing it? it finishes with them. [08:47] \sh: As a participant in *two* universe-based flavours of Ubuntu, I'm not sure that's true, and further think a lot of universe packages are important, but I see what you are saying. [08:47] Because the world isnt centered on a developers perception of what needs to be done [08:47] Development isnt the only "work" [08:48] It needs to be build, deployed, tested [08:48] nullack: no, but we do need ways of making sure 2 people don't work on the same bug, and therefore one spending useless energy on it, at the same time [08:48] ie, if both come up with a fix. [08:48] <\sh> persia: I don't say, universe is not important...but having a bug which is a blocker to a release, I tend to agree, that a status change is sane, regarding the fact, that most valuable devs of core are doing this assignment [08:48] Certainly. It just needs a procedure that works for developers, testers, etc. [08:48] Hobbsee: Agreed [08:48] currently, assigning is done for that. [08:48] thus, the "please don't touch it, i'm aware of it" is the protocol used, in current ubuntu. [08:48] And the final part of the puzzle thats most important is the user experience [08:49] \sh: OK. So your assertion is that release-tracking ought be done by release management and flavour developers, and not the QA teams? [08:49] And often there is bugs with serious user experience problems not on the release teams radar and not on the qa status report [08:49] Since the nominate for release function isnt working too well [08:49] nullack: so, in your proposals, how many bugs would you be expecting to have resolved at the end of each milestone, for the release team to deal with? [08:50] What Brian and I worked on was where bug squadders would raise it on the list [08:50] <\sh> persia: yes...because release managers and flavour relengs do know more about the underlaying problems then QA...(that's why in most companies QA is a _testing_ department and not a department which decides what's RC critical and what not) [08:50] just for a ballpark figure, so that the release team can actually check if that's something it wants to do, or not. [08:50] nullack: Ah, so the procedure would be to raise the bugs on the mailing list? [08:50] there is too many bugs to do that [08:50] \sh: What about those who just do QA? How about the release testers who rigourously check each daily build? [08:50] seb128: that would have been my thought, yes. [08:50] the reason why the nomination doesn't work correctly is that hundred of bugs are nominated [08:51] if hundred of mails are sent on the list that will not scale either [08:51] seb128: So you think the issue is that we have more nominations than developer time to fix them? [08:51] persia: clearly [08:51] seb128 you have to consider that launchpad is pretty public but the member of bug squad is not [08:51] persia: I'd agree with that, with my RM hat on. [08:51] and people tend to nominate their pet bugs because they think their usecase is important for everybody [08:51] persia: many things get dropped from the milestone lists, or deferred, just because it won't get fixed. [08:52] (in time) [08:52] nullack: Given seb128's concern (and he's one of the *most* active developers for Ubuntu Desktop), how do you think we can increase developer time to scale to the identified issues? [08:52] persia Your getting into bifurcation [08:52] s/RM/Release Team/, etc. [08:52] <\sh> persia: well, daily cd testing doesn't mean finding RC bugs..but it can be, that a bug which is found by some qa people is RC critical...and yes, a QA role person can also have RELENGS role position...but we should definitly make a difference [08:52] persia Those issues are release management issues [08:52] persia What the testers are saying is we need to get better reports to the release management meeting [08:53] persia And then the meeting can debate priorities and allocation of resources [08:53] nullack: then i hope they'll be more, but filtered. [08:53] nullack: OK. I'm not sure how it helps release management if we don't have enough developers, but I can see prioritisation. [08:53] nullack: a lot of those meetings don't include universe-based stuff, though. [08:53] nullack: mainly because the universe people don't tend to be on the payroll, and so demanding they get it fixed, on time, isn't going to work. [08:54] * persia needs to run, and is already late. Apologies to all: this is a very interesting discussion, and I firmly believe there is a solution that meets everyone's goals (but we're not there yet) [08:54] (i understand that you probably haven't had to deal with the above situation before) [08:54] Hobbsee: Thats a release management issue [08:54] * persia notes that many main people are not on any payroll for their work in Ubuntu as well, and really leaves [08:54] Hobbsee: If they decide to priority something in MOTU, they need to figure out how to do that [08:54] persia: oh, sure, but the people who are in that meeting tend to be. [08:55] I joined in the middle of the discussion but I'm not sure why you want an another workflow [08:55] nullack: you appear to want to give the release teams more work, without asking if they actually want it. [08:55] what is wrong in the current nominations one? [08:55] Hobbsee: Many of them, but not all. [08:55] * persia really leaves [08:55] seb128: stuff doesn't get fixed from it [08:55] persia: yes, hense the "tends to be" :) [08:55] that's a manpower issue, changing the workflow will not make a difference [08:55] *hence. [08:55] seb128 It will [08:56] seb128 If the release management meeting raises a critical user experience problem [08:56] seb128 Release management milestones will be set [08:56] those guys should go on a regular basis through the nomination lists [08:56] * Hobbsee notes this tends to happen already. [08:56] if they don't that's the issue [08:57] seb128 the problem is bug control cant see them all [08:57] I'll talk to slangasek when he's around [08:57] it's his job to look at those lists [08:57] seb128 and when people nominate for release some others gets uneccasirly agitated like \sh [08:57] seb128: what brought this up was the fact that lots of developers are getting "needless" bugmail from all the switches being pressed, and the fact that assigned, in progress bugs, are then being filled with by the QA team - and they view this as stepping on toes. [08:57] s/filled/fiddled/ [08:57] that's a launchpad issue [08:57] (if that helps for context) [08:57] seb128: sure, but we need to work around LP [08:58] seb128 Its not about the devs and their toes, I have tremendous respect for all the devs [08:58] Hobbsee: launchpad doesn't bug mail on nominations [08:58] seb128 The issue is user experience problems need to have a way of being flagged as hey, this needs release management attention [08:58] use tagging? [08:59] seb128 Well, you could imagine some more sensitive devs might see that as fiddling as well [08:59] <\sh> nullack: first, I got mail, second, I have to click on some strange "approve/decline" links just to say "no" because it's useless, because devel release bug tracking is already done without nominating...only when bugs are also in former releases the nomination makes sense, so that assigned dev knows, he needs to work on the very same package in older archives, too... [08:59] that's not true [08:59] <\sh> nullack: furthermore, you don't have the rights for nominating, so someone else needs to work to resolve those nominations [08:59] \sh Perhaps you should focus on helping improve the process isnt of getting up me [08:59] you should read the current processes, nominations are used for bug which should be fixed in the current cycle too [09:00] \sh I do have rights for nominating and I did [09:00] any bug which is nominated and has a milestone is something to fix for this milestone [09:00] seb128: oh, i thought it did. It certainly does for everything else - which I usually see done in tandem. [09:00] <\sh> seb128: that's why on lp its written: the actual status and bug info is tracked on the mainline, which means: devel release of today [09:00] <\sh> seb128: and yes, it could be, that LP is wrong here, then we need to fix LP [09:00] you can nominate a bug for intrepid [09:00] seb128: ew, tags :) [09:00] seb128 Thats right [09:00] and that's how slangasek tracks the intrepid targets for example [09:01] seb128: they *also* create a whole stack of bugmail :) [09:01] <\sh> nullack: you don't have the rights...you just clicked, but approval is coming from someone else... [09:01] \sh Yes, the release management group, which is where it should be [09:01] \sh The objective is for testers to be able to flag this stuff === BugMaN1 is now known as BugMaN [09:01] \sh Honestly, its not about your work on the bug, its a release issue [09:01] <\sh> nullack: no...the developer who is working on it, or the security team, or motu-release, or just me can approve or decline...many people can, because they have to [09:02] \sh I understand, but what your really doing in that context is release management not development, if you see my point [09:03] <\sh> nullack: what in your eyes is Release critical on ia32-libs? [09:03] <\sh> nullack: what is release critical on a buggy flashplayer10 ? [09:03] \sh The flash user experience on 64 bit systems is release critical [09:03] <\sh> nullack: did you read the bugreport really well? [09:03] \sh Did you? [09:04] nullack: have you asked the release managers what sort of information they want, before putting everything that you view is important, no matter what the section, on their radar? [09:04] <\sh> nullack: because what's written there is: "Flashplayer10 needs some add libs", I'm the reporter of the initial bug about FMS (both adobe) ... did you ever thought about "oh this guy knows something about that?" [09:04] nullack: and if not, should you? [09:04] those flash issues are on their list [09:04] Hobbsee: Ive allready explained what I asked and then I what I did from there [09:05] \sh Im warning you to pull your head in [09:05] \sh Youve already insulted me enough here [09:05] <\sh> just on a sidenote: "flashplayer10 is just so buggy, that some really hardcore flex apps are not running correctly" [09:05] nullack: you said you asked brian. i asked if you asked the *release team*. Brian, afaik, is not the release team. [09:05] could everybody calm down and stay correct? [09:07] having a decent way to track bugs that should be considered is a valid request [09:07] <\sh> nullack: If I would start insulting you, that would sound different...really... [09:07] <\sh> anyways, it's not going to work... [09:07] seb128: but not 10 billion of them. [09:07] the current system uses launchpad nominations [09:07] and I don't think changing the workflow is the solution there [09:08] we just need to figure what doesn't work in the current way and to fix that rather than design a new one [09:09] seb128 Brians feeling was that in the short term if testing folk discussed it on the bug squad list thats atleast treating the issue [09:09] seb128 Which is what I shared on the squad list and qa list [09:09] nullack: i don't think anyone's objecting to that. [09:09] would be nice to have concrete cases of where the current workflow didn't work to understand what are the issues [09:09] and yes, testing guys can use the list [09:10] nullack: however, that doesn't involve actually touching the bugs, which, afaik, is what \sh and others are complaining about. [09:10] Hobbsee: Look at the bug history [09:10] but the recommendation should not be that any user finding a bug which might be to consider should mail the list because that will not scale [09:10] Hobbsee: I nominated it for release under the old process which Sebastien thinks is ok [09:10] seb128 Its not any user [09:10] seb128: that was my other concern. [09:11] serb128 Were talking about bug squadders [09:11] not only it's ok, but that's the documented way to nominate issues and the one which is used to track those by the current teams [09:11] seb128 Right, so why I am copping grief from \sh about it then? [09:12] seb128 Especially when Ive gone to the extra effort of discussing how to improve the process with Brian and bug squadders [09:12] just ignore him, he has not been constructive in this discussion and seems to doesn't know the way ubuntu works currently [09:14] Everyone, can I honestly say, were all trying our best I know that [09:14] Maybe the problem is the current process isnt well documented or understood [09:14] And the talk about changing it might be confusing it further [09:14] seb128: even any bug squad member highlighting multiple bugs won't scale, will it?. [09:15] I'm not sure to understand what issue mailing the bugsquad list should fix [09:15] it's probably be fine to discuss whether a bug should be nominated or not when unsure [09:15] but that should not be the standard way to discuss any bug [09:16] seb128 : The idea was to ask people to raise a bug they found on the bug squad list to raise awareness of it [09:16] * Hobbsee wishes nullack would actually ask her questions. [09:16] er, answer [09:16] <\sh> anyways [09:16] but they can suggest it for nomination [09:16] why wouldn't that work correctly? [09:17] Hobbsee: Which question Sarah? I did not see it I thought the last one you asked was to Seb [09:17] what are we suggesting for nomination? :) [09:17] [17:49] nullack: so, in your proposals, how many bugs would you be expecting to have resolved at the end of each milestone, for the release team to deal with? [09:17] slangasek: some people seem to think that the current process to nominate bugs doesn't work correctly [09:17] slangasek: too many of those are being ignored [09:18] Hobbsee: I dont know, honestly, and thats not the issue. The issue is how to get it to the release team. I understand there will be further issues but Im focused on this one first [09:18] well, I agree that it doesn't work correctly [09:18] slangasek: every bug that the QA team thinks is a critical bug from a users POV (including things such as nonfree flash on amd64, it seems), even if it's already assigned and in progress, and someone is clearly dealing with it. [09:18] because it's a one-shot deal in launchpad; I've complained to kiko before about this workflow being a problem [09:18] slangasek: aiui, anyway. [09:18] slangasek: and they are trying to suggest alternative workflow using the bugsquad mailing list to raise attention on some issues [09:19] slangasek: my impression was that we are not active enough on accepting or declining things which are suggested for nominations [09:19] mvo: landscape-common needs to be held back its broken [09:19] s/needs/should [09:19] gnomefreak: how broken? [09:19] gnomefreak: broken in what way? is there a bugnumber? [09:19] nullack: i'm sorry, but it *is* a valid issue that you need to address here. If you want to get stuff changed, and significantly add to a team's workload, then it would be a *very* wise idea to estimate the impact, and check that it's something that they want, rahter than trying to blindly change things. [09:19] seb128: DOESNT INSTALL [09:19] gnomefreak: it's in binary new no? [09:19] seb128: yes, because once a nomination has been declined (which is the appropriate workflow for any nominated bug that's still incomplete or new), it can't be re-nominated [09:19] Errors were encountered while processing: /var/cache/apt/archives/landscape-common_1.0.18-0ubuntu2_all.deb [09:20] Hobbsee: I guess thats where I differ to your opinion [09:20] Hobbsee: I see the problem right now as being a test issue [09:20] gnomefreak: copying the actual error would be useful [09:21] nullack: it would be great to make the testing better, I agree. However, are you just pushing the bottleneck further up? [09:21] Hobbsee: Lets try not to be defeatist eh :) [09:21] seb128: mvo http://pastebin.mozilla.org/538170 is full [09:22] "trying to overwrite `/usr/lib/python2.5/site-packages/landscape/patch.py', which is also in package landscape-client" [09:22] is the error [09:22] lack of correct replaces [09:22] strange its held back but tryies to install [09:22] seb128: if that ws it --force-overwrite would work [09:22] seb128 You can reinstall the landscape client and it works but it then complains about no setup as per my bug comment [09:22] nullack: and I can see your point - that it's not your problem if it's above the QA team - it's for the release team to deal with. But, if you want to stay in good standing with the release team, you'll need to actually work with them, rather than throwing information in their faces, and flooding their processes. [09:23] nullack: no, i'm being a realist, having worn a lot of the hats before. [09:23] gnomefreak: already fixed in the -0ubuntu3 upload [09:23] slangasek: there is no such upload? [09:23] hmmmmm it hasnt hit archives than [09:23] ps [09:23] Hobbsee: I would expect the release team to be less alarmist and to discuss things in an open and friendly way. Process improvement should be a continual thing [09:23] there is [09:23] seb128: of landscape-client? theer is [09:23] slangasek: ignore my comment ;-) [09:23] and it's in NEW. Hmm! [09:23] yep [09:24] slangasek: I was just looking at that [09:24] seb128: shall I let you keep looking? [09:24] nullack: I have been. I've been asking stuff like "how much change do you think will be made here?", so that hte release team can have a fair idea of the impact, and so can then deal with how to react as a result, but you keep telling me it's a non-issue, and not your problem. [09:24] slangasek: I've a command line ready to accept it if you are not faster :-p [09:25] seb128: go ahead :) [09:25] Hobbsee: I believe I said I dont know what the impact will be, I dont see how I can be more clear than that [09:25] slangasek: accepted to main [09:25] nullack: you can't estimate it, based on how many bugs you'd milestone/etc if that were the process? Aren't you dealing with a lot of these bugs, and trying to push them higher now? [09:27] Hobbsee: Theres alot of bugs Im not involved with, any one person wont be involved with any significant portion of the total number. Its huge. And, we dont know yet how well the raising bug awareness issue will go within the bug squad team so its too early to give any meaningul numbers to the release team [09:27] nullack: right, so you can't really even give a ballpark (ie, how many 0's would follow the number). Pity. [09:27] I'm going to ask again, but what is that you are trying to fix exactly? [09:28] Hobbsee: I dont believe anyone could give you a meaningul number, But how about I monitor it, and let you know ok? :) [09:28] nullack: that'd be cool. [09:28] Hobbsee: ok :) [09:28] nullack: ultimately, i really only want to know the power of 10 of bugs it would be, or so [09:28] * slangasek squints at bug #246141, which has been confirmed, nominated for intrepid, and... never assigned to the right package. [09:29] Launchpad bug 246141 in linux-meta "no support for realtek rtl8187se" [High,Confirmed] https://launchpad.net/bugs/246141 [09:29] * Hobbsee would tentatively guess 10's or low 100's. [09:29] seb128 : The nominate for release process is not optimal [09:29] right, slangasek confirming he agrees on that [09:30] seb128 : When I discussed it with Brian it come out that he felt it better for now too [09:30] seb128 : Email the squad list to raise awareness of any big user issues that should be targeted for a specific release target [09:30] seb128 : that way provide visibility atleast [09:31] why can't you use the standard nomination? [09:31] <\sh> slangasek: bug #196526 is really important, never nominated, nor touched and they are annoying, because not only ~ubuntu-drivers can approve/decline them [09:31] Launchpad bug 196526 in python2.5 "ubuntu's platform.dist() always returns debian lenny/sid " [Low,Triaged] https://launchpad.net/bugs/196526 [09:31] \sh: "and they are annoying"? what "they"? [09:31] seb128 : Because it was seen that the lp nominate was too noisy because many people with only a casual interest in stuff were marking it up [09:32] <\sh> slangasek: nominations (when it's not been a security bug or an -update bug) [09:32] seb128 : By limiting it to the bug squad list, it was seen as a less noisy solution [09:32] that's not a good answer [09:32] seb128 : Its an interim [09:32] nominations are the documented way to list those issues [09:32] seb128 Its not supposed to be final [09:32] people complaining should raise the issue and open launchpad bugs about their annoyances [09:33] or set up mail filtering [09:33] seb128 Well it seems easier to abuse the testers [09:33]