| nigelbabu | 82, yaay! | 00:07 |
|---|---|---|
| nigelbabu | nhandler: you're on in 1 hour | 00:07 |
| nhandler | nigelbabu: Aren't I going on 01:00 UTC, which is 1.75 hours from how | 00:20 |
| nigelbabu | nhandler: wht is utc time now? | 00:21 |
| nhandler | nigelbabu: 23:21 | 00:21 |
| nigelbabu | nhandler: oh no, can you start frm next session, i need to get to work | 00:21 |
| ajmitch | nigelbabu: wouldn't you need sleep or something first? :) | 00:22 |
| nigelbabu | ajmitch: sleep is over. 2200 to 0230 | 00:22 |
| nhandler | nigelbabu: I can try, but I'll probably be eating dinner in the middle | 00:22 |
| nigelbabu | nhandler: *grin* ajmitch will be around :) | 00:23 |
| * ajmitch may not be around | 00:23 | |
| ajmitch | that'll be when I head out for lunch (12:00 here) | 00:23 |
| nigelbabu | 83 bugs more! | 00:24 |
| nhandler | Somehow we'll cover any questions that get asked during that hour, but they might need to wait for answers | 00:24 |
| maco | nigelbabu: im helping a guy fix his centos | 00:26 |
| maco | im failing :( | 00:26 |
| maco | im *trying* to help him fix his centos | 00:26 |
| maco | but its a yum b0rk not a things-that-exist-here-too b0rk | 00:26 |
| maco | akk: i think the list is "stuff ubuntu-reviewers is subscribed to" and that the magic date is simply the date from which the script that autosubscribes the team was set to run | 00:27 |
| nigelbabu | maco: lol, ok. we're having a gap in coverage due to my excellent math skills thinking gmt = utc | 00:28 |
| maco | ah daylight savings got ya? | 00:30 |
| nigelbabu | i think so, why is there no desktop tool for time conversion? | 00:31 |
| maco | date -u | 00:31 |
| yofel | @now | 00:31 |
| yofel | :( | 00:31 |
| maco | nigelbabu: the date command accepts format strings, such as %Z for the timezone name to be listed | 00:32 |
| nigelbabu | maco: ok, so basically its always -4:30 for me | 00:33 |
| nigelbabu | well, I'm always at +4:30 from UTC | 00:33 |
| maco | right, whereas gmt moves about for british summer time | 00:33 |
| nigelbabu | yeah, I usually keep a gmt thingie on my clock and forgot it moved around | 00:34 |
| nigelbabu | can someone review 3 more bugs? | 00:36 |
| nigelbabu | so we can get to 70? | 00:36 |
| nigelbabu | at least I want to make sure we reach the 40s for this patch day :) | 00:37 |
| nigelbabu | persia: we need some system to deal with packages that are ubuntu-specific | 00:38 |
| nigelbabu | also, can someone test and review bug 564698 | 00:40 |
| ubot3 | Malone bug 564698 in util-linux "lscpu command shows "???" when messages are translated in Japanese" [Undecided,New] https://launchpad.net/bugs/564698 | 00:40 |
| ajmitch | persia would be good to look at that :) | 00:40 |
| nigelbabu | yes, hopefully he will when he sees it :) | 00:40 |
| nigelbabu | maco: can take a look at the k-reltaed packages in the list? | 00:41 |
| nigelbabu | wow, I spell *bad* | 00:41 |
| nigelbabu | ajmitch: wise to defer eucalyptus to server team? | 00:42 |
| ajmitch | yes | 00:42 |
| nigelbabu | just unsubscribe then? | 00:42 |
| ajmitch | I assume so, you're the boss ;) | 00:42 |
| nigelbabu | lol, no I'm not :) | 00:43 |
| ajmitch | but that bug looks very actively looked at | 00:43 |
| nigelbabu | yeah, its assigned too | 00:43 |
| nigelbabu | ok, so I'm off, someone please cover and answer questions | 00:46 |
| nigelbabu | we're at 82 | 00:46 |
| nigelbabu | bug 569442 | 00:47 |
| ubot3 | Malone bug 569442 in ttf-wqy-zenhei "After upgradeing to Lucid, unexpectedly-using bitmap font in Japanese Environment (upgrading regression)" [Undecided,New] https://launchpad.net/bugs/569442 | 00:47 |
| * nigelbabu points to maco ^ | 00:47 | |
| maco | ew yuck. bitmapped japanese. that has to be hard to read | 00:48 |
| nigelbabu | bitmapped chineese actually I think | 00:48 |
| nigelbabu | check out the bug | 00:48 |
| maco | japanese uses chinese characters | 00:49 |
| Paddy_NI | Hey maco | 00:49 |
| nigelbabu | maco: o_0 thats news to me | 01:12 |
| maco | nigelbabu: japanese didnt have a written language. chinese monks gave them literacy | 01:16 |
| nigelbabu | maco: wow | 01:20 |
| ajmitch | almost down to 1 page of stuff to look at | 01:24 |
| nigelbabu | YAAY! We have breached 80 | 01:25 |
| nigelbabu | Only 79 more bugs to look at! | 01:25 |
| maco | Paddy_NI: https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide | 01:47 |
| Paddy_NI | thanks maco I was wondering what I should be doing.. perhaps reading the topic :) | 01:48 |
| maco | um hmmm | 01:59 |
| maco | so one of the wiki pages links to bugs that have been marked accepted upstream or accepted debian | 01:59 |
| maco | maybe this query should filter out "fix committed" bugs though, since if its committed in ubuntu, its just waiting for a freeze to be lifted, which most people cant really do anything about | 02:00 |
| nhandler | So I guess I'm up now | 02:00 |
| nhandler | Nice and quiet now | 02:23 |
| * ajmitch is working... | 02:25 | |
| nhandler | Hmm...Does anyone remember what bugs the script looks for to subscribe the reviewers team to? | 02:41 |
| persia | nhandler: I believe the script looks for any bugs with attached patches that have the patch added since a certain date and aren't subscribed to a blacklist of teams and aren't bugs against a blacklist of packages. | 04:49 |
| nhandler | persia: Do you know what statuses it looks at? | 04:50 |
| persia | I believe all open statuses (not invalid, won't fix, fix released). | 04:51 |
| nhandler | Ok, thanks | 04:51 |
| persia | The interesting question is: if a bug is Fix Committed and has a patch attached, is this confusion on the part of the person setting the status? | 04:51 |
| maco | persia: bdrung told me today that if i upload a package but its sitting in the queue waiting to be approved, then its fix committed | 04:54 |
| maco | for -proposed stuff and during freezes | 04:54 |
| persia | I guess, but why should it both have an attached patch and *not* be subscribed to a team? | 04:55 |
| persia | I think the majority of cases are mistakes: the rare case where it's correct, we can just unsubscribe the team. | 04:56 |
| persia | And it's still Patch Day! We're down to 79 bugs to review, which indicates that we're 58% done. | 05:00 |
| maco | what team would be subscribed when its uploaded and sitting in a queue? | 05:01 |
| maco | archive admins or something? | 05:01 |
| maco | (do they have a team?) | 05:01 |
| persia | Depends on the reason for the freeze. | 05:01 |
| persia | I'd say the Release Team, generally. | 05:02 |
| maco | i uploaded a merge to maverick today thats waiting for toolchain freeze to go away | 05:02 |
| persia | So, bug #538774 is an example of a bug in our queue that's Fix-Committed. Why shouldn't that get patch-accepted-debian and be unsubscribed? | 05:02 |
| ubot3 | Malone bug 538774 in python-scipy "scipy.io.loadmat() excessively slow (regression)" [Undecided,Fix committed] https://launchpad.net/bugs/538774 | 05:02 |
| persia | Also, even if an upload is prepared for Ubuntu, should we not be looking at pushing the patch somewhere else (or verifying that this has been done)? | 05:03 |
| maco | that's a misuse | 05:03 |
| maco | the person put fix committed when they committed to their own branch on lp, but if theyre going to use that it should be when it gets committed to lp:ubuntu/<package> | 05:04 |
| persia | How is that different than the case you describe? It will be closed with autosync in a couple days, much like the case you descibe will be closed with unapproved queue clear. | 05:04 |
| persia | Oh, right. Timing miss. | 05:05 |
| maco | timing miss? | 05:05 |
| persia | Yeah. The status was changed for the incorrect reason (making it good we caught it), *but* in later analysis, it has reached a state that matches what you describe. | 05:05 |
| maco | oh yeah i looked at the activity log to see how it got there | 05:06 |
| maco | i dont think we're doing it like this yet, mostly (though kubuntu does) but committing to lp:ubuntu/<package> bunches of fixes and then only doing a dpkg-buildpackage -S once seems like something thatll be futury | 05:07 |
| maco | futurey | 05:07 |
| maco | erm..something | 05:07 |
| persia | Right. Anyway, my point is that in case 1: where it's Fix Committed for the wrong reasons, we want it anyway, and in case 2: where it's Fix Committed because it's been uploaded and pending processing, it's not bad for us to get it. | 05:07 |
| maco | "get it"? | 05:07 |
| persia | "receive the bug in our review queue" | 05:07 |
| persia | I've worked on a bunch of packages that do VCS packaging and upload containing lots of fixes by lots of folks, and yes, in that case, Fix Committed makes sense, but I think there's still value in us tracking the patches to ensure that patch communication is happening. | 05:09 |
| maco | you mean in terms of upstreams? | 05:15 |
| maco | persia: patch communication in terms of what? | 05:21 |
| persia | Yeah. | 05:21 |
| persia | Basically, I'm not sure how the stuff we do is in any way affected by Fix Committed. | 05:22 |
| persia | because none of the automated patch communication stuff takes effect until the upload is processed. | 05:22 |
| maco | i think ill go through all the fix-committed's and check to see if theyre improper use and if so put them to the proper status | 05:23 |
| persia | I recommend against that. You'll bump into the Desktop Team, which abuses that status regularly. | 05:23 |
| persia | There aren't any more Fix Committed ones in our queue. | 05:23 |
| maco | yeah just noticed that when i saw jon the taco and seb128 both use it weirdly | 05:26 |
| maco | seems that team uses fix committed in ubuntu in place of upstream bug watches | 05:26 |
| maco | persia: my email says to tell you im gonna expire from sponsors soon | 05:32 |
| persia | I suspect your email tells you that you're expiring from the obsolete sponsors team, and suggests telling me under the false impression I'm going to let anyone renew :) | 05:33 |
| persia | Would you like to join the new, cool, shiny, real sponsors team? | 05:33 |
| * persia finds the .m and prepares to click the button, waiting for a response | 05:35 | |
| maco | hehe yes :) | 05:37 |
| maco | the .m? | 05:37 |
| maco | is that because lp/~maco != me ? | 05:38 |
| persia | Yes. | 05:38 |
| persia | The .m is essential | 05:38 |
| maco | yeah i dont know lp/maco | 05:38 |
| maco | just that they took my name | 05:38 |
| maco | thanks | 05:43 |
| maco | (just got email) | 05:43 |
| persia | Thanks for helping with sponsoring :) | 05:44 |
| persia | OK. 5:00 UTC, and we're only down to 78, which is the one I did. There's lots there, and we've only 6 hours left, which means we need to push fairly hard to finish within the day! | 05:57 |
| maco | persia: it went back up to 79 | 06:35 |
| persia | It did indeed, but shishire is working 485225, and I expect it to go back down soon. | 06:37 |
| maco | persia: if a not-right patch is attached to a bug, should we unmark it as a patch or delete it or what? | 06:39 |
| persia | example? | 06:39 |
| maco | https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/512395 | 06:39 |
| ubot3 | Malone bug 512395 in openoffice.org "Openoffice.org's .desktop files do not contain translation domain info" [Wishlist,New] | 06:39 |
| maco | well in this case there are a bunch of "oh no wait this time i got it right..." type things | 06:40 |
| persia | I'd call that patch-needswork | 06:40 |
| maco | should the old patches be removed? | 06:40 |
| dholbach | good morning | 06:40 |
| persia | I'd leave the old patches for historical purposes. | 06:40 |
| maco | ok | 06:40 |
| maco | should they be unmarked so that the patch list on the side only lists the one thats being suggested? | 06:41 |
| persia | Hmm. That's an interesting question. | 06:41 |
| persia | I think "No", because I think there's sufficient value in reading the bug log to understand the background. | 06:42 |
| maco | ok | 06:42 |
| persia | That said, it does add apparent difficulty if one assumes folks just grab from the patch lists and push, but I think doing so is uninformed behaviour, and don't want to encourage it. | 06:42 |
| persia | Note that I feel this is a very subjective opinion on my part: I'm not certain it should be policy without wider discussion. | 06:43 |
| maco | usually when im going "oops that patch was wrong, heres a fixed one" i delete my previous one from the bug. wasnt sure if that was just me or not | 06:43 |
| dholbach | Development and MOTU Q&A Session in #ubuntu-classroom in 17m | 06:43 |
| maco | dholbach: pfft nobody in this channel has any interest in development :P | 06:44 |
| maco | this channel is for kitten photos! | 06:44 |
| dholbach | maco: I hope you're wrong ;-) | 06:44 |
| persia | And we kinda compete with MOTU in some ways: seeing who can get the patches applied first | 06:44 |
| persia | (to different targets) | 06:44 |
| maco | (actually no, #ubuntu-women was the kitten-photo channel earlier) | 06:44 |
| maco | cuz we're trying to make it so that all the patches reach ubuntu by syncing from debian? | 06:45 |
| persia | Or, better, by inclusion by the original software authors, yeah. | 06:45 |
| persia | Mind you, it's a very freindly and cooperative competition :) | 06:46 |
| maco | well if its in upstream, itll hit debian then sync to here in most cases | 06:46 |
| persia | Right. | 06:46 |
| maco | i dont /think/ there's a whole lot that goes straight into ubuntu without passing through debian | 06:46 |
| maco | except kde. we get that packaged within a day or two of a new release and then i have no idea how long til debian's got it | 06:46 |
| persia | Depends on the area of focus. Some areas have lots, some not so much. | 06:47 |
| maco | mm and the kernel | 06:47 |
| maco | so where do OOo patches get pushed to? OOo-proper or Go-OOo? | 06:49 |
| persia | Ask ccheney :) | 06:50 |
| persia | And we're still at 79 at 6:00 :( | 07:11 |
| * persia needs to stop digging at hard ones, and hunt through for easy ones | 07:11 | |
| maco | persia: unsubscribe the reviewers team after marking patch-needswork? | 07:15 |
| persia | maco: Please, and please give the patch submitter as *much* detail as you can about how to fix it. | 07:16 |
| persia | I'm not sure we have a good model for what to do once the patches get fixed: maybe hint that they can resubscribe us. | 07:16 |
| maco | persia: a comment has already done that | 07:16 |
| persia | nigelbabu: When you get back: this is a case that deserves some thought: how to we recapture patches that needed work to ensure that they don't get lost. | 07:17 |
| maco | persia: dont suppose a script could be written to run periodically that churns through all bugs tagged "patch-needswork" and check the activity log to see if a patch has been added since the tag was and if so, replace the patch-needswork with patch? | 07:25 |
| maco | (no idea if lplib exposes enough info for that though) | 07:25 |
| persia | That might work, but we'd need to find a way to put it in a workqueue. | 07:26 |
| persia | Maybe have that script remove patch-needswork and subscribe the reviewers team again? | 07:26 |
| ajmitch | oops, looks like I missed dholbach's session :) | 07:40 |
| maco | ajmitch: its still going | 07:40 |
| maco | he's doing a Q&A | 07:40 |
| maco | and im learning more about this UDD stuff and how it makes everything ive been doing obsolete and wrong | 07:41 |
| * ajmitch goes to read the backscroll | 07:41 | |
| * ajmitch needs to learn how to be a rock star | 07:41 | |
| persia | maco: It's not obsolete and wrong. I do nearly everything that way. There are alternatives. | 07:42 |
| maco | apparently i fail at humour this far past bedtime | 07:43 |
| ajmitch | even though I've been using bze since 0.0.x, I'm still getting used to the Proper way of using it for packages | 07:43 |
| ajmitch | s/bze/bzr/ | 07:43 |
| * persia isn't convinced there exists *the* proper way. | 07:44 | |
| persia | I've used it in at least 3 different ways, depending on the set of packages with which I was interacting. | 07:45 |
| ajmitch | yeah, I've used it with having upstream+debian+integration branches | 07:45 |
| ajmitch | that made for fun times | 07:45 |
| === gotunandan_ is now known as gotunandan | ||
| persia | Hey gotunandan! | 07:53 |
| gotunandan | hi persia | 07:53 |
| persia | It's Patch Day! We're following https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow : just ask if you have any questions, or need an opinion or a hand. | 07:53 |
| gotunandan | i do not know how useful I can be right now, since I am on a windows PC (at work :P ) | 07:53 |
| persia | Ah, yeah, that makes it tricky to test the patches :) | 07:54 |
| gotunandan | Also I think I'll need to do some reading up on the entire packaging process, pretty keen on doing something at least in the maverick cycle ! | 07:55 |
| persia | I'd actually recommend against "reading up" too much. It's easy to get stuck in circles of ever-more-complex documentation for specialised corner cases. | 07:56 |
| persia | If you just want to do packaging work for Ubuntu, I'd suggest you'd do better to hang out in #ubuntu-motu, try to work on some of the MOTU TODO tasks, and ask questions whenever you get stuck (this will probably be *lots* at the beginning). Folks will likely point you at specific, targeted, documentation that helps you understand the problem at hand, rather than you needing to learn everything first. | 07:57 |
| gotunandan | oh, but its been a while since I last did some packaging, my ppa has been stale for a few months now :| Just need to refresh a bit, I guess | 07:57 |
| persia | Even our most knowledgeable packagers don't pretend to know everything about packaging. | 07:57 |
| gotunandan | right, thanks :) | 07:57 |
| ajmitch | not even persia knows all :) | 07:58 |
| * persia encounters unknown stuff *every day* | 07:58 | |
| persia | OK. 7:00 and we're down to 76. I'll blame that on the recent -classroom session, but let's get back to Patch Day! | 08:00 |
| * ajmitch hasn't been working on any for several hours | 08:01 | |
| * imbrandon grabs the list-o-bugs | 08:07 | |
| persia | We're down to one page :) | 08:07 |
| ajmitch | and some of the bugs have 2 tasks listed there | 08:09 |
| persia | Hey etretyak! | 08:11 |
| etretyak | persia, hi | 08:12 |
| persia | We're following https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow and down to 75 bugs in our current worklist. Jump in, grab one, and ask if you have questions. | 08:12 |
| etretyak | ok.. let me see | 08:13 |
| persia | Welcome ddecator :) | 08:17 |
| ddecator | thanks persia =) | 08:17 |
| ddecator | hopefully you guys can introduce me to what patch reviewing entails this weekend. is there a wiki page i can look over? | 08:18 |
| persia | https://wiki.ubuntu.com/ReviewersTeam is probably a good place to start. | 08:19 |
| persia | https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow is the core of what we do. | 08:19 |
| ddecator | perfect, thanks | 08:21 |
| persia | Hey zus! | 08:23 |
| zus | persia, helllo | 08:23 |
| * zus waves to persia | 08:25 | |
| persia | Did you change your mind, and are staying up to review a few patches, or just stopping by? | 08:25 |
| persia | Ah, the latter, I think :( | 08:25 |
| ddecator | how long does it take to review a patch? | 08:27 |
| persia | Minutes to hours, depending on the complexity of the patch, etc. | 08:27 |
| ddecator | if you got one that'd only take a few minutes, i can see about helping out real quick before i go to bed =) | 08:27 |
| persia | Sometimes we get lucky, and the patch is submitted by upsteam, so it's just a quick test and see about getting into Ubuntu. | 08:28 |
| persia | Sometimes we're unlucky, and the patch is confusing, does something subtle that's tricky to reproduce, and has an usptream with an irregular bug tracker with a complicated signup process. | 08:28 |
| ddecator | i'll let you guys handle those for now.. | 08:28 |
| persia | Bug #527639 looks like it's not terrible. | 08:30 |
| ubot3 | Malone bug 527639 in boinc "boinc should use chrt instead of schedtool" [Wishlist,Triaged] https://launchpad.net/bugs/527639 | 08:30 |
| persia | Should be easy to test, and seek upstream comment. | 08:30 |
| ddecator | so since it's not necessarily a bug to reproduce, i just get the software, see how it works, apply the patch, and make sure it doesn't break the functionality at all? | 08:34 |
| ddecator | persia: ^ | 08:37 |
| persia | Basically, yeah. | 08:38 |
| persia | Also, check some upstream docs on schedtool and chrt and make sure that it actually makes at least some sense (no reason to bother upstream if it's pointless). | 08:39 |
| persia | I suspect it does make sense because without having thought about it previously, I have chrt on my system, and don't have schedtool, but that may be coincidence. | 08:39 |
| ddecator | right, which seems to be the reasoning behind the suggested change | 08:40 |
| persia | Indeed :) | 08:40 |
| persia | You did ask for an easy one :) | 08:41 |
| ddecator | alright, so i have some more questions about what i should do exactly, but i'm afraid that'll take up too much time and i've already stayed up later than i should have, so i'll return to this patch tomorrow and ask for some help in here =) | 08:41 |
| persia | OK. | 08:41 |
| ddecator | thanks for the help persia | 08:41 |
| ddecator | g'night guys | 08:41 |
| persia | Note that someone else might grab it first though, and you'll have to get a new one. | 08:41 |
| ddecator | that's fine | 08:42 |
| ddecator | i'll watch to see what the person did in that case | 08:42 |
| persia | Hey RAOF. We're almost done, but can always use a bit more on the last push :) | 09:01 |
| persia | OK. 75 bugs. 3 hours. It's a push, but possible. Now we just need a *heap* of reviewers in the eastern pacific :) | 09:09 |
| persia | Hey alourie|work. | 09:27 |
| persia | Still 75 at 8:00 :( | 09:58 |
| nigelb | persia: how are we doing on the count? | 10:39 |
| persia | Not wonderfully :( | 10:39 |
| nigelb | breached 70s? | 10:39 |
| persia | We're down to 75, but we've been holding there for a good while now. | 10:40 |
| nigelb | ouch, was 79 when I left | 10:40 |
| persia | So it's nice to have only one page of reports, but I think not many people still find it 5th May :) | 10:40 |
| nigelb | well, patch day gets over in about 20 days and we can review what we did wrong | 10:41 |
| nigelb | I have a couple of complaints with the workflow which I need to correct | 10:41 |
| nigelb | I feel we should never unsubscribe ~ubuntu-reviewers unless we don't intent to review that patch at all | 10:41 |
| nigelb | also, I'm thinking of defering a few packages to the server folks, the ones that are too hot to handle for us | 10:42 |
| persia | Hrm? 80 minutes I thought. | 10:42 |
| nigelb | 1100 UTC is when? | 10:42 |
| persia | 78 minutes from now. | 10:42 |
| nigelb | ok, my time calculation is just broken :) | 10:42 |
| persia | So, my thought on unsubscription is that if we have already reviewed a bug, why do we need to stay subscribed? | 10:43 |
| nigelb | also we need a way for people to say, I got this, the ~ubuntu-reviewers need not get into this bug | 10:43 |
| nigelb | the unsub is because I'm giving other folks can option to say ^ | 10:44 |
| nigelb | so, all the sub'd bugs would be taken care of by us, and others would be taken care of someone else | 10:44 |
| nigelb | great, now I have putty, my private key, but forgot to note down the ip adress and port to connect to :( | 10:46 |
| persia | I don't think that's a big deal: if we bump into bugs like that, we can just unsub. It's usually fairly easy to identify when someone has it, and it's not that hard to add our tags and unsub. | 10:47 |
| persia | heh. | 10:47 |
| nigelb | yes, so we'll make a policy that we wont take of bugs that we've unsub'd | 10:48 |
| nigelb | so I'd rather have the others in the review queue. anyway it wont show up in the query unless ready for re-review | 10:48 |
| persia | How does "ready for re-review" work? | 10:49 |
| persia | Especially for the patch-needswork case? | 10:49 |
| nigelb | we leave instruction that once you feel the patch needs another review by us, please change the patch-needswork tag to patch tag | 10:52 |
| persia | Oh right. | 10:55 |
| persia | maco: ^^ | 10:55 |
| nigelb | i probably need to work on standard replies | 10:58 |
| persia | heh | 11:02 |
| nigelb | any other lessons from patch day? | 11:06 |
| persia | 10:00 and still 75 bugs. Over to nigelb! | 11:07 |
| persia | We need to do better at determining what to do with Ubuntu-only packages. | 11:07 |
| persia | When there's no real upstream, I'm not sure how much we can help. | 11:08 |
| persia | Maybe that's just extending the blacklist a lot. | 11:08 |
| nigelb | I'd vote to blacklist packages like eucalyptus | 11:09 |
| nigelb | we'll just break their workflow | 11:09 |
| persia | And stuff like apport/mountall/casper/ubiquity/etc. as well? | 11:10 |
| nigelb | yep, especially stuff maintained by folks at canonical | 11:11 |
| nigelb | they are being paid to do it, we're better off helping the packages that noone cares about | 11:11 |
| persia | I disagree with that. I don't see how it matters whether it's being maintained by folks at Canonical: I think it matters more whether it's being maintained *in* Ubuntu. | 11:12 |
| persia | So, there's folks at Canonical who maintain a bundle of packages and do most of their uploads to Debian, etc. They might use the package in Ubuntu, but ae normal upsteams in that they don't tend to use distribution-provided packages. | 11:13 |
| nigelb | yeah, well, they tend to sort of coincide | 11:13 |
| persia | And there's package in Ubuntu, like ubuntustudio-controls, that aren't maintained by folks at Canonical, but have no sensible separate upstream. | 11:13 |
| nigelb | we ignore those is what I'm saying | 11:14 |
| nigelb | the ones that are always uploaded to ubuntu | 11:14 |
| persia | Sure, but I think we should focus on stuff where upstream maintains it in Ubuntu, rather than anything else. | 11:14 |
| persia | whereas something like python-lazr.uri would work fine with our regular process. | 11:15 |
| persia | (or maybe that wasn't the best example, but you get the idea) | 11:15 |
| nigelb | its extremely subjective, we'e better off having a wiki page were folks can suggest the ones we can *potentially* ignore and then take a call | 11:16 |
| persia | That sounds ideal: let's have a wiki page and invite developers who maintain their packages *in Ubuntu* and don't want us pushing patches upstream to add their packages there. | 11:17 |
| persia | That makes it opt-in on a per-developer/per-package basis. | 11:17 |
| persia | And nicely avoids all the social discussions :9 | 11:17 |
| persia | :) ! | 11:17 |
| nigelb | yes, better than them coming screaming at us | 11:17 |
| nigelb | ok, so graphs, changes to workflow, standard replies, and page for developers to opt-out | 11:19 |
| persia | Well, if we have a wiki page, and we announce it to ubuntu-devel@, then if folks come screaming, we can point at the wiki page and the email, and ask them why they don't read their mail :) | 11:19 |
| nigelb | exactly! | 11:19 |
| nigelb | Anything else hit you we're doing wrong? | 11:23 |
| nigelb | Did we advertise too less about patch day? :/ | 11:24 |
| persia | I think we did fairly well. | 11:24 |
| persia | 110+ patches reviewed. | 11:24 |
| nigelb | It would be very intersting to see the patch review mailing list, especially the moderation to see how many people participated | 11:24 |
| nigelb | all the bug mails would be stuck in moderation. I have to ask brian to give me a tar or something of all the mails over last 2 days | 11:25 |
| persia | I think we also need to work on integration with bugsquad more. | 11:25 |
| persia | I saw someone in bugsquad suggest subscribing us and adding the patch tag as the way to triage a bug with a patch. | 11:25 |
| nigelb | woot, yes it is :) | 11:25 |
| persia | But I'd rather be more integrated, so that folks upstreaming bugs know about our tags, and we make sure we do the right upstreaming stuff when we forward our patches. | 11:26 |
| nigelb | raise it at the next bug squad meeting? | 11:26 |
| nigelb | its after UDS anyway | 11:26 |
| persia | Sounds like a good plan. | 11:26 |
| nigelb | during UDS you can say how successful Patch day was ;) | 11:27 |
| persia | and make sure the upsteaming docs point to our docs about tags when also sharing patches and make sure our docs point at the upstreaming docs as best practice when opening upstream reports, etc. | 11:27 |
| nigelb | our docs point to upstream docs | 11:27 |
| nigelb | *upstreaming | 11:27 |
| persia | Sure, but let's make sure we *preserve* that as we update our docs :) | 11:28 |
| nigelb | yes, the docs need extensive revision, including how to test | 11:28 |
| persia | We're an interesting mix of triagers and developers (and folks who are both), and I'd like to not end up with too much of a separate identity. | 11:28 |
| persia | Patch review should be something people do, not something people are. | 11:28 |
| nigelb | did I tell you the statistic I had come up with? | 11:29 |
| nigelb | 1800 bugs with patches attached, out if which 1500 will be in our queue if there were no date thingy. If all the members of ~ubuntu-dev reviewed 10 bugs, we'd be done! | 11:29 |
| nigelb | there were 153 members of ~ubuntu-dev when I last checked | 11:30 |
| nigelb | if everything comes together, patch review, adopt-an-upstream, bug triage, it would be the most awesomest! | 11:31 |
| persia | Yeah. It's not hard to review all the patches. Folks just aren't doing it. That's why we needed this initiative. | 11:31 |
| nigelb | Yep. I'm deeply saddened by that. | 11:32 |
| nigelb | But, also happy that in 1 month, we could get going so fast. | 11:32 |
| nigelb | This cycle, I'd like to explore the possibility of us being the new starting point for development, though I'd advocate uploads to debian than Ubuntu to reduce the delta. | 11:33 |
| persia | I don't think any model that involves the starting point for development is good. | 11:33 |
| persia | I'd rather consider us *a* starting point. | 11:33 |
| nigelb | Well, yeah *a* starting point, especially to budding triagers | 11:34 |
| nigelb | People who are well versed with bugs and want to start thinking of packaging stuff | 11:34 |
| persia | And I think that work in this team is a close match to a lot of MOTU work, so it makes a good "next step" for bug control folks vaguely wanting to do more development, but without any close association with one of the development teams (e.g. desktop, server, kubuntu, mythbuntu, etc.) | 11:34 |
| nigelb | yep, lost folks like me ;) | 11:35 |
| persia | Right. I think we're thinking the same, except for the "a"/"the" bit :) | 11:35 |
| persia | I don't like to think we're lost, so much as we're more interested in fussing with random stuff than focusing on anything specific. | 11:35 |
| nigelb | yea, I agree with the 'a' too | 11:35 |
| * persia tends to focus first on anything that is irritating when using Ubuntu installs, and then on various unloved pacakges. | 11:36 | |
| persia | At least, for me, if someone is caring for a package, they tend to do a good enough job that I'll end up being lazy, rather than fixing it. If nobody else is watching, then I'm more likely to be annoyed and just fix it. | 11:37 |
| nigelb | Desktop team likes us taking care of patches, so far they're happy that we're pointing out stuff that work | 11:37 |
| nigelb | But I'd defer mozilla stuff to somene from the team since they take good care of them | 11:38 |
| nigelb | Also, most of the patches tend to turn up in unmaintained stuff since no one maintaines those pacakgse | 11:38 |
| nigelb | People get annoyed and fix the bug. | 11:39 |
| nigelb | And we ignore them. | 11:39 |
| nigelb | We're down to 74, I guess you're reviewing. | 11:40 |
| persia | I must run: good luck with the end of the day. I think we made great progress, regardless of the counts, just from the number of folk who came by the channel and read the docs, and had some practice doing it. | 11:43 |
| nigelb | persia: I'm stepping out for some chores too. :) | 11:43 |
| nigelb | persia: shall I delcare patch day officially over? | 11:44 |
| nigelb | another 15 mins to go, but I have to run | 11:44 |
| persia | If you have to run, unless you can get someone else, yeah. | 11:44 |
| persia | 111 bugs done! | 11:44 |
| persia | Actually more, because we got some new ones (the count went up a couple times) | 11:44 |
| nigelb | Patch Day is officially over. Thank you Review Leads for your help. Those who reviewed patches, thank you for your time. | 11:45 |
| nigelb | We have reviewed 111 bugs in the last 50 hours! | 11:45 |
| persia | 49 :) | 11:45 |
| nigelb | 48-3/4 ;) | 11:46 |
| persia | We hit 61% of our target queue. | 11:46 |
| nigelb | Which is really really good news | 11:46 |
| persia | Which isn't bad for a first time. | 11:46 |
| nigelb | now, I think we can move that date 1 month back | 11:46 |
| nigelb | and plan for regular patch days | 11:46 |
| nigelb | no wait, scratch regular patch days | 11:46 |
| persia | Every month? | 11:46 |
| persia | Yeah, let's not have them for a while. | 11:47 |
| nigelb | we need something to encourage every day review, like 5-a-day | 11:47 |
| persia | Let's have sporadic patch days on an as-needed basis until we get a feel for how the team works. | 11:47 |
| persia | and if enough folks want to have a special Patch Day! we can do that. | 11:47 |
| nigelb | yes, when we get dangeoursly high, for now lets just keep things in 2 digits :) | 11:47 |
| persia | That makes sense to me, but let's not worry so much about next week, as lots of folks will be paying attention to UDS. | 11:48 |
| persia | With luck, we won't get so many patches, but I expect a bit of backlog :) | 11:48 |
| nigelb | persia: yes, and do tell them about the 10 patch per head thing and the 111 that me manged :) | 11:48 |
| nigelb | *we | 11:49 |
| persia | Really, UDS doesn't work that way: there's no good way to do announcements. | 11:49 |
| nigelb | plenary? | 11:49 |
| * persia is *not* going to try to schedule a plenary about Patch Day | 11:49 | |
| nigelb | lol, ok | 11:49 |
| nigelb | just mention that in the session | 11:49 |
| persia | Best is just to send mail to the developer and bugsquad mailing lists, saying what was done. | 11:50 |
| nigelb | Yes, that's a good idea | 11:50 |
| persia | That ends up getting mirrored all over the place | 11:50 |
| nigelb | The fridge can re-post *that* one | 11:50 |
| persia | Anyway, really have to go :) | 11:50 |
| nigelb | ok, ciao | 11:50 |
| vish | aw.. i did probably only around 5 :( | 12:21 |
| maco | <persia> We need to do better at determining what to do with Ubuntu-only packages. <--- subscribe sponsors? | 12:22 |
| yofel | would be fine, but only after we convert it into a debdiff | 12:29 |
| yofel | (IMHO) | 12:29 |
| yofel | I saw bugs where the sponsors were subscribed, didn't find a debdiff, unsubscribed themselved and subscribed us | 12:31 |
| maco | which they're not supposed to do | 12:31 |
| maco | the debdiffs-only stuff was supposed to have gone out a year or two ago | 12:32 |
| yofel | hm, I didn't check the dates on the posts | 12:32 |
| vish | maco: recent bugs too its being done | 12:33 |
| yofel | well, packaging the patch included reviewing it so it makes sense in some way | 12:35 |
| yofel | *includes | 12:35 |
| maco | "check it before you upload" has always been part of the sponsor's job | 12:35 |
| maco | even if it's a debdiff, they're still supposed to check it out! | 12:35 |
| yofel | true | 12:36 |
| vish | hrm , if the patch has been forwarded upstream do we unsubscribe te review team? | 12:36 |
| vish | the* | 12:36 |
| yofel | is says so on the workflow, you're supposed to subscribe yourself and follow the bug after that | 12:37 |
| vish | yofel: Bug #40872 , nigel has subscribed himself, i think we can remove the review team.. | 12:41 |
| ubot3 | Malone bug 40872 in nautilus "Desktop icons are allowed to overlap" [Unknown,Confirmed] https://launchpad.net/bugs/40872 | 12:41 |
| yofel | true, work is done | 12:41 |
| persia | So, patches for ubuntu-local stuff fals into an annoying gap. | 12:48 |
| persia | Sponsors *aren't* supposed to upload anything that isn't a ready candidate, and *are* supposed to be all sorts of picky to help train nascent developers. | 12:49 |
| persia | But we're not even especially focused on getting stuff into Ubuntu. | 12:49 |
| persia | The thought was to blacklist the Ubuntu-local stuff from the script that fills the review queue, and then expect whoever maintains the package to process the bugs once in a while. | 12:50 |
| persia | (where "whoever maintains" might be some random Ubuntu developer passing by, depending) | 12:50 |
| persia | That said, there's no reason that any of us *can't* turn a patch into an upload candidate in any of several ways, but that it's not the main goal of the team. | 12:51 |
| yofel | hm, about bug 546032 - I did use reportbug a few times already, but never supplied patches, and I don't get how submittodebian works, can I just use reportbug with the patch tag and supply links to the patches in the bug description? | 12:55 |
| ubot3 | Malone bug 546032 in tcsh "[PATCH] tcsh-6.14.00-astron $COLUMNS $LINES not set" [Undecided,New] https://launchpad.net/bugs/546032 | 12:55 |
| persia | I usually attach the patch in an email to the BTS. | 12:56 |
| persia | I'm not sure how reportbug does it. | 12:56 |
| yofel | well, reportbug is a cli app that creates a mail, but you're right, just sending a mail directly would be easier I guess | 12:56 |
| persia | yofel: reportbug has a -A option that lets you attach something, so you could use that. | 12:58 |
| yofel | ah, you're right, thanks | 12:59 |
| persia | Just be sure to add the patch tag if you sdo. | 12:59 |
| persia | manpages are wonderful :) | 12:59 |
| yofel | yep, I did check it, too fast it seems :P | 13:01 |
| === effie_jayx_ is now known as keffie_jayx | ||
| nigelbabu | maco: UUD can be taken at UDW | 14:08 |
| nigelbabu | err UDD | 14:08 |
| hyperair | nigelbabu: so how did patch day go overall? | 14:11 |
| nigelbabu | hyperair: 111 patches reviewed | 14:12 |
| hyperair | woo | 14:12 |
| hyperair | that's a lot | 14:12 |
| hyperair | it's now down to one page \o/ | 14:12 |
| nigelbabu | yes, thanks a lot for the tme that the review leads put in | 14:12 |
| nigelbabu | I intend to write a mail, now sleep time | 14:12 |
| vish | nigelbabu: hey ,any reason we you've left the team still subscribed to Bug #40872 | 14:13 |
| ubot3 | Malone bug 40872 in nautilus "Desktop icons are allowed to overlap" [Unknown,Confirmed] https://launchpad.net/bugs/40872 | 14:13 |
| nigelbabu | vish: Its reviewed, see tags | 14:16 |
| nigelbabu | the review team will not be unsub'd ever unless they dont want us playing with the bug | 14:16 |
| nigelbabu | I'll change the docs as soon as I'm sane and conscious | 14:17 |
| vish | nigelbabu: yup ,the docs wasnt clear... hence, was wondering if the team needs to be un-sub'd there.. | 14:17 |
| * persia has been unsubbing from everywhere, and wonders why we bother to have sub/unsub at all if we're not unsubbing to drop from the workqueue | 14:18 | |
| * hyperair did the same as persia | 14:18 | |
| nigelbabu | vish: I realized the hole in the docs only today. Its my mistake | 14:18 |
| nigelbabu | Just to make it clear. Do *not* unsub reviewers unless they dont want us poking in | 14:18 |
| nigelbabu | persia can explain further on that or you can read scroll back | 14:19 |
| hyperair | =\ i don't even remember which bugs i unsubbed reviewers from | 14:19 |
| nigelbabu | we talked about it 2 hours back | 14:19 |
| nigelbabu | hyperair: dont worry, we can find with tgas :) | 14:19 |
| hyperair | heh okay | 14:19 |
| nigelbabu | I'll do that next week, though I may have to run a huge LP query through api | 14:20 |
| nigelbabu | persia: can follow up with lool about the MIR? I need sleep and rest | 14:21 |
| persia | I can't explain, because I don't see the point (but I'm sure nigelbabu will explain better later) | 14:21 |
| persia | Which MIR? | 14:21 |
| nigelbabu | bug 525512 | 14:22 |
| ubot3 | Malone bug 525512 in libtime-modules-perl "[MIR] libtime-modules-perl" [Undecided,New] https://launchpad.net/bugs/525512 | 14:22 |
| nigelbabu | but 525395 is blocked due to this | 14:22 |
| yofel | so instead of usubbing reviewers remove the patch tag? or just add the tags? | 14:22 |
| * persia doesn't like MIRs are part of not liking components, but isn't prepared to ignore components completely yet | 14:22 | |
| nigelbabu | yofel: just change the tag according to situation | 14:22 |
| persia | nigelbabu: And the query already hides stuff with the right tags? | 14:22 |
| nigelbabu | persia: yes it does | 14:23 |
| nigelbabu | the unsub was part of workflow when I didn't know that | 14:23 |
| nigelbabu | brian explained it to me that day, that meeeting we had | 14:23 |
| persia | OK. I'm not sure there's any benefit to any of subscription/unsubscription/even having a team in LP if we're not actually using it. | 14:24 |
| yofel | k, so change the tag (and leave only one) and leave team subscribed, right? | 14:24 |
| nigelbabu | yofel: yes | 14:24 |
| yofel | ok | 14:24 |
| nigelbabu | persia: having the team sub'd gives option to others not to have us meddle | 14:24 |
| yofel | I'll try to fix the bugs I still find in my inbox later | 14:25 |
| persia | How? | 14:25 |
| hyperair | nigelbabu: but other people can't unsub us. | 14:25 |
| persia | But explain it to be when you've slept. | 14:25 |
| persia | I'm sure I'll disagree then too, but we can have a productive debate :) | 14:25 |
| nigelbabu | persia: when there is a bug a and there is a very responsible person taking care of it | 14:25 |
| vish | IMO , unsubscribe if someone takes up the bug.. | 14:25 |
| nigelbabu | vish: no | 14:25 |
| hyperair | launchpad api again \o/ | 14:25 |
| hyperair | nigelbabu: go sleep =p | 14:25 |
| nigelbabu | what if that person "gets hit by a bus" | 14:25 |
| nigelbabu | hyperair: good idea | 14:26 |
| nigelbabu | I should | 14:26 |
| hyperair | =) | 14:26 |
| vish | nigelbabu: i meant , if forwarded upstream.. , but not very sure the current flow is good though | 14:26 |
| persia | nigelbabu: Do. I'm fully prepared to debate this with you another day. | 14:26 |
| hyperair | count me in. | 14:26 |
| vish | lol! | 14:26 |
| yofel | me too | 14:26 |
| nigelbabu | vish: we still want it on the list, later, sleep is overtaking me | 14:26 |
| persia | nigelbabu: And I think you've been pinging lool sufficiently for 525512: I'll pay attention and say something if necessary whist you sleep, but it may just be a matter of time. | 14:27 |
| nigelbabu | persia: most probably, only if he asks something you feel I wont be able to answer :) | 14:27 |
| nigelbabu | persia: and I dont want to wait for 24 hours to finish a conversation ;) | 14:27 |
| * nigelbabu goes before someone kicks me out | 14:27 | |
| persia | I think it's 99% a matter of waiting for him to have time, which means it's probably not going to happen until post-UDS. | 14:28 |
| nigelbabu | im just reminding, btw vish had you assigned a bug to me? I vaguely remember a mail | 14:28 |
| yofel | hm, a patch attached and issue already fixed upsteam in a different way would be patch-rejected-upstream? | 14:28 |
| yofel | bug 542185 | 14:29 |
| ubot3 | Malone bug 542185 in qt4-x11 "holdingnuts GUI badly affected by a bug in Qt 4.6.2" [Medium,Triaged] https://launchpad.net/bugs/542185 | 14:29 |
| * persia looks | 14:29 | |
| vish | nigelbabu: the cheese bug? | 14:29 |
| vish | nigelbabu: wasnt that what we discussed the other day? | 14:29 |
| yofel | upstream patch: http://qt.gitorious.org/+kde-developers/qt/kde-qt/commit/1ab5feb6260589f254ed209816cb67dbe9d3e4a5 | 14:29 |
| persia | Yeah, that'd be patch-rejected-upstream, but it's worth adding a comment that this tag is used to denote the case where a patch doesn't match upstream changes perfectly, so that we know it has to be an Ubuntu-local adjustment, etc. | 14:31 |
| yofel | ok, thanks for confirming | 14:31 |
| persia | I'm not certain that all patch authors would understand this use of "rejected" (which isn't quite right) without explanation. | 14:31 |
| yofel | indeed | 14:32 |
| persia | But I'm not sure what other tags correctly toss the bug into the right "bucket": specifically the set of stuff that needs a developer to apply in Ubuntu directly. | 14:32 |
| vish | persia: i see one problem though , once we unsubscribe the team , the person who takes over must fully respond to the bug .. or we need to draw a line where the reviewer work ends.. if the bug patch is redone after 2-3 months what is the procedure then? if the person subscribed has gotten busy and is not looking at bugmail? who's task is it to check the patch then? | 14:33 |
| persia | vish: I don't think whether the team is subscribed or not makes any difference in that case. | 14:34 |
| persia | I think we'd do better to define a set of states in our patch management workflow, and then focus on moving patches between these states in various ways. | 14:35 |
| persia | subscription/unsubscription is one tool that could help with that, because it lets us set a match criteria for LP queries (and in a way that *dosen't* send bugmail). | 14:35 |
| persia | But just because the team is subscribed doesn't mean anyone will ever look at the bug. | 14:36 |
| vish | persia: yup no bug mail , but in that case , having the team subscribed might ensure the bug gets a second look ,... but still the current workflow isnt perfect though , this makes | 14:36 |
| vish | s/this makes/ / | 14:36 |
| persia | do a search sometime on all the bugs assigned to MOTU. Every single one of those is wrong, and nobody has ever used that query to find work to do. | 14:36 |
| persia | Why would it get a second look? If it doesn't show in the queries on the reviewing guide page, it's not likely to be looked at, regardless of anything else. | 14:36 |
| vish | persia: if the team is subscribed it could be looked again , but the tags would be misleading.. which is kinda wrong , what we need is the re-tagging to work properly and automatically ,once a new patch is submitted ,the old patch must be auto removed and subscribing the team then would probably work | 14:38 |
| vish | s/old patch/old tag/ | 14:39 |
| persia | vish: *why* would it be looked at again? Who would look at it? | 14:39 |
| yofel | is the mail that the review team gets as a launchpad group sent somewhere or to /dev/null ? | 14:39 |
| persia | And how would the result differ from e.g. a query againt the "patch" tag? | 14:39 |
| vish | right.. | 14:39 |
| persia | yofel: It goes to an LP mailing list that is subscribers-only, so most stuff ends up in a moderation queue, and is dropped summarily. | 14:39 |
| persia | vish: My point is not that the current system is correct. My point is that there's no inherent value to subscription, unless subscription is used to define a query that is used as a workqueue. | 14:40 |
| vish | +1 | 14:41 |
| persia | Well, and also that it has no more or less value than any other change we make to bugs to define a workqueue. | 14:41 |
| yofel | ah, if there was some way to access it I think it would make sense to leave the team subscribed, but from my point of view I would vote to unsubscribe the team currently | 14:41 |
| vish | persia: currently the workflow is kinda what anyone can do , there is no need for a specific team :s | 14:41 |
| yofel | +1 | 14:42 |
| persia | Well, unless we use subscription/unsubscription as a way to manage workqueues. We currently do, in that we only have the team subscribed to a subset of the available bugs, so as to focus on quick response to current patches, rather than too much on older patches. | 14:42 |
| yofel | only team members can unsubcribe the team, which means that if we don't require that we don't really get to review newcomer work as they have no reason to contact us | 14:43 |
| persia | I'd say that the vast majority of the patches we reviewed during patch day were submitted in the last couple months, which is good. If a patch has already sat around for a year, we already look bad, and it's not worth missing new ones to try to clean them up until we're ahead of ourselves with the new ones. | 14:43 |
| persia | yofel: Indeed, which is one of the reasons I *like* having unsubscription be part of the workflow: it encourages a member of the team to review all work by non-members until someone shows they know what they are doing, and can be made a member. | 14:44 |
| persia | (as our current requirements for membership are basically: someone says "Yeah, this person is good at it). | 14:44 |
| yofel | yeah, and about an hour to fulfill the bugsquad requirements | 14:45 |
| persia | and a week to get approved :) | 14:47 |
| yofel | unless somone doesn't use the desktop bugs team as a loophole yes | 14:49 |
| yofel | as that gives you an indirect membership | 14:50 |
| persia | There are lots of loopholes :) But yeah. | 14:52 |
| persia | The point of the requirement is basically that we didn't want to have to explain basic bug triage stuff also in the reviewers docs. | 14:53 |
| persia | Oh, and that most of the tasks end up being very similar to triage tasks, so it's helpful to have that background (in any of the *many* ways in which one can get it). | 14:54 |
| yofel | true | 14:54 |
| === yofel_ is now known as yofel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!