=== charles_ is now known as charles === drkokandy_ is now known as drkokandy === lp|outy5000 is now known as lazyPower === FourDollars_ is now known as FourDollars === Tribaal_ is now known as Tribaal [13:51] hey guys, I have never submitted any code to launchpad before. I would like to create a branch on an existing project to do a bugfix. I have found how to get the code to my computer, but don't seem to find how to submit it back after making changes. Can anybody help me with this? [13:56] 'bzr push lp:~jo0st/projectname/branchname' will create a new branch and push your code there. [13:59] stub: thank you, after that I link the branch to a bug using the "link related branch" button? [14:00] JO0st: Yes, that will link the bug to the branch. A comment would be appropriate too to give it some context. [14:00] stub: thank you very much [14:00] JO0st: You can also create a merge proposal, but many projects are small and don't really bother with those. [14:41] JO0st, stub: it's better to link branches using the --fixes argument to 'bzr commit' as then it's in the bzr metadata. using the button on launchpad does not store bug information in the bzr commit metadata [15:06] cjwatson: wgrant: well, i'm going to pull a random sample, assuming i can figure out the commands to run without having coffee >.< [15:07] cjwatson: wgrant: granted, nginx in Debian is adamant of using done+wontfix so... *shrugs* [15:07] I think it's likely the right thing to do, it would just be nice to check. [15:07] cjwatson: i agree, my connection died because E:BillUnpaid so i'm stuck on crappy campus wifi [15:07] which gives me < 5Mbps [15:08] so... [15:08] * teward expects a long download time >.> [15:21] cjwatson: well... the database download kept giving me a broken pipe. SO... [15:21] cjwatson: i guess i'm just going to have to pull a report from the debian bts and filter on tag:wontfix >.> [15:21] then scrape >.< [15:25] cjwatson: i'll give you the cliffs notes, and the link to the full data pull.. [15:26] summary: http://i.imgur.com/HOeSsb4.png overview w/ header links (top of search page): http://i.imgur.com/O1hAgPJ.png The Search Itself (5 min return time): https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;tag=wontfix [15:27] cjwatson: at a glance, it looks like nginx isn't the only one to wontfix and close as resolved [15:27] Er, sure, but that wasn't what I meant [15:27] cjwatson: i can't download the database here - it keeps failing at Broken Pipe [15:27] i blame campus [15:27] The point is to take a random sampling of those and verify what the correct representation is [15:27] OK, so come back when you can [15:28] cjwatson: that'll be a few months, because i have no internet OUTSIDE of campus internet - and they're killing the download [15:28] cjwatson: at a glance, though? looks like the 'proper procedure' is "There isn't one" [15:28] If you download the indexes rather than the full spool (or even a segment of it), that'll be much smaller [15:29] And will be enough to construct URLs that you can go and check by hand [15:29] might do that [15:29] I don't care about proper procedure, I can tell you that for myself as a (former) bugs.d.o admin [15:29] 'course worse comes to worse i'll have to create a new VM offsite >.< [15:29] or borrow someone's [15:30] What I'm asking is to get a rough handle on whether a random sampling of done/wontfix bugs are actually best represented as Won't Fix in Launchpad [15:30] cjwatson: okay [15:30] cjwatson: is the linking back to launchpad easy to identify though [15:30] It doesn't have to be exact; my suspicion is that there'll be some outliers either way [15:30] Um, what linking? [15:30] cjwatson: i.e. which ones originated on LP [15:31] Who cares [15:31] heh [15:31] That's not important. What we care about is whether this is actually a largely correct summary of that bug status combination [15:31] ... o...kay i just got an rsync segv >.> [15:31] Independent of whether the bugs in question happen to be linked to LP bugs [15:31] ack [15:32] i think i need more coffee >.< [15:32] I'm sure there'll be some outliers, so take a random sample of like 30 or so and check them by hand to see whether they would subjectively best be characterised as Fix Released or Won't Fix [15:32] ok [15:32] god i wish there were linux workstations here on campus on the LAN >.< [15:33] would move a lot faster than 100KB/sec [15:49] cjwatson: well, i'm stuck - its downloading the raw database data but not actually in a searchable/checkable format - any other ideas for accessing a list of bug numbers without spending an eon downloading the entire db? [15:49] cjwatson: i'm obviously not a db guy :p [15:50] oh great i have dead pixels >.> [15:57] $ rsync -av --include \*.summary --exclude \* --exclude \?\*.\* bugs-mirror.debian.org::bts-spool-archive/00/ 00/ [15:57] $ grep ^Tags: 00/*.summary | head -n3 [15:57] 00/100000.summary:Tags: upstream [15:57] 00/100100.summary:Tags: moreinfo unreproducible [15:57] 00/100300.summary:Tags: pending [15:57] etc. [15:58] You'd also want to grab the same from bts-spool-db, and in both cases check for the presence of ^Done: too [15:58] cjwatson: i'm going to borrow your command there then [15:58] Then grep for wontfix and you have a set of bug numbers which you can open in your browser [15:58] cjwatson: also, my rsync-fu is not as good as yours, i bow to your superiority there [15:58] After running through something to select a random subset [15:59] I think that was more elaborate than needed due to poor editing; the second --exclude is redundant [16:01] wheee, doublegrep [16:01] and crap, i almost forgot i have class >.< [16:01] * teward disappears to run to class [16:35] cjwatson: 10/30 so far of my sample - most are wontfix+done, one was an outlier and a translations package - wontfix then fixed later. [16:35] cjwatson: of those so far... [16:36] cjwatson: they would be "Won't Fix" in Launchpad, with the exception of the translations one [16:37] also some driver packages falling into my sample, meeting the same case [16:40] some of these are wontfix as a result of other bug merges... [16:44] cjwatson: some have been fixed after the such but have `fixed` present somewhere there [16:44] rather than 'done+wontfix' [16:45] (OK, could you please present the results in one go at the end?) [16:46] (preferably in whichever bug is open about this ...) [16:46] cjwatson: ack [16:46] cjwatson: problem is that chrome keeps crashing :/ [16:47] We'll want this all in a bug report for audit trail anyway, so you might as well batch it all up and put it there. [16:47] cjwatson: it'll be subjective, though. i'll make the bug shortly [16:48] I'm happy to help but the stream of incremental IRC notifications is getting a bit much, so batching would be really helpful :) [16:57] cjwatson: well i'm done now [16:57] cjwatson: writing the bug with the summary. [16:57] cjwatson: i found an outlier where it's 'fixed' but the package was removed (not really a 'fix' because the bug wasn't looking to remove the package) [16:58] cjwatson: what's the link to the bugtrackers code again for Debian? [16:58] * teward wants to look at the code again [16:58] and my scrollback didn't keep :/ [16:59] nevermind found it in my history [17:00] lib/lp/bugs/externalbugtrackers/debbugs.py [17:00] s/externalbugtrackers/externalbugtracker/ [17:02] cjwatson: https://bugs.launchpad.net/launchpad/+bug/1413304 [17:02] Launchpad bug 1413304 in Launchpad itself "[Bugtracker - Debian] Done+WontFix in Debian marked as 'Fix Released' even in cases where fixes are *not* released" [Undecided,New] [17:03] Thanks. Note that there is no difference between "closed" and "done" in debbugs. [17:23] cjwatson: ack. note i also went ahead and added a text file with the subset of bugs I used - one was merged into another bug but that link was not included here. [17:24] and I expanded your rsync - ...::bts-spool-archive/0*/ - this got a much larger set of bugs, which i pulled a list of via random number generators (shuf -n 30) [17:32] * cjwatson nods [17:32] cjwatson: i also forgot a case i observed too, and just added it [17:33] cjwatson: we should keep the 'open' analysis as well - there will be open bugs that aren't archived or closed which will have 'wontfix' [17:33] cjwatson: and another case is 'done'+'moreinfo' which should be incomplete, but that's an edge case [17:37] My gut feeling is that done+moreinfo should be expected to be mixed, because some of that will be people forgetting to remove the moreinfo tag when somebody explains the problem and then they fix it [17:37] cjwatson: mhm [17:37] The same versioned-close heuristic would probably help there [17:37] cjwatson: however, done+moreinfo+wontfix would still be wontfix [17:38] cjwatson: the analysis on how this could be foolproof will be ongoing [17:38] I think it's sensible to distinguish versioned-close from close+tags-indicating-problem [17:38] mhm [17:38] It'll never be foolproof [17:38] cjwatson: indeed. [17:38] the moment its foolproof devs lose jobs :; [17:38] :/ === Laney is now known as Guest54456