[13:51] <JO0st> 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] <stub> 'bzr push lp:~jo0st/projectname/branchname' will create a new branch and push your code there.
[13:59] <JO0st> stub: thank you, after that I link the branch to a bug using the "link related branch" button?
[14:00] <stub> JO0st: Yes, that will link the bug to the branch. A comment would be appropriate too to give it some context.
[14:00] <JO0st> stub: thank you very much
[14:00] <stub> JO0st: You can also create a merge proposal, but many projects are small and don't really bother with those.
[14:41] <dobey> 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] <teward> 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] <teward> cjwatson: wgrant: granted, nginx in Debian is adamant of using done+wontfix so... *shrugs*
[15:07] <cjwatson> I think it's likely the right thing to do, it would just be nice to check.
[15:07] <teward> cjwatson: i agree, my connection died because E:BillUnpaid so i'm stuck on crappy campus wifi
[15:07] <teward> which gives me < 5Mbps
[15:08] <teward> so...
[15:08]  * teward expects a long download time >.>
[15:21] <teward> cjwatson: well... the database download kept giving me a broken pipe.  SO...
[15:21] <teward> cjwatson: i guess i'm just going to have to pull a report from the debian bts and filter on tag:wontfix >.>
[15:21] <teward> then scrape >.<
[15:25] <teward> cjwatson: i'll give you the cliffs notes, and the link to the full data pull..
[15:26] <teward> 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] <teward> cjwatson: at a glance, it looks like nginx isn't the only one to wontfix and close as resolved
[15:27] <cjwatson> Er, sure, but that wasn't what I meant
[15:27] <teward> cjwatson: i can't download the database here - it keeps failing at Broken Pipe
[15:27] <teward> i blame campus
[15:27] <cjwatson> The point is to take a random sampling of those and verify what the correct representation is
[15:27] <cjwatson> OK, so come back when you can
[15:28] <teward> cjwatson: that'll be a few months, because i have no internet OUTSIDE of campus internet - and they're killing the download
[15:28] <teward> cjwatson: at a glance, though?  looks like the 'proper procedure' is "There isn't one"
[15:28] <cjwatson> If you download the indexes rather than the full spool (or even a segment of it), that'll be much smaller
[15:29] <cjwatson> And will be enough to construct URLs that you can go and check by hand
[15:29] <teward> might do that
[15:29] <cjwatson> I don't care about proper procedure, I can tell you that for myself as a (former) bugs.d.o admin
[15:29] <teward> 'course worse comes to worse i'll have to create a new VM offsite >.<
[15:29] <teward> or borrow someone's
[15:30] <cjwatson> 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] <teward> cjwatson: okay
[15:30] <teward> cjwatson: is the linking back to launchpad easy to identify though
[15:30] <cjwatson> It doesn't have to be exact; my suspicion is that there'll be some outliers either way
[15:30] <cjwatson> Um, what linking?
[15:30] <teward> cjwatson: i.e. which ones originated on LP
[15:31] <cjwatson> Who cares
[15:31] <teward> heh
[15:31] <cjwatson> That's not important.  What we care about is whether this is actually a largely correct summary of that bug status combination
[15:31] <teward> ... o...kay i just got an rsync segv >.>
[15:31] <cjwatson> Independent of whether the bugs in question happen to be linked to LP bugs
[15:31] <teward> ack
[15:32] <teward> i think i need more coffee >.<
[15:32] <cjwatson> 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] <teward> ok
[15:32] <teward> god i wish there were linux workstations here on campus on the LAN >.<
[15:33] <teward> would move a lot faster than 100KB/sec
[15:49] <teward> 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] <teward> cjwatson: i'm obviously not a db guy :p
[15:50] <teward> oh great i have dead pixels >.>
[15:57] <cjwatson> $ rsync -av --include \*.summary --exclude \* --exclude \?\*.\* bugs-mirror.debian.org::bts-spool-archive/00/ 00/
[15:57] <cjwatson> $ grep ^Tags: 00/*.summary | head -n3
[15:57] <cjwatson> 00/100000.summary:Tags: upstream
[15:57] <cjwatson> 00/100100.summary:Tags: moreinfo unreproducible
[15:57] <cjwatson> 00/100300.summary:Tags: pending
[15:57] <cjwatson> etc.
[15:58] <cjwatson> 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] <teward> cjwatson: i'm going to borrow your command there then
[15:58] <cjwatson> Then grep for wontfix and you have a set of bug numbers which you can open in your browser
[15:58] <teward> cjwatson: also, my rsync-fu is not as good as yours, i bow to your superiority there
[15:58] <cjwatson> After running through something to select a random subset
[15:59] <cjwatson> I think that was more elaborate than needed due to poor editing; the second --exclude is redundant
[16:01] <teward> wheee, doublegrep
[16:01] <teward> and crap, i almost forgot i have class >.<
[16:01]  * teward disappears to run to class
[16:35] <teward> 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] <teward> cjwatson: of those so far...
[16:36] <teward> cjwatson: they would be "Won't Fix" in Launchpad, with the exception of the translations one
[16:37] <teward> also some driver packages falling into my sample, meeting the same case
[16:40] <teward> some of these are wontfix as a result of other bug merges...
[16:44] <teward> cjwatson: some have been fixed after the such but have `fixed` present somewhere there
[16:44] <teward> rather than 'done+wontfix'
[16:45] <cjwatson> (OK, could you please present the results in one go at the end?)
[16:46] <cjwatson> (preferably in whichever bug is open about this ...)
[16:46] <teward> cjwatson: ack
[16:46] <teward> cjwatson: problem is that chrome keeps crashing :/
[16:47] <cjwatson> 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] <teward> cjwatson: it'll be subjective, though.  i'll make the bug shortly
[16:48] <cjwatson> 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] <teward> cjwatson: well i'm done now
[16:57] <teward> cjwatson: writing the bug with the summary.
[16:57] <teward> 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] <teward> cjwatson: what's the link to the bugtrackers code again for Debian?
[16:58]  * teward wants to look at the code again
[16:58] <teward> and my scrollback didn't keep :/
[16:59] <teward> nevermind found it in my history
[17:00] <cjwatson> lib/lp/bugs/externalbugtrackers/debbugs.py
[17:00] <cjwatson> s/externalbugtrackers/externalbugtracker/
[17:02] <teward> cjwatson: https://bugs.launchpad.net/launchpad/+bug/1413304
[17:03] <cjwatson> Thanks.  Note that there is no difference between "closed" and "done" in debbugs.
[17:23] <teward> 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] <teward> 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] <teward> cjwatson: i also forgot a case i observed too, and just added it
[17:33] <teward> 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] <teward> cjwatson: and another case is 'done'+'moreinfo' which should be incomplete, but that's an edge case
[17:37] <cjwatson> 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] <teward> cjwatson: mhm
[17:37] <cjwatson> The same versioned-close heuristic would probably help there
[17:37] <teward> cjwatson: however, done+moreinfo+wontfix would still be wontfix
[17:38] <teward> cjwatson: the analysis on how this could be foolproof will be ongoing
[17:38] <cjwatson> I think it's sensible to distinguish versioned-close from close+tags-indicating-problem
[17:38] <teward> mhm
[17:38] <cjwatson> It'll never be foolproof
[17:38] <teward> cjwatson: indeed.
[17:38] <teward> the moment its foolproof devs lose jobs :;
[17:38] <teward> :/