[00:35] Son_Goku: I question your anecdata there, THB [00:35] *TBH [00:35] I've heard lots of people say the exact opposite [00:35] really? [00:35] really [00:35] I imagine it depends very strongly on the maintainer/subscribers [00:35] well, the track record for both is really low for me [00:35] so it's not hard for one to surpass the other [00:36] some maintainers are excellent in either system, some are overworked, such is life [00:36] yeah, I know [00:36] god knows I've been that way about stuff, too [00:37] but I do really hate debbugs [00:37] it's a horrid system [00:37] I like how launchpad does quite a few things, I just wish it wasn't an enormous mess to set up and basically not portable to Python 3 [00:38] I like both in different ways [00:38] and hopefully we'll prove you wrong about Python 3 eventually :) [00:38] what is there to like about debbugs? [00:38] cjwatson: I *really* *really* hope so [00:38] you're being pretty aggressive about it so I don't really want to get into it quite honestly [00:39] meh, I'm in a sour mood (I've been sick for nearly 9 days) [00:39] may I recommend reading? [00:39] sarnold: reading what? [00:39] anything :) your local library likely has recommendations if your reading pile has grown too short :) [00:40] don't have one :( [00:40] but I like its simplicity and lack of bells and whistles; sometimes that's pretty refreshing [00:40] cjwatson: simplicity is nice [00:40] also I really really like the ability to clone bugs [00:40] I don't often see trackers with that feature [00:40] we have that feature in the Red Hat Bugzilla [00:40] fair enough [00:40] it is something that I miss from GitHub projects, though [00:41] GitHub's issue tracker leaves a ton to be desired [00:41] and its version tracking is a really good (if complex) bit of data gathering [00:41] cjwatson: isn't that just special emails with extra header information? [00:41] no [00:41] it's aware of the version history of each package and its status in different suites [00:42] that *is* handy [00:42] and can track bugs present/absent in different branches etc. [00:42] rhbz is unfortunately not wired up that way (even though I know it can do it...) [00:42] LP -> python3 is basically blocked pretty hard behind porting the build system to pip/virtualenv [00:43] what, so the Zope components are already ported? [00:43] I thought twisted was the sticking point? [00:43] because there are a bunch of key dependencies we can't upgrade until we've done that, for arcane reasons [00:43] Zope is mostly ported upstream [00:43] twisted is also mostly ported upstream, maybe with some missing bits and pieces [00:43] bzr is not ported, right? [00:43] wow, that must have been .. intense. :) [00:43] no, we'd have to do something about that, ditto storm and others [00:44] I can only imagine the pain that had to happen for zope and twisted [00:44] we might well be able to carve out some of our bzrlib dependencies a bit nowadays [00:44] not sure, it hasn't yet been really worth looking into that [00:45] but the first thing is to get onto xenial and onto pip [00:46] (and revision control into git, which should be in the new year assuming that our department's jenkins setup gets some necessary tweaks applied) [00:46] I certainly gather twisted was pretty heavy lifting [00:48] quite a few of LP's bzrlib dependencies are basically because there happened to be some handy bit of code in the bowels of bzrlib and the people working on that bit of LP knew that bit of bzrlib ... [00:50] so e.g. bzrlib.tests.multiply_tests (can be replaced by testscenarios), or bzrlib.lock.WriteLock used in lp.testing.pgsql and surely there's some other replacement for that [00:52] I suspect that with a bit of effort most of the rest could be made into some kind of RPC call to the codehosting server and we could just consolidate all the bzrlib use in codehosting, at which point the rest of the codebase could avoid needing to import it. Maybe. [00:52] e.g. our git hosting is structured so that all the use of pygit2 is entirely confined to the git server [01:08] it's too bad that lp never supported hg [01:09] it would have made for a first-class hosted hg system [01:10] yeah, perhaps; but the time has probably passed [01:16] * Son_Goku shrugs === clivejo is now known as zz_clivejo [10:54] anyone from the ubiquity slideshow team around? our (Ubuntu Budgie) proposal is kind of stuck - any chance of a review please? https://bugs.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu/+bug/1644976 [10:54] Launchpad bug 1644976 in ubiquity-slideshow-ubuntu (Ubuntu) "ubuntu budgie slideshow proposal" [Undecided,New] === zz_clivejo is now known as clivejo === clivejo is now known as zz_clivejo === zz_clivejo is now known as clivejo === grumble is now known as grumbells === JanC_ is now known as JanC