[00:11] blr: What're you working on atm? Did you sort out the big branch's test failures? === jamesh_ is now known as jamesh [00:18] wgrant: I did yep, I'm looking at https://bugs.launchpad.net/launchpad/+bug/676769 atm [00:18] Bug #676769: resubmitting a merge proposal should reuse the old commit message

[00:19] blr: That should be quick, but don't put too much effort into it -- the resubmit workflow needs to be entirely redesigned. [00:21] wgrant: sure. Anything I should be thinking about today prior to the stakeholder meeting? [00:23] blr: Not really, I don't think. [00:23] blr: Is the big branch ready for review? [00:30] wgrant: yes if you could have a look again thanks. [00:39] wgrant: oh one omission that I fogot to ask you about regarding the licensing for the git icons - does the entire text of the creative commons license need to be in LICENSE? [00:39] forgot even [00:39] or is it sufficient to state that the images are licensed CCv3 and provide a link [00:43] blr: It needs to include the entire text if we're including the icon. [00:43] Where's the icon used atm? [00:43] push instructions [00:49] wgrant: updated the license [00:54] blr: Did you explore splitting the page into a bzr half and a git half? You could then hide the non-default half behind an expander or something by default, making the page less awkward for projects that don't care about the other VCS. [00:55] I've just selected Bazaar, so why is the next thing on the page a Git command? [00:56] wgrant: err that's weird [00:57] you aren't seeing the push instructions update on changing the radio? [00:58] Hrm, I have JS issues, apparently. [00:58] Recreated the container over the weekend, must have broken something. [00:59] you should see the form toggling from the bzr|git radio [01:00] Didn't consider the expander, do you think that would work better? [01:01] would usually consider using an accordion when there are more than 2 sections, but here it seemed fairly binary [01:05] Oh, my container was too well secured. [01:05] heh [01:07] blr: That's working much better. We probably still want to provide the ability to set the other side's options, though. [01:08] (splitting the page into sections by VCS would make that easier, and also improve the non-JS case) [01:08] wgrant: oh, I suppose in that case we really will need a split. [01:09] frankly, I didn't consider the case of needing to set both. :| [01:10] It's not common, but it isn't very difficult, and it makes the path for migration much less unclear. [01:10] that's true. So I suppose we need a +setbranch/git and +setbranch/bzr [01:11] I want to set up my new Git trunk so I can test that my CI systems build against it, but I can't do that without changing my project's main VCS away from Bazaar :( [01:11] right [01:11] I think they can be on the same page. [01:11] Hidden like now. [01:11] But there's a $something that'll show the non-default one. [01:12] ok a link stating [Configure non-default (git|bzr)] ... something like that? [01:12] could we use the horizontal space? [01:13] would be a bit of a break from convention for LP forms, but I'd imagine most people have the resolution (would be nice to see those stats, did we ever get GA access?) [01:13] where default is just something expressed in the UI? does it have other consequences? [01:13] also, hi! [01:13] Evening beuno. [01:14] beuno: It just selects which VCS is preferred when showing listings, push/clone instructions, etc. at the moment. [01:15] * beuno nods [01:15] In the UI it's not referred to as the "default VCS", just the "VCS", but the other one can be used as well if it exists, if you click the relevant link. [01:15] hi beuno [01:16] eg. LP's default VCS is Bazaar, but because it has a Git repo too there's a Git link on https://code.launchpad.net/launchpad [01:16] Most projects won't be doing that long-term. [01:16] But it's important for migration and some weird projects that are really several codebases in one project. [01:16] (eg. lots of PES things) [01:17] and I guess the rationale for splitting them into parallel universes is because you can't merge between them [01:17] And they're very difficult (and usually not interesting) to list together. [01:17] Due to the repo vs. branch differences. [01:17] ah yes [01:17] that thing [01:18] Having them as separate worlds is fine for most cases and adequate for all, but we need to make the other world accessible. [01:20] * beuno nods [01:20] wgrant: any thoughts on how to best approach the layout? [01:22] are there are existing UI patterns for that sort of thing (i.e. 1. Configure this, but 2. optionally configure this) in LP? Would be best to follow existing convention, but I can't think of anything [01:23] blr: It need not be obvious. Just a widget somewhere that says something about "$VCS settings" and causes the rest of the widgets to appear. You already have something sort of along those lines in the description of the default VCS widget, where it mentions the other one is still available. [01:23] That could potentially be replaced with a single link somewhere that says "let me poke the other one too" [01:23] I don't know of anything similar. [01:23] It's very rare that we have two alternate worlds that sometimes need to exist in parallel. [01:24] yep, nothing springs to mind. Ok, I'll re-work it, and if it seems cludgy we can try a different layout I guess. [01:25] having 2 distinct forms will make the doctests happier at least. [01:26] blr: They're probably still the same form, but I guess see how it turns out. === Spads_ is now known as Spads [09:01] I've got various mostly UI branches up for review from the tail end of last week, in case they got missed [09:01] Currently working on merge detection [09:02] Whoops, forgot about those, sorry. [09:04] Except I need like four times as much coffee to do the turnip side of merge detection. :-P [09:14] cjwatson: Just an API call that takes a commit ID and a collection of other commit IDs and calls merge_base on each of them? [09:16] That bit's easy, but I think it's also useful to determine the commit at which it was merged into the left-hand history, analogous to bzr [09:16] hahaha left-hand history [09:17] I'm forever being annoyed at other sites for making it hard to find when something was merged [09:17] I've a feeling we're not in Bazaar any more. [09:17] Yeah I know but it's actually useful :P [09:18] But https://git.launchpad.net/launchpad/log/?h=db-devel makes SO MUCH SENSE. [09:18] Who needs topology :) [09:18] cjwatson: Do you have a strategy for determining the merge point? [09:18] You'd basically need to rewrite merge_base in Python. [09:18] I think. [09:19] We can use merge_base to speed up the common case of unmerged MPs. [09:19] True. [09:19] So first, exclude all MPs where merge_base(source, target) != source [09:20] But then it's graph theory in Python [09:20] Hence coffee [09:20] At least it should only have to be done once per MP, I suppose. [09:20] Hm. [09:20] I think a lot of that work can be amortised across all MPs [09:20] You can't actually terminate it early, even. [09:21] Oh, unless you use GIT_SORT_TOPOLOGICAL, I suppose. [09:21] Then I think the merge point is just the last one you see. [09:21] If I can't do it reasonably I'll just leave merged_revision_id empty [09:21] or null or whatever it is [09:22] I guess we could possibly also store the last point we've closed up to. [09:22] Then you can .hide(previous_commit) to limit the search sapce. [09:23] But not much point if it performs adequately anyway. [09:37] Going for a walk to think about the algorithm. Whatever I come up with I'll test on everything in LP's bzr-personal repo to see how it performs. [09:37] If it can do that it can probably take more or less anything. [13:12] Looks like the optimisation of running merge_base on everything first to test if it's merged at all isn't actually an optimisation. merge_base isn't that quick on large histories, and git_merge_base_many isn't exported. So we'd have to roll our own logic there even if we left aside the mergepoint detection. [13:13] I have an algorithm which roughly works based on merge_base for the first pass, but it took nearly two minutes to run over all the LP bzr-personal branches. [13:13] Also, repo.walk(oid, GIT_SORT_TOPOLOGICAL) takes time equivalent to walking the entire history before it returns any results at all. [13:14] Yep [13:14] That's a little under two seconds for LP. [13:16] I think it may be best to roll our own rev walker for this; we can order topologically without having to walk the whole history first. [13:17] How? [13:17] Depth-first traversal until we hit a node not all of whose children we've seen yet, at which point we push that onto a queue and look at it later. [13:18] Memory requirements should be no worse than libgit2's topological sort must already be doing. [13:19] Children or parents? [13:19] Traverse from which end? [13:19] Seems like a bug that libgit2's toposort is behaving this way, though. If you haven't asked for time or reverse as well, there's no reason it needs to walk the whole graph first. [13:19] Oh, right, we don't know the children yet [13:20] Hm, OK, that is actually hard. [13:20] Yup :) [13:20] libgit2 isn't wrong here. [13:21] It's also possible that it will be more efficient to just enumerate all the left-hand IDs up front. [13:21] Anyway, meeting first ... [13:21] (I have tests for this algorithm which pass, so shouldn't be too hard to refactor once I work something better out) [15:16] Fetching a complete list of left-hand parents for LP is about six times as fast as starting a topological walk and fetching the first commit from it [22:59] wgrant: hey there - is there any published documentation on handling of PPA keys and how they are used / secured? Basically, something that convinces a layman of the security. [23:00] bigjools: You wrote it :P [23:00] There's no documentation that I know of, though. [23:00] wgrant: I may have written it but now I am a customer ;) [23:00] looking for something official