=== frankban|afk is now known as frankban [16:24] Hello. I'm thinking about hacking on Launchpad to add the ability to edit comments. Does Launchpad.net run on the trunk version or on some stable milestone? [16:26] very close to tip [16:27] if we've just done a deployment, then it runs exactly on the tip of lp:launchpad [16:29] Cool. The wiki says to talk about it in here before starting to hack. Are there any pitfalls regarding this issue? https://bugs.launchpad.net/launchpad/+bug/80895 and probably https://bugs.launchpad.net/launchpad/+bug/668267 as well [16:29] Bug #80895: comments on bugs/answers/merge proposals/etc cannot be edited

[16:29] Bug #668267: No way to remove nuclear launch codes from comments on bugs, answers, merge proposals.

[16:30] have you thought about the social issues? e.g. what's to stop somebody engaged in an argument on a bug from editing a comment further up and gaslighting people by claiming they never said something? [16:31] I was thinking just to allow the author to edit their own comments [16:31] (There are many times I wish I could do that...) [16:31] OK, that's too broad and won't fly on its own. Matthew's suggestions in #80895 are one possibility, but it does need care and thought [16:31] Bug #80895: comments on bugs/answers/merge proposals/etc cannot be edited

[16:32] (i.e. time-limited) [16:32] Consider also the approach exemplified in https://www.dreamwidth.org/support/faqbrowse?faqid=47 : "You can edit your own comments on any journal, as long as the comments have not yet been replied to. You can't edit other people's comments posted on your entries, or edit comments after they've been replied to" [16:33] Good point. That sounds fair. [16:33] (That's how phpBB works too) [16:33] There's also the possibility of leaving the original comment around for inspection, but off to the side, like what happens if you edit a bug description [16:33] That doesn't address the "accidentally posted your house address in a comment" issue, but does address the typo issue [16:34] The admin hide ability that's already there addresses that though, right? [16:34] Yes, and people can in fact hide their own comments entirely too [16:35] Though I think possibly only on bugs (I can't recall about questions) [16:35] All of bugs, questions, and merge proposals are distressingly separate here [16:36] So that case (sensitive info) is covered. I just want to have the ability to edit my own comments because I tend to have additional thoughts or notice typos after I post. [16:36] Partially covered, because only bugs (or possibly only bugs and questions0 [16:36] yeah that's a problem too [16:36] (Why are the three mechanisms separate code-wise?( [16:36] This is quite a big project. I'd suggest trying to identify smaller pieces that you can tackle in smaller units [16:37] Sure. I would start just on the bugs since that's what we use the most. [16:37] Aim for each change to come in at 800 lines max [16:37] Partly because somewhat different requirements; partly because they were initially built by different subteams [16:38] ...and nobody is interested in a giant refactor I'm sure. :) [16:38] They're not totally separate, but certainly not as well-factored as they could be [16:39] Funnily enough, I haven't yet found out what language LP is written in. I'm assuming Python? [16:39] Yes [16:39] three quarters of a million lines of it [16:39] Not to scare you. :-) [16:40] Nah, Mixxx is pretty big as well, though it's C++. (We use Python for the Scons build system though.) [16:40] (Some dependencies have bits of C and such for performance, but it's almost entirely Python, built on the Zope stack.) [16:41] Is LP still actively developed? I noticed last-changed dates on some wiki pages like the roadmap are years ago. [16:41] I apologise in advance for the extremely slow bootstrap process. It'll get better once we've finished switching to git, but I'm waiting for our sysadmins to find time to get to my buildbot upgrade ticket before we can make further progress on that ... [16:41] You can look at http://bazaar.launchpad.net/+branch/launchpad/changes to see commit dates, which are somewhat more accurate [16:42] Yeah... bazaar's slowness on LP is the reason we no longer host our code there [16:42] (That and git's merge wizardry) [16:42] LP had its staffing heavily cut a few years back, and it's certainly a much smaller team than it was, but there are still a couple of us working on it. [16:43] (And several major features that have been developed since that cut) [16:43] Okay that's good to know. It has its strong points over other code-hosting/collaboration sites which is why we still use it [16:44] But we do indeed miss the integration of bugs and code/branches [16:45] Right, that was what first sold me on LP as an Ubuntu developer ten years ago or so :) [16:45] * Pegasus_RPG wonders if other sites expose enough info to be able to have LP yank the needed info over their APIs... [16:45] We do import a bunch of stuff. [16:46] Not anything like merge proposals, though. [16:46] Yeah... the biggest reason we use the other site we do is the ease of doing merge proposals, discussions, comments, etc. [16:47] It would at least be great if LP could monitor the APIs and auto-link a bug to someone's merge proposal on the other site. [16:47] But one thing at a time. :) [16:48] I assume there are plans to have LP work as seamless with Git as it does with Bazaar? [16:49] Pegasus_RPG: It almost does today. Just a few remaining bits of parity and some tidying up of the merge proposal UI. [16:49] oh sweet [16:50] I think the only missing features are translations integration, useful subscriptions, and RSS feeds. [16:51] On that train of thought, I told LP to import our trunk from the other site, and it did, along with the branches, but there's no facility to specify in a series that the code for that series is in one of those already-imported branches. Should I file a bug on this? [16:51] For Bazaar or Git? [16:51] Git [16:51] "If the code is already in a Bazaar branch registered with Launchpad link the branch to this series. " I need that but for Git [16:52] The association with Git branches is somewhat deliberately weaker than with Bazaar. [16:52] Mainly because Git branches are more ephemeral in database terms, and often in practice too. [16:52] Why specifically do you need a hard database-level association (as opposed to e.g. writing something in the series description)? [16:52] How so? We treat our git branches pretty much like we did Bazaar ones [16:52] we make them for stable release series as well as bug fixes [16:53] LP doesn't get to intervene when git branches are deleted in the same way that it does when bzr branches are deleted [16:53] So having a hard association with a series is problematic [16:53] Oh I guess I don't. It would just make it more convenient to see the link on the series page in the same place. [16:54] https://bugs.launchpad.net/launchpad/+bug/1580167 [16:54] Bug #1580167: Hide the "Code for this series" UI in projects that are configured to use git

