[05:12] <wgrant> Launchpad will shortly be offline for up to 15 minutes while we upgrade a file server.
[05:21] <wgrant> (read-only access is still possible if you open a private browser window)
[05:36] <dpm> hi wgrant, is there a known issue with LP, or is it down for maintenance? I'm trying to add a bug task and keep getting a 502 error, and adding tags does not seem to work, either
[05:36] <wgrant> dpm: Heh
[05:36] <wgrant> 15:12:22           wgrant | Launchpad will shortly be offline for up to 15 minutes while we upgrade a file server.
[05:36] <wgrant> 15:21:16           wgrant | (read-only access is still possible if you open a private browser window)
[05:36] <wgrant> 15:21:26              --> | dpm (~dpm@ubuntu/member/dpm) has joined #launchpad
[05:36] <wgrant> dpm: It's back now.
[05:37] <dpm> I guess it was all bad timing, then :)
[05:37] <dpm> thanks, trying it again
[09:23] <mpt> Is there a page equivalent to <https://code.launchpad.net/ubuntu> for merge proposals?
[09:27] <mpt> …Via the PatchPilot pages I find <https://code.launchpad.net/bzr/+merges>, which suggests that <https://code.launchpad.net/ubuntu/+merges> should exist, but it doesn’t
[09:29] <wgrant> mpt: There is not.
[09:29] <wgrant> It would be unusably large.
[09:29] <wgrant> And not perform acceptably.
 lists a batch of over half a million branches in <10 seconds … There are fewer merge proposals than there are branches, right? :-)
