[00:09] hrrm ... something funny happening with the function to "This bug affects 1 person. Does this bug affect you? " mark as affects me too [00:09] if opin in new tab and use window that way... get error:- [00:09] Timeout error [00:09] Sorry, something just went wrong in Launchpad. [00:09] (Error ID: OOPS-83c7013fe3bbdb2b34e2c5afbc6d17df) [00:09] https://oops.canonical.com/?oopsid=OOPS-83c7013fe3bbdb2b34e2c5afbc6d17df [00:10] No doubt that will help somebody figure out the problem(s) =) === jamesh_ is now known as jamesh === pieq_ is now known as pieq === cpaelzer__ is now known as cpaelzer === pieq_ is now known as pieq === pieq_ is now known as pieq === cjwatson changed the topic of #launchpad to: Help contact: cjwatson (09:30-17:30 UTC Mon-Fri) | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support and spam reporting: https://answers.launchpad.net/launchpad [11:03] cjwatson: o/ Happy New Year! I'd like to chat to you about git-ubuntu plans to automatically find uploaders' git commit on import please. Not urgent - I'd deferred looking at this until after the holiday period. We've discussed some different approaches IIRC, and I don't recall what we settled on. I'm ready to implement in git-ubuntu in the next couple of months. [11:04] rbasak: I, uh, don't remember anything about this right now, so might need a reminder [11:05] It was a long time ago. [11:06] The user story is: an uploader does work based on a git-ubuntu branch (eg. ubuntu/devel), is ready to upload it, and wants to see the git-ubuntu branch update with their own commits, rather than a synthesized one. [11:06] When git-ubuntu sees the Launchpad publication, it needs some way to locate a commit that the uploader will need to have left somewhere. [11:07] Ah, so the equivalent of the Dgit field in Debian .changes files? [11:07] Right now we use this "upload tag" hack that I'd like replace with something nice [11:07] Yes [11:07] One thing we talked about was to put something in the changes file [11:08] But then we still need a mechanism to locate the repository to pull the commit from [11:08] Right [11:08] So another bit of metadata in the changes file, or an API call in Launchpad to find a repository given a commit hash [11:08] IIRC wgrant was there too, and mentioned something about it not being too difficult to implement such a call? [11:08] I think there was some other approach proposed too, which didn't use the changes file [11:09] I'd be surprised if wgrant had been happy with such a thing [11:09] It sounds scary [11:09] And not obviously easy [11:09] Another thought (maybe related): git-ubuntu could look for suitable MPs that appear approved according to some criteria [11:09] I could do that without changes in Launchpad right now maybe [11:10] But it would require uploaders to push an MP, which some uploaders won't want to bother with I expect [11:10] In git-ubuntu I now have a place where I can hook all of this very easily, including using multiple methods [11:11] Since there's just a "here's a publication, add the rich history to the local repository and return a commit hash" function now. [11:11] My instinct is that this sort of thing fits well as metadata in .changes, though I agree it would need to be well-specified (e.g. the syntax should probably support non-LP repositories, even if the initial implementation doesn't) [11:12] Do you have a good way to get the .changes for a given primary archive publication at the moment? [11:13] I haven't thought it through [11:13] I have a source_package_publishing_history reference [11:14] And some snippets of code to follow that through pocket copies to get to a package_upload [11:14] I think [11:16] For an initial implementation maybe pocket copies aren't important to implement. [11:16] There's always the fallback of synthesizing a commit [11:16] So in that case, I think I can get the changes file for a straightforward upload [11:16] spph.package_upload.changes_file_url? [11:17] Something like that. We could probably also ingest the relevant field and arrange for it to be published more directly on the API if needed. [11:18] Does Launchpad need adjusting to pass new changes file fields through? [11:26] It doesn't need adjusting to simply preserve them in changes_file_url. It would need adjusting if we wanted it to parse them in any way. [11:26] I don't think I need Launchpad to parse them. [11:27] I'm imagining two fields (semantically at least, whether collapsed into one or not). URL to the git repository, and commit-ish [11:27] And I think that's all I need, if everyone is happy with that. [11:28] Should be an actual commit rather than a commit-ish. [11:28] *actual commit ID [11:29] I'm OK with that, but wouldn't mind a sanity-check from wgrant. [11:29] actual commit> Yes, on reflection, I agree. It should be locked in. [11:30] You'll presumably need to consider things like what happens if, by the time git-ubuntu gets to it, the repository in question doesn't exist or doesn't have the relevant commit or is private. [11:30] Initially I could have git-ubuntu require the URL to match a regexp or something [11:30] Yes - in that case I'll fall back to a synthesized commit [11:30] It's a very optional thing, and I'm already accepting that the resulting importer output mutates if the availability of the rich history changes [11:31] (in the upload tag hack we're using now) [11:31] Perhaps ideally don't fall back if the error can be identified as temporary [11:31] 5xx, say [11:31] Not 4xx? [11:32] 4xx -> you screwed up 5xx -> we screwed up [11:32] OK [11:32] I see [11:32] Currently I don't have a concept of a temporary failure. [11:32] Very roughly :-) [11:32] However, I can fail the import entirely [11:32] And it's idempotent [11:32] So it will catch itself up [11:32] You may also be using launchpadlib, in which case it will back off and retry [11:32] That would do for now [11:32] At least for some errors [11:32] Depends on the length of an outage I guess [11:33] There's a watchdog that kills an import attempt after a few hours [11:34] So it will catch itself up> when it picks up the subsequent publication, which admittedly may not happen. But we do watch the errored import "log" === hellswor1 is now known as hellsworth === ijohnson is now known as ijohnson|lunch === ijohnson|lunch is now known as ijohnson