[16:54] (That said, we might need to tackle this if we do translations integration) [16:55] (BTW, mup is including the > in the URL, making it not directly clickable.) [16:56] I'm not sure I have any idea who runs mup; I /ignore it :-) [16:57] (or it's my IRC client...) [16:57] Testing: [16:57] Bug #1580167: Hide the "Code for this series" UI in projects that are configured to use git

[16:57] yep, my client, sorry [16:58] The convention is reasonably old, although it's always been disputed [16:58] If we did a series link for git, I think we'd have to do the same kind of thing we do for MPs, where you can have a link but the link is allowed to go away. [16:59] i.e. stored as repository + a text column for the branch; the link changes style when it stops referring to anything; and deleting the entire repository checks and either prevents deletion or breaks the link [17:00] Sound good to me [17:01] When one imports a Git tree so it can be reached at lp:project, is it made to look like a bazaar tree to LP or does it fully understand Git at this point? (e.g. if I did bzr branch/checkout lp:project, would that work?) [17:01] It's native. [17:01] No bzr/git translation in either direction is involved. [17:01] ok good [17:01] so that command would fail [17:01] Yes [17:02] lp:turnip (historical reasons ...) is the slightly specialised git server; it uses git send-pack/receive-pack for most of the hard work, but has some translation layers on top. [17:02] e.g. so that we don't have to move storage around when its logical location in the LP taxonomy changes [17:06] okay checkout of lp:launchpad done [17:06] err branch [17:06] You're going from https://dev.launchpad.net/Running/LXD ? [17:06] (If not, I strongly recommend doing so) [17:08] uh no, https://dev.launchpad.net/Getting [17:08] oh crap, thanks for the warning [17:10] * cjwatson edits that a bit [17:13] You can do the Running/LXD bit and then run utilities/rocketfuel-setup inside the container in the branch you now have checked out (possibly moving it into the right place first; you can have it be somewhere other than that page says, but you need to adjust ~/.rocketfuel-env.sh if so, so depends how strongly you feel about your homedir layout) === frankban is now known as frankban|afk [17:52] I first need to upgrade my kernel, heh [19:20] Does anyone know if there is an OAuth API for LP/Ubuntu One so that we could have people use their LP credentials to access our wiki for example? Searching the Web only refers to the now-defunct one.ubuntu.com service. [19:21] Similarly, can people use other OAuth ID providers (e.g. Facebook) to log in to Launchpad? [19:24] Other services can authenticate against login.ubuntu.com, which is the same as login.launchpad.net (just a different frontend hostname). [19:24] However, it is not possible to use other providers to sign in to Launchpad. [19:25] login.ubuntu.com is an OpenID provider. [19:25] https://help.launchpad.net/YourAccount/OpenID [19:27] OpenID 2.0 or OpenID Connect? [19:27] looks like 2.0 [19:32] Unfortunately that is falling out of favor and OpenID Connect (based on OAuth) is taking its place