[09:32] <wgrant> Databases don't quite work that way.
[09:32] <wgrant> It would require significant work to optimise the million row join to be acceptable.
[09:34] <wgrant> It may be something that's valuable with the new Git-based UDD.
[09:36] <mpt> Would Git make the database operation easier? Or just start from a small enough count that optimization wasn’t so daunting?
[09:37] <wgrant> Git-based UDD would be viable enough to justify the effort of making Distribution:+activereviews practical.
[09:37] <wgrant> Bazaar-based UDD is not.
[09:38] <wgrant> We anticipate that Git-based UDD will be usable, and used, for all packages, at which point it makes sense to make the experience great.
[09:40] <mpt> Oh, I didn’t realize that Bazaar UDD isn’t used for all packages
[09:41] <wgrant> Bazaar-based UDD tends to work fine for a package until someone uses it.
[09:41] <wgrant> Then it usually stops working for that package.
[09:41] <wgrant> It can't be used for many interesting packages.
[09:43] <cjwatson> Yeah, honestly at this point Bazaar-based UDD is worse than useless.
[09:44] <cjwatson> Because it is a seductive trap that leads people to believe that it's overall worthwhile, until they waste time finding out that it's not.
[09:44] <cjwatson> But just about enough people manage to sort of struggle along with it that we need to replace it properly rather than just decommissioning it unilaterally.
[09:45] <wgrant> Exactly.
[09:45] <cjwatson> Unfortunately development documentation authors decided to go with idealism rather than realism, and so the docs advocate a mode of operation that isn't useful for anything non-trivial.
[10:01] <mpt> So … Would it be useful to report a bug for a distribution +merges page, or would it get lost in the ocean?
[10:05] <cjwatson> I don't hugely mind, but it will definitely have to be put on the shelf for at least months, since Git-based UDD is as yet only at initial planning stages.  (Although the likely software to make it go already exists in Debian.)
[10:07] <cjwatson> Polishing around initially cut corners, webhooks, mirroring, recipes are ahead of it in the queue right now.
[10:09] <pkern> cjwatson: You mean Ian's project as its base?
[10:10] <cjwatson> pkern: Indeed, subject to Ubuntu people checking it out.
[10:10] <cjwatson> pkern: (Last I checked it was still not entirely as good friends with 3.0 (quilt) as it probably ought to be.)
[10:11] <cjwatson> But dgit is already mostly a more reliable package-import than package-import itself ever was ...
[10:12] <pkern> cjwatson: It's Perl.
[10:12] <pkern> That stunned me a bit.
[10:12] <cjwatson> *shrug*
[10:12] <pkern> Yeah, I have different constraints at work and people would throw things at me. ;)
[10:12] <pkern> I'm also planning to import everything so I should also look at that stuff soonish.
[10:13] <cjwatson> For this purpose, design-level resiliency is a lot more important than choice of implementation language.
[10:13] <pkern> Yeah, I know.
[10:13] <pkern> Except that I cannot actually run Perl, hence that doesn't help me.
[10:14] <cjwatson> Ah, cut-down system?
[10:48] <DamienCassou> hi
[10:49] <DamienCassou> when I try to log in launchpad, I'm told that I'm a bot. Even though I can't be 100% certain, I'm quite sure I'm not a bot
[10:49] <DamienCassou> Can somebody help me login please?
[11:48] <wgrant> DamienCassou: Submit a support request using the Support link at the bottom of the error page.
[11:49] <wgrant> I'll take your word for it that you're not a bot :)
[11:53] <DamienCassou> thanks!
[12:54] <brendand_> hi - would like change the name of the project https://launchpad.net/ubuntu-sanity-tests to https://launchpad.net/ubuntu-system-tests
[13:00] <wgrant> brendand_: File a request at https://answers.launchpad.net/launchpad.
[18:06] <DalekSec> It's safe to presume https://bugs.launchpad.net/launchpad/+bug/1084403 isn't getting fixed soon, right?  (If so, I need to setup a workaround, if not I can simply wait.)
[18:08] <cjwatson> DalekSec: Indeed; we don't have anyone working on that, and git mirroring + recipes will almost certainly be implemented before anything's done about that bug (if ever).
[18:09] <DalekSec> Alright, new question then.  Can you guess it? :P
[18:09] <cjwatson> DalekSec: In the meantime, as Jelmer suggests, occasionally running manual exports/imports is a reasonable workaround.
[18:10] <cjwatson> DalekSec: We'll hopefully have native git mirroring/recipes going in about two or three months, at a guess.
[18:10] <cjwatson> (Very roughly; neither is started yet.)
[18:11] <cjwatson> DalekSec: Hopefully something in there answered your new question. ;-)
[18:11] <DalekSec> Sure, roughly works just fine for me, at least gives me an idea.  Yes, thanks very much cjwatson!
[20:33] <whit> hello! I'm trying to clone lp:charm-helpers like so: git clone git+ssh://whitmo@git.launchpad.net/charm-helpers chlp
[20:34] <whit> I think from https://help.launchpad.net/Code/Git this should work
[20:34] <whit> but I get this error
[20:34] <whit> fatal: remote error: Could not translate 'charm-helpers'.
[20:34] <whit> what am I doing wrong here?
[21:00] <whit> is this the wrong place to ask questions?
[21:03] <dobey> whit: does lp:charm-helpers actually have a git?
[21:03] <dobey> whit: you can't checkout code that's in bzr, using git in that way
[21:03] <whit> dobey: so support is not bidirectional :/
[21:03] <dobey> no it's not
[21:04] <whit> ok... so if I have a bzr branch I've imported to git and I want to get changes back to the upstream in bzr
[21:05] <whit> is there a good workflow for this?
[21:06] <dobey> i guess the bzr plug-in to git would have to provide someway to push changes to a remote bzr branch
[21:06] <dobey> but that has nothing to do with launchpad itself
[21:13] <whit> my charmhelpers repo does is initialized for git and bzr, should be ok
[21:16] <dobey> i don't know anything about using bzr within git. i'd suggest asking whoever wrote the plug-in for git to support bzr
[21:20] <blr> whit: you're just a bit early! I suspect most canonical projects like charmhelpers will move to git in the near future :)
[21:21] <whit> blr, so if I were to say convince the charmhelpers maintainers to move over to git, what would that entail?
[21:21] <whit> and what would the ramification be?
[21:21] <whit> is bidirectional support planned?
[21:21] <blr> whit: that may be a decision that juju as a whole needs to make, I can't say with any certainty.
[21:22] <blr> whit: not at the moment no, although you're certainly not the first to ask for it.
[21:22] <dobey> bidirectional support would not be fun
[21:22] <dobey> so i wouldn't expect it to ever exist
[21:33] <cjwatson> whit: Bidirectional support isn't planned at this point, no.  We don't have serious version control system expertise on the team, and it would definitely involve that.
[21:34] <cjwatson> You could run imports yourself in one direction or the other if you wanted, or even use Launchpad's own git->bzr import facility.  It would probably be necessary to mark merge proposals as merged manually on one side or the other, though.
[21:35] <cjwatson> whit: Also, the way the world is going, we rather suspect most projects are just going to want to end up on git; it's not clear how much sense it makes to invest quite a lot of effort in what would be a fairly short-term transitional option for most projects.
[21:36]  * whit nods
[21:37] <cjwatson> whit: For charmhelpers, I guess that projects that embed it generally just take copies anyway, so it shouldn't have too many downstream implications apart from updating the scripts that refresh copies of things?
[21:37] <whit> we are moving away from vendoring due to a variety of issues
[21:38] <cjwatson> whit: Yeah, but for now
[21:38] <whit> yeah, true
[21:38] <cjwatson> whit: For charms in general, at least internal to Canonical we'd want mojo/codetree to have git support first, though bzr imports could perhaps serve as a stopgap
[21:42] <cjwatson> whit: Other things to think about: do you have/need a merge robot (tarmac is being worked on but not ready yet)?  You might want to do a mass import of all the existing unmerged branches, and we should probably suggest some scripts for that in migration docs although it's pretty tricky to fully automate in general.  And probably other things ...  You can certainly run an import as basically a read-only thing for a while until you have ...
[21:42] <cjwatson> ... everything sorted out, the way that we're currently doing for Launchpad itself
[21:42] <cjwatson> whit: And any CI facilities you have, of course