| === nixternal_ is now known as nixternal | ||
| Baron1984 | http://ubuntuforums.org/showthread.php?p=5194590#post5194590 | 03:07 |
|---|---|---|
| === dholbach_ is now known as dholbach | ||
| === mdz_ is now known as mdz | ||
| === elkbuntu` is now known as elkbuntu | ||
| === Mamarok_ is now known as Mamarok | ||
| === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Bugs for Hugs Day | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 17 Jun 15:00 UTC: Server Team | 18 Jun 06:00 UTC: Platform Team | 18 Jun 17:00 UTC: QA Team | 18 Jun 20:00 UTC: Xubuntu Community | 19 Jun 13:00 UTC: Desktop Team | ||
| === persia_ is now known as persia | ||
| === asac_ is now known as asac | ||
| === stdin_ is now known as stdin | ||
| === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Bugs for Hugs Day | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 16 Jun 21:00 UTC: MOTU SRU | 17 Jun 15:00 UTC: Server Team | 18 Jun 06:00 UTC: Platform Team | 18 Jun 17:00 UTC: QA Team | 18 Jun 20:00 UTC: Xubuntu Community | ||
| popey | @schedule | 17:42 |
| ubottu | popey: Schedule for Etc/UTC: Current meeting: Bugs for Hugs Day | 16 Jun 21:00: MOTU SRU | 17 Jun 15:00: Server Team | 18 Jun 06:00: Platform Team | 18 Jun 17:00: QA Team | 18 Jun 20:00: Xubuntu Community | 17:42 |
| === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Bugs for Hugs Day | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 16 Jun 21:00 UTC: MOTU SRU | 17 Jun 15:00 UTC: Server Team | 18 Jun 17:00 UTC: QA Team | 18 Jun 20:00 UTC: Xubuntu Community | 18 Jun 22:00 UTC: Platform Team | ||
| === johnc4511 is now known as johnc4510 | ||
| === cropalat is now known as cropalato | ||
| === kirkland` is now known as kirkland | ||
| DktrKranz | !now | 20:55 |
| ubottu | Factoid now not found | 20:55 |
| DktrKranz | mh... | 20:55 |
| lukehasnoname | @now | 20:55 |
| ubottu | lukehasnoname: Current time in Etc/UTC: June 16 2008, 19:55:52 - Current meeting: Bugs for Hugs Day | 20:55 |
| Seveas | DktrKranz, try @now :) | 20:55 |
| DktrKranz | heh, thanks :) | 20:56 |
| lukehasnoname | !@now | 20:56 |
| ubottu | Factoid now not found | 20:56 |
| ScottK | @!now | 20:56 |
| \sh | hmm | 21:20 |
| ScottK | Hello everyone. I have it as time to start the motu-sru meeting. Who is here? | 22:00 |
| === ubottu changed the topic of #ubuntu-meeting to: Current meeting: MOTU SRU | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 17 Jun 15:00 UTC: Server Team | 18 Jun 17:00 UTC: QA Team | 18 Jun 20:00 UTC: Xubuntu Community | 18 Jun 22:00 UTC: Platform Team | ||
| \sh | moins | 22:00 |
| * ogra lurks | 22:01 | |
| * geser watches from the back | 22:01 | |
| TheMuso | Greetings. | 22:01 |
| * DktrKranz is here | 22:01 | |
| ScottK | No jdong or cody-sommerville | 22:02 |
| LaserJock | I'm stopping by and wanted to say a couple things at some point if that's ok | 22:02 |
| ScottK | \sh, DktrKranz, TheMuso: Who is running this meeting? | 22:02 |
| TheMuso | Do we have an agenda? | 22:03 |
| * heno listens in | 22:03 | |
| \sh | aehm.how wanted it? :) | 22:03 |
| ScottK | I think it was get together and make a plan. | 22:03 |
| * sbeattie is also lurking | 22:03 | |
| * ScottK considers 4 of 6 a good quorum and suggests we start. | 22:03 | |
| ScottK | Any objections to letting LaserJock say his piece at the beginning? | 22:04 |
| TheMuso | No. | 22:04 |
| DktrKranz | No. | 22:04 |
| ScottK | LaserJock: Go. | 22:04 |
| \sh | fire away pls :) | 22:04 |
| LaserJock | well, I wanted to just brief people on the script I've been working on | 22:04 |
| LaserJock | in collaboration with Steve Beattie who is the Canonical SRU QA Engineer (I think that's right) | 22:04 |
| LaserJock | http://qa.ubuntuwire.com/sru/ is the current site | 22:05 |
| LaserJock | and I've got an hourly cron job producing 3 pages | 22:05 |
| ScottK | LaserJock: Very good work. Particularly for someone who's taking a break from Ubuntu. | 22:05 |
| ScottK | ;-) | 22:05 |
| LaserJock | well, this is the *only* thing I'm doing *buntu related | 22:06 |
| LaserJock | and it was started before I started my break | 22:06 |
| * ScottK appreciates it. | 22:06 | |
| * DktrKranz even more | 22:06 | |
| * TheMuso also. | 22:06 | |
| ScottK | Much easier to work from than Launchpad. | 22:06 |
| LaserJock | so we'd like to get feedback from you guys as primary users | 22:06 |
| ScottK | I think DktrKranz has been doing the most SRU stuff lately. | 22:07 |
| DktrKranz | I tried to, at least | 22:07 |
| LaserJock | the other thing is that the QA team is working on some specs related to SRU work | 22:07 |
| LaserJock | heno and sbeattie, who are lurking ;-) are working on those specs | 22:07 |
| ScottK | I think before we can know much about that, I think we need to talk about process for Universe. I think it's pretty broken right now. | 22:07 |
| LaserJock | I'd really love to see the MOTU SRU team working well with the QA team to get the consistency and quality of SRUs up | 22:08 |
| heno | agreed | 22:08 |
| ScottK | Perhaps one of you can tell me how we got from the old process to one where only the sru-verification team can verify a Universe SRU? | 22:08 |
| ScottK | I've looked through the MOTU meeting minutes and can't find where that was agreed to. | 22:08 |
| ScottK | heno: Unfortunately I think the current situation really isn't very suitable for Universe. | 22:09 |
| LaserJock | ScottK: that's not actually true at all | 22:09 |
| LaserJock | anybody can verify SRUs | 22:09 |
| ScottK | LaserJock: No they can't. Only sru-verification can tag them verified. | 22:10 |
| LaserJock | the sru-verification team, from what I understand, is there to *ensure* that SRU (Main mostly) are done | 22:10 |
| ScottK | At least per the written process. | 22:10 |
| LaserJock | hmm, that's not how I read it | 22:10 |
| ScottK | Historically that was true, but no longer. | 22:10 |
| heno | depends what you mean by verify -- do the verification work or ack that it was verified correctly | 22:10 |
| heno | the formed should be open to many people | 22:11 |
| heno | *former | 22:11 |
| LaserJock | ScottK: hmm, I can see how you could read it both ways | 22:11 |
| ScottK | LaserJock: https://wiki.ubuntu.com/StableReleaseUpdates very clearly says it's the verification team that tags it done. | 22:11 |
| LaserJock | it's not clear to me | 22:11 |
| LaserJock | I read that that is their function, but not to the exclusion of other people | 22:11 |
| DktrKranz | indeed, I've seen some SRUs (for main too) copied to -updates without a "thumbs up" from sru-verification but after a large testing by users | 22:12 |
| LaserJock | however, the SRU page sometimes gets edited without telling people ;-) | 22:12 |
| ScottK | Yes. This isn't about who tests, but who can say it's good. Although no where on that page does it actually ask for community testing/results. | 22:12 |
| LaserJock | "Verification feedback from bug reporters and subscribers is greatly appreciated" | 22:12 |
| ScottK | OK. | 22:13 |
| LaserJock | though that is very far down the page | 22:13 |
| ScottK | It also says, "The SRU verification team may also discover that your fix is good. They will: - Modify the verification-needed tag to a verification-done tag on the bug report." | 22:13 |
| LaserJock | right | 22:13 |
| ScottK | That's pretty clear and how I understand it's historically been done in Main. | 22:13 |
| LaserJock | which to me doesn't exclude other people from doing so | 22:13 |
| LaserJock | but says that there is a team in place to catch the ones that may fall through the cracks | 22:14 |
| ScottK | That's the only step in the process where it's mentioned | 22:14 |
| DktrKranz | well, sru-verification is not closed, someone can join in (as I did, basically to perform verifications for Universe) | 22:14 |
| ScottK | What it appears to me happened is that motu-sru was told to go document Universe process differences and instead then just dropped them. | 22:15 |
| ScottK | https://wiki.ubuntu.com/MOTU/Meetings/2007-11-23 | 22:15 |
| DktrKranz | but it's a bottleneck, especially for universe | 22:15 |
| LaserJock | in any case, IMO, a sru-verification team is unnecessary if SRU QA is in place | 22:15 |
| ScottK | "The Universe SRU Policy shall be reviewed by the members of ~motu-sru, and the rationale for variations from the policy for Main will be documented." | 22:15 |
| LaserJock | DktrKranz: what is a bottleneck? sru-verification or verification in general? | 22:15 |
| ScottK | No where does it say go drop all the differences. | 22:15 |
| LaserJock | ScottK: no, we decided to drop | 22:16 |
| DktrKranz | LaserJock, having sru-verification to check bugs, IIRC it's just me who perform "regular" scan in universe packages | 22:16 |
| ScottK | Who and when? Such a decision is not documented? | 22:16 |
| ScottK | LaserJock: ^^^ | 22:16 |
| LaserJock | ScottK: the MOTU SRU team did, and it'd only be documented in an IRC log I belive | 22:16 |
| heno | IMO we don't have enough people doing verifications in main _or_ universe so pooling those (testing) teams would be good | 22:16 |
| LaserJock | DktrKranz: well, I totally ignored it | 22:17 |
| ScottK | LaserJock: I don't think the MOTU SRU team had that authority. They changed something that affects all of Universe without asking anyone else. | 22:17 |
| LaserJock | ScottK: umm, yeah, it was our authority | 22:17 |
| ScottK | From where? | 22:17 |
| ScottK | The MOTU Meeting minutes say document the differences, not remove them. | 22:17 |
| LaserJock | by virtue of being the MOTU SRU team | 22:17 |
| DktrKranz | heno, having hug days targeted to SRU verification? | 22:17 |
| heno | DktrKranz: that'd be good! | 22:18 |
| ScottK | LaserJock: I disagree. We've had a policy for quite some time now that process changes get decided by MOTU. | 22:18 |
| LaserJock | sru-verification team should most likely go away | 22:18 |
| LaserJock | ScottK: no, we don't | 22:18 |
| LaserJock | we have a process of letting relevant teams make decisions | 22:18 |
| LaserJock | not nit-picking every single policy change | 22:18 |
| heno | pedro has been doing both bug days and universe verification - he could probably set that up | 22:18 |
| ScottK | I think motu-sru decide how it wants to make it's decisions, but not to change overall process that affects everybody. | 22:18 |
| ScottK | LaserJock: So far we're down to one person focused on Universe who can verify SRUs. That's no nit picking. | 22:19 |
| LaserJock | no, it's not | 22:19 |
| TheMuso | I think this all came out of the idea that we wanted to allign ourselves with the process for main somewhat more, and so it was decided that our process was as close to main as possible. | 22:19 |
| LaserJock | that's utterly untrue | 22:19 |
| LaserJock | *anybody* can verify an SRU | 22:19 |
| ScottK | LaserJock: That's not what the wiki page says. | 22:20 |
| LaserJock | yes it is | 22:20 |
| LaserJock | though I agree that it's unclear | 22:20 |
| LaserJock | but the operational reading of that, IMO, has been that anybody can verify | 22:20 |
| ScottK | LaserJock: OK. I don't think it's at all unclear and I don't think that's what it says. | 22:20 |
| LaserJock | then change it | 22:20 |
| LaserJock | no biggie | 22:21 |
| ScottK | Can anyone mark an SRU verified or just MOTU? | 22:21 |
| LaserJock | *anybody* | 22:21 |
| ScottK | heno: Is it OK per process if I mark a Main SRU with the verification done tag? | 22:21 |
| LaserJock | if it's badly marked MOTU SRU or pitti will pick that up | 22:21 |
| heno | ScottK: if you feel qualified, yes. it still needs to be let through by an archive admin | 22:22 |
| \sh | hmm...anybody with bug powers can mark an SRU verified, even if it's the worst nightmare ? | 22:22 |
| heno | that's where the real gatekeeping happens | 22:23 |
| ScottK | OK. Then I think the wiki page needs a lot of work on that because I don't see that at all as written. | 22:23 |
| heno | \sh: why would you do that just for fun? | 22:23 |
| ScottK | heno: We have people with Launchpad accounts we definitely don't want marking verification done. | 22:24 |
| heno | generally it's only done by the QA in practice | 22:24 |
| sbeattie | note that even if a good verification has been done and tagged, a package may not necessarily get moved into the archive if it's felt that more test usage is needed to catch any regressions. | 22:24 |
| \sh | heno: oh...not just for fun, but because I know at least one person without a clue but thinking he does the right things, even if he didn't ... | 22:24 |
| \sh | heno: and believe me, 1+n with n <3 want to play gatekeeper for crap | 22:24 |
| \sh | archive admins I mean | 22:24 |
| heno | so in MOTU the tag triggers the upload basically? | 22:24 |
| DktrKranz | heno, if a user publishes a clear verification (by attaching screenshots, terminal logs, and so on), I'd say it's ok, taggind and stating "works for me" is somewhat "incomplete" to me | 22:24 |
| LaserJock | ok, hang on a sec | 22:25 |
| LaserJock | 1) I've not seen any badly tags SRUs | 22:25 |
| LaserJock | 2) The MOTU SRU team and the archive team can both easily revert the tag | 22:25 |
| LaserJock | if something looks phony, revert it | 22:26 |
| LaserJock | not a problem | 22:26 |
| ScottK | I don't think anyone is aware they are allowed to tag. I certainly wasn't. | 22:26 |
| heno | yeah, trying to restrict tag use isn't practical | 22:26 |
| ScottK | Unless I misunderstood DktrKranz last week, he joined sru-verification because he thought he had to to tag stuff verified. | 22:26 |
| LaserJock | hmm, I was just doing it, naughty me ;-) | 22:26 |
| \sh | because tasks and tags are two different things...but work tasks we don't have in LP ;) | 22:27 |
| DktrKranz | ScottK, basically yes | 22:27 |
| LaserJock | ok, so my suggestion: | 22:27 |
| LaserJock | 1) edit SRU page to be clear about who can use tags, etc. | 22:27 |
| LaserJock | 2) discuss with Ubuntu SRU and QA team about eliminating sru-verifcation team | 22:27 |
| LaserJock | IMO, we're developing QA tools that should obsolete the sru-verification team | 22:28 |
| ScottK | Makes sense. | 22:28 |
| * DktrKranz agrees | 22:28 | |
| sbeattie | LaserJock: heh, sru-verification is the subscriber that I'm querying off of. | 22:28 |
| DktrKranz | we're moving in the right direction, and we have some good tools already | 22:28 |
| ScottK | While we can't restrict tag use formally, I do think a motu/core-dev ought to sign off on a verification. | 22:29 |
| LaserJock | sbeattie: that's why we need to "discuss" | 22:29 |
| LaserJock | ScottK: well, Ubuntu Archive does that | 22:29 |
| \sh | LaserJock: who is "we"? and which QA team? ubuntuwire or canonical qa? | 22:29 |
| ScottK | LaserJock: The archive admins don't scale very well. I think developers ought to do the initial verification. | 22:29 |
| heno | \sh: there is an Ubuntu QA team too ;) | 22:30 |
| LaserJock | ScottK: well, MOTU SRU can always do it | 22:30 |
| DktrKranz | LaserJock, I think we should take more responsibility and leave a-a just administrative tasks, not verification ones | 22:30 |
| LaserJock | heno: no there isn't, last I looked | 22:30 |
| heno | LaserJock: https://wiki.ubuntu.com/QATeam | 22:30 |
| heno | we have weekly meetings here | 22:30 |
| ScottK | LaserJock: I agree we can do it, but I don't think we should be a choke point on the back end of the process. | 22:31 |
| LaserJock | \sh: sbeattie and I at the moment, hosted on ubuntuwire and eventually on qa.ubuntu.com perhaps | 22:31 |
| LaserJock | heno: if it doesn't have an LP it doesn't exist ;-) | 22:31 |
| LaserJock | ScottK: well, I'd say go easy on it and re-evaluate after a while of processing perhaps. My experience is that people flipping the tag is the least of the problems | 22:31 |
| heno | LaserJock: you can discuss these things with a team of people, not an LP team ;) | 22:32 |
| LaserJock | heno: you don't know who to talk to if there isn't an LP team | 22:32 |
| LaserJock | heno: especially when there *is* a Canonical LP team | 22:32 |
| ScottK | LaserJock: I really don't want to write down a process that says it's OK for someone like Kmos to set an SRU to verified. | 22:33 |
| LaserJock | ScottK: why not? | 22:33 |
| LaserJock | it's easy to change if it's wrong | 22:33 |
| ScottK | Only if the archive-admin catches it. | 22:33 |
| LaserJock | it much easier to let the 99.9% good stuff go through unhindered then block all 100% because of it | 22:33 |
| LaserJock | ScottK: but MOTU SRU is there the whole time | 22:33 |
| * \sh 's wife will kill him... | 22:33 | |
| ScottK | Any SRU has a MOTU that sponsored it, so they should be able to follow-up on the verification. | 22:34 |
| LaserJock | sure | 22:34 |
| LaserJock | I just don't think it needs to be limited | 22:34 |
| LaserJock | but I'm not on the team anymore so ... :-) | 22:34 |
| \sh | ScottK: and the sponsor is mostly not sitting in the SRU team | 22:35 |
| ScottK | Exactly. | 22:35 |
| * ajmitch reads the scrollback & tries to catch up | 22:35 | |
| \sh | ajmitch: simple workflow matters ;) | 22:35 |
| DktrKranz | \sh, when sponsors do sponsoring :) | 22:35 |
| ajmitch | \sh: sure... | 22:36 |
| * ScottK has ~10 minutes until he goes. | 22:36 | |
| LaserJock | overall I think the current process is good | 22:36 |
| LaserJock | but the SRU page needs to be fixed | 22:36 |
| \sh | DktrKranz: if they have the guts to sponsor SRU..which could harm their powers | 22:36 |
| ScottK | I think the current process only worked because virtually no one knew about it. | 22:37 |
| LaserJock | 1) doesn't tell people they need to wait for MOTU SRU ack | 22:37 |
| LaserJock | 2) doesn't describe versions well | 22:37 |
| LaserJock | 3) needs to be more procedural. i.e. answer "I want to submit and SRU, how do I do that?" | 22:37 |
| LaserJock | ScottK: enough people knew about it to create a lot of SRUs | 22:38 |
| LaserJock | and I don't see any reason why it wouldn't scale decently well | 22:38 |
| LaserJock | IMO the biggest missing piece was good tracking, and I think we're going to get that handled much better | 22:38 |
| ScottK | It's the verification part I'm talking about. | 22:39 |
| DktrKranz | it's not that hard to have a SRU in -proposed, the hard part is having it in -updates | 22:39 |
| ScottK | LaserJock: I do think your script is a big step forward. | 22:39 |
| LaserJock | yes, well the nature of many Universe SRUs doesn't lend themselves to ready verification | 22:40 |
| LaserJock | lot's of weird, specific cases where something fails | 22:40 |
| ScottK | DktrKranz: You've the most recent experience with the process. Would you be up for drafting a proposed update to the wiki? | 22:40 |
| slangasek | fwiw, I do share ScottK's concern that ubuntu-archive shouldn't be trying to judge whether the person setting the verification-done tag is qualified to do so | 22:41 |
| DktrKranz | ScottK, if we motu-sru can work on it to have a good candidate, sure | 22:41 |
| ScottK | I'll be glad to help. | 22:41 |
| ScottK | slangasek: Thanks. | 22:41 |
| LaserJock | slangasek: for sure | 22:41 |
| LaserJock | my point is that the subscribers and MOTU SRU all get bugmail | 22:41 |
| ScottK | True. | 22:42 |
| LaserJock | and lastly Ubuntu Archive | 22:42 |
| LaserJock | *somebody* is going to catch a bogus verification change | 22:42 |
| ScottK | Hopefully. | 22:42 |
| slangasek | LaserJock: but not necessarily before the archive admin du jour does the copy to -updates? | 22:42 |
| slangasek | LaserJock: does there need to be a minimum review period between setting the tag and copying the package? | 22:43 |
| LaserJock | no | 22:43 |
| LaserJock | it's whenever pitti gets to it | 22:43 |
| LaserJock | we already have a 7-day aging in -proposed | 22:43 |
| \sh | because pitti doesn't scale.. | 22:43 |
| LaserJock | pitti scales just fine | 22:43 |
| LaserJock | this is really not a bandwith-heavy process | 22:44 |
| LaserJock | it just requires people paying attention to it | 22:44 |
| DktrKranz | pitti is doing a *huge* job, anyone subscribed to sru-verification can confirm | 22:44 |
| slangasek | but the bug may be unverified for 8 days, then be marked "verified" by someone not qualified to know, and the copy happens right after that without review? | 22:44 |
| ScottK | slangasek: Yes. | 22:44 |
| DktrKranz | if we can help it to just doing archive admin task, it will be good | 22:44 |
| slangasek | fwiw, https://wiki.ubuntu.com/ArchiveAdministration#head-18b6747493b60de8de4b4ceaef46ac8e705d3231 suggests that copying packages to -updates is part of the archive team's duties, not just pitti's :) | 22:44 |
| LaserJock | slangasek: yep | 22:44 |
| DktrKranz | it/him | 22:44 |
| ScottK | This is why we really need to minimize what the archive-admins have to face. | 22:45 |
| LaserJock | slangasek: sure, pitti's just the one that does it | 22:45 |
| * ScottK needs to go. | 22:45 | |
| ScottK | Read you all later. | 22:45 |
| LaserJock | the archive-admins don't have much to face | 22:45 |
| LaserJock | there's a lot to do, for sure | 22:45 |
| \sh | ok...i don't get it... | 22:45 |
| LaserJock | but like I said, I've never seen a bogus verification | 22:45 |
| \sh | we have a queue of let's say 7 to 8 days in -proposed | 22:45 |
| lukehasnoname | later ScottK | 22:46 |
| \sh | after that period, someone tags it as "verfied" and A-A of the day just copies it from a to b .. | 22:46 |
| \sh | now, for user x * 1000 this update make things worse | 22:46 |
| \sh | because unknown master of puppets set the flag of "yeah it works"? | 22:46 |
| LaserJock | no | 22:47 |
| LaserJock | it needs to be in -proposed for 7 days *and* have 2 + acks and no -'s | 22:47 |
| LaserJock | and the whole time multiple people are watching it | 22:47 |
| DktrKranz | LaserJock, mh... sometimes not | 22:48 |
| LaserJock | so I'm fairly sure within reason people catch all the problems | 22:48 |
| LaserJock | DktrKranz: that's failure in executing the established process, not failure in the process itself | 22:48 |
| DktrKranz | exactly | 22:48 |
| DktrKranz | we should enforce it | 22:49 |
| === bureflux is now known as afflux | ||
| LaserJock | but MOTU SRUs job is to make sure that the process is exectuted correctly | 22:49 |
| DktrKranz | sometimes motu-sru is hijacked, rare cases, but it happened | 22:50 |
| LaserJock | so, as long as that's happening, and MOTU SRU has the tools it needs then all is good | 22:50 |
| LaserJock | well, then MOTU SRU needs deal with that | 22:50 |
| geser | if a package in the -proposed queue doesn't get confirmed for 7 or 8 days, then either a) there was a communication problem or b) the package is less used | 22:50 |
| LaserJock | well, currently we have form 0 days to 80+ days in -proposed | 22:51 |
| LaserJock | *from | 22:51 |
| DktrKranz | geser, users think about -proposed as a "regular" repository, if a package works, that's enough | 22:51 |
| heno | having many more people use -proposed would help because we would catch the worst breakage -- thousands would be good | 22:51 |
| DktrKranz | my experience is only 5% commented on bugs | 22:51 |
| LaserJock | heno: I disagree | 22:51 |
| slangasek | geser: ehm, do you want me to count the bugs on http://people.ubuntu.com/~ubuntu-archive/pending-sru.html for hardy/universe that haven't bee confirmed yet after > 10 days? | 22:51 |
| LaserJock | heno: I don't think -proposed should be just "enabled" | 22:51 |
| LaserJock | I'd much rather have links to .debs in -proposed | 22:52 |
| heno | if just 1% of those who run the devel releases ran -proposed we'd be doing well | 22:52 |
| DktrKranz | heno, if we suggest to enable it, we should be prepared to another X breakage | 22:52 |
| DktrKranz | and we need to have -proposed-proposed :P | 22:52 |
| TheMuso | I don't think proposed should be enabled by default at all. | 22:52 |
| heno | DktrKranz: people are prepared for that on the devel release | 22:53 |
| LaserJock | I don't think proposed should be enabled for general users, ever | 22:53 |
| heno | TheMuso: no clearly not | 22:53 |
| TheMuso | Particularly since there is the occasional big update, i.e alsa-lib for hardy, that is likely to break things for users, and unless they know how to downgrade again, its somewhat unsafe. | 22:53 |
| geser | slangasek: I just looked at the page. I didn't expect to see that many "main" packages with > 10 days in the queue. | 22:53 |
| sbeattie | LaserJock: I don't think we want all users to run -proposed, but we do want far more power users to use it. | 22:53 |
| heno | obviously, neither should the devel release ... | 22:53 |
| LaserJock | sbeattie: we can't control that | 22:53 |
| slangasek | geser: in the case of hardy/main, many of them are d-i components that couldn't be tested at all until just recently | 22:54 |
| LaserJock | with the devel release, when something breaks we say "well, you were warned, tough luck" | 22:54 |
| LaserJock | with -proposed we lose testers, and reputation because we told people to enable it | 22:54 |
| heno | LaserJock: right we should warn people | 22:54 |
| sbeattie | what heno said. | 22:54 |
| LaserJock | if you turn -proposed into essentially the same as devel then you lose a lot of people | 22:54 |
| heno | but if the same people ran it they would know the risks | 22:55 |
| LaserJock | well, that does make some sense for common Main packages, I admit | 22:55 |
| heno | LaserJock: that's not what we're suggesting | 22:55 |
| LaserJock | but it makes little sense for many Universe packages | 22:55 |
| LaserJock | because you *have* to know the test cases anyway | 22:55 |
| heno | just that people with the same risk awareness run it | 22:55 |
| LaserJock | so you just enable -proposed as a convenience | 22:55 |
| LaserJock | which opens up your testers to potentially hundreds of new packages | 22:56 |
| DktrKranz | when people enable -proposed, they catch almost everything because version is bigger than stable release, if we could tell "ok, this is a proposed upgrade, install it for testing purposes", it should be better | 22:56 |
| LaserJock | when they only want/need to test one or two | 22:56 |
| \sh | heno: you just made a distinction between common world users who just want to use something which is broken, and the hard boiled egg sysadmin who knows what he does... | 22:56 |
| heno | LaserJock: you have to know the test case to verify the fix but not catch severe regressions | 22:56 |
| \sh | heno: regarding d-i examples of slangasek, yes, the sysadmin will do some testing | 22:56 |
| LaserJock | heno: which is really and odd thing | 22:57 |
| LaserJock | we aren't looking for sever regression! | 22:57 |
| \sh | heno: regarding simple tomboy nobody will test this, because they just want to use it. | 22:57 |
| LaserJock | we are wanting to verify that an SRU fixes what it's supposed to fix | 22:57 |
| geser | would a apt pinning like debian backports or debian experimental help so people don't get all -proposed updates automatically? | 22:57 |
| slangasek | there was discussion recently on ubuntu-devel about how best to enable -proposed | 22:57 |
| LaserJock | just enabling -proposed does *nothing* towards that | 22:57 |
| slangasek | I still think that apt pinning + update-manager support is the best solution | 22:57 |
| heno | but the bad regressions are the thing we really worry about, so 'just using' is helpful | 22:57 |
| LaserJock | geser: I would be for that | 22:57 |
| LaserJock | slangasek: agreed | 22:57 |
| LaserJock | heno: again, only for a certain class of SRUs | 22:58 |
| DktrKranz | I agree with slangasek | 22:58 |
| LaserJock | evolution for instance | 22:58 |
| * \sh needs to read the logs tomorrow morning...his wife has a knife in her hand and tells him to shut down the computer, or she will kill him...cu tomorrow folk | 23:00 | |
| LaserJock | \sh: cya | 23:00 |
| LaserJock | ;-) | 23:00 |
| DktrKranz | when doing SRUs, changelogs entries are "incomplete", they do not tell users which issues they are addressing, thus leaving users a doubt if a -proposed update is worth a risk for a regression | 23:00 |
| slangasek | \sh: it's a trick, once the computer's off there are no witnesses | 23:00 |
| LaserJock | lol | 23:00 |
| DktrKranz | if we document better what we are addressing, people looking at -proposed from update-manager will be encouraged to test | 23:01 |
| LaserJock | how concerned are we about major regressions outside of the kernel, X, and perhaps microrelease exception packages? | 23:01 |
| sbeattie | LaserJock: here's an example: gnome-games had fixes for a couple of the solitaire games, but the update that was pulled in also caused glchess to fail to start. | 23:01 |
| sbeattie | LaserJock: we didn't catch it, but upstream did, fortunately before it made it into -updates. | 23:02 |
| LaserJock | sbeattie: right, we *should* catch that | 23:02 |
| sbeattie | Agreed, we should. | 23:02 |
| LaserJock | i.e. mass uploading Gnome into -updates is not high on my recommendation list | 23:02 |
| sbeattie | How, with the resources we have, is the tricky question. | 23:02 |
| LaserJock | well, there are a couple things | 23:03 |
| LaserJock | 1) catch it before we release | 23:03 |
| sbeattie | LaserJock: well, that's unfortunately out of my control, despite my agreement with that. | 23:03 |
| LaserJock | QA before release helps a *ton* when it comes to SRUs | 23:03 |
| sbeattie | LaserJock: point is, if you *only* went to verify the bugfixes (which is what I did), you missed that regression. | 23:03 |
| LaserJock | 2) perhaps use a staging PPA to look for regressions | 23:04 |
| LaserJock | yes, but my point is that is *precisely* why we have our current SRU policy | 23:04 |
| sbeattie | I agree it would be helpful to let people pick and choose which proposed packages they wish to test. | 23:04 |
| sbeattie | But we *also* want to tap our expert users and help us catch regressions in updates to scary packages like dpkg. | 23:05 |
| geser | I see a problem with universe packages that only 5 people have installed and only one finds a SRU worthy bug, how will you find regressions there? | 23:05 |
| slangasek | ask all 5 users to try it, if none find regressions, then by definition they don't exist ;) | 23:06 |
| DktrKranz | sbeattie, what about improving https://wiki.ubuntu.com/QATeam/PerformingSRUVerification and widespread it? | 23:07 |
| sbeattie | DktrKranz: heno and I are trying to do exactly that. | 23:07 |
| DktrKranz | good starting point | 23:08 |
| heno | we'll get there :) | 23:08 |
| === encryptz is now known as atoponce | ||
| heno | LaserJock's tracking pages will help publicize it | 23:08 |
| DktrKranz | as I said before with heno, having targeted days on SRUs will surely help and people could become more interested and willing to help | 23:09 |
| heno | DktrKranz: I'll try to get one set up next week | 23:09 |
| heno | (I'll CC you on an email) | 23:10 |
| DktrKranz | good | 23:11 |
| sbeattie | I wonder if there's a way we can do more targeted notifications, so we can inform those 5 users in geser's example that there's a package in -proposed that we'd like them to help test? | 23:11 |
| LaserJock | publishing an SRU RSS feed with bug URL and test case would be good | 23:13 |
| DktrKranz | we already have instruments (pinning a-la-debian), just lack UI | 23:13 |
| sbeattie | LaserJock: a) heno has asked me to set that up, but b) it needs to be filterable so you don't get spammed with packages you don't use. | 23:14 |
| geser | sbeattie: what about enabling -proposed by default so update-manager sees new packages and can notify the user. But with apt-pinning so they don't get automatically installed / marked for installation. | 23:17 |
| sbeattie | That's a possibility worth exploring. | 23:18 |
| heno | hm, I'm worried about people agreeing to install by accident | 23:19 |
| LaserJock | sbeattie: does it need to be filtered? | 23:19 |
| DktrKranz | I fear users will be tempted to install *everything*, we should document changes better at a first glance, as for security updates, for instance | 23:19 |
| heno | it should be strictly opt-in | 23:20 |
| geser | it would also help if update-manager didn't mark all -proposed packages for upgrade by default. /me has used some time to uncheck all -proposed updates when using update-manager and wanted only some from -proposed (e.g. firefox 3.0) | 23:20 |
| heno | perhaps an installable notification applet | 23:20 |
| LaserJock | well, why not do both ways | 23:20 |
| LaserJock | 1) allow people to just enable -proposed as now, these are the bleeding edgers looking for regressions | 23:21 |
| DktrKranz | update-manager do distinction between security and updates, why not adding a third type "proposed/testing packages" ? | 23:21 |
| LaserJock | 2) in an SRU tracker set up links to .debs for people who are specifically testing a fix | 23:21 |
| geser | isn't there one? I remember seeing one the last time | 23:21 |
| geser | DktrKranz: ^^ | 23:22 |
| * DktrKranz opens hardy VM to check | 23:22 | |
| DktrKranz | just a couple of minutes | 23:22 |
| LaserJock | DktrKranz: it does | 23:22 |
| sbeattie | LaserJock: re filtering: you use $EDITOR; do you wish to be notified when $OTHEREDITOR gets moved into -proposed? | 23:22 |
| LaserJock | sbeattie: maybe, but that's the fun of RSS | 23:23 |
| LaserJock | *we* can't tell what people want | 23:23 |
| LaserJock | so we let them intelligently filter themselves | 23:23 |
| * heno wanders off for the night; it's getting late here | 23:25 | |
| heno | LaserJock: thanks for alerting me to the meeting | 23:25 |
| heno | It's been enjoyable :) | 23:26 |
| LaserJock | heno: thanks for coming | 23:26 |
| DktrKranz | gnight heno, please keep me informed if you plan to do some hug day, I'll be happy to help :) | 23:26 |
| DktrKranz | hah, late :P | 23:26 |
| TheMuso | heh | 23:26 |
| === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Bugs for Hugs Day | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 17 Jun 15:00 UTC: Server Team | 18 Jun 17:00 UTC: QA Team | 18 Jun 20:00 UTC: Xubuntu Community | 18 Jun 22:00 UTC: Platform Team | 19 Jun 13:00 UTC: Desktop Team | ||
| DktrKranz | LaserJock, could you point us to some specs related to QA SRU you talked earlier? | 23:33 |
| sbeattie | https://wiki.ubuntu.com/Testing/fix-validation-tracking is one | 23:35 |
| DktrKranz | mh, it seems we ran out of topics :) | 23:42 |
| DktrKranz | should we summarize and go to bed? | 23:43 |
| LaserJock | DktrKranz: yeah, I thought you already did | 23:43 |
| LaserJock | :-) | 23:43 |
| LaserJock | it seemed to me the broad topics were: | 23:43 |
| LaserJock | 1) "fixing" and clarifying the SRU policy wiki page | 23:44 |
| LaserJock | 2) tracking SRUs and what tools are needed | 23:44 |
| LaserJock | 3) how to get verification done better | 23:44 |
| LaserJock | sound about right? | 23:44 |
| DktrKranz | perfect | 23:44 |
| DktrKranz | I'll give a first try at 1) | 23:46 |
| LaserJock | I'm working some on 2) | 23:46 |
| LaserJock | and I think 3) needs more dialog, IMO | 23:46 |
| DktrKranz | let's do 3) with QA, maybe lurking at their meetings | 23:46 |
| LaserJock | yeah | 23:46 |
| LaserJock | I would encourage MOTU SRU to at least lurk at QA meetings | 23:47 |
| sbeattie | LaserJock: do you think you got sufficient input on 2)? | 23:47 |
| DktrKranz | I will, given that timing permits it | 23:47 |
| LaserJock | because I consider SRU to be a part of QA | 23:47 |
| LaserJock | sbeattie: well, I'm not sure | 23:47 |
| DktrKranz | 17 UTC... bad timing :( | 23:48 |
| DktrKranz | I'm on my way back from office | 23:48 |
| LaserJock | sbeattie: there were'nt any objections though, so that's good | 23:48 |
| sbeattie | LaserJock: just wondering if there were additional ideas (besides an RSS feed some slacker *cough* should set up) to enhance tracking. | 23:49 |
| LaserJock | DktrKranz: can you think of any other "tool" that would help you with SRUs? | 23:50 |
| DktrKranz | LaserJock, nothing right now, I'll think a bit about what we should have | 23:52 |
| LaserJock | DktrKranz: awesome, thanks | 23:52 |
| sbeattie | Was trying to figure out if there was a way to pull out who tagged a fix as verification-done out of launchpad, but I don't think it's possible. Need to dig more. | 23:52 |
| sbeattie | Given the concerns that were raised earlier. | 23:52 |
| DktrKranz | sbeattie, addind to bug history perhaps? | 23:53 |
| DktrKranz | it shouldn't be too difficult | 23:53 |
| DktrKranz | e.g. https://bugs.edge.launchpad.net/ubuntu/hardy/+source/amavisd-new-milter/+bug/226845/+activity | 23:54 |
| ubottu | Launchpad bug 226845 in amavisd-new-milter "amavisd-new-milter: unmet dependencies" [Medium,Fix committed] | 23:54 |
| DktrKranz | if we can have who tagged it in there, could be enough | 23:54 |
| sbeattie | Yeah, I don't see the tag history in there. But that would be the logical place for it to appear. | 23:56 |
| DktrKranz | sbeattie, I'll search through malone bugs to see if there's something similar already and file a new bug otherwise | 23:57 |
| LaserJock | the Launchpad "history" isn't always very complete | 23:57 |
| LaserJock | sbeattie: I honestly think it's a waste of your time and cpu cycles | 23:58 |
| sbeattie | DktrKranz: https://bugs.edge.launchpad.net/malone/+bug/56630 | 23:58 |
| ubottu | Launchpad bug 56630 in malone "Tag changes are not recorded in the activity log" [Medium,Confirmed] | 23:58 |
| DktrKranz | good :) | 23:58 |
| LaserJock | we get bugmail | 23:58 |
| LaserJock | and if somebody is consistently abusing the tag then we'd notice | 23:58 |
| sbeattie | LaserJock: sure, was just thinking if it was easy to pull out, it'd be easy to add as a column to the verification-done table. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!