[00:09] <enyc> 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] <enyc> if opin in new tab and use window that way... get error:-
[00:09] <enyc> Timeout error
[00:09] <enyc> Sorry, something just went wrong in Launchpad.
[00:09] <enyc> (Error ID: OOPS-83c7013fe3bbdb2b34e2c5afbc6d17df)
[00:10] <enyc> No doubt that will help somebody figure out the problem(s) =)
[11:03] <rbasak> 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] <cjwatson> rbasak: I, uh, don't remember anything about this right now, so might need a reminder
[11:05] <rbasak> It was a long time ago.
[11:06] <rbasak> 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] <rbasak> 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] <cjwatson> Ah, so the equivalent of the Dgit field in Debian .changes files?
[11:07] <rbasak> Right now we use this "upload tag" hack that I'd like replace with something nice
[11:07] <rbasak> Yes
[11:07] <rbasak> One thing we talked about was to put something in the changes file
[11:08] <rbasak> But then we still need a mechanism to locate the repository to pull the commit from
[11:08] <cjwatson> Right
[11:08] <rbasak> 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] <rbasak> IIRC wgrant was there too, and mentioned something about it not being too difficult to implement such a call?
[11:08] <rbasak> I think there was some other approach proposed too, which didn't use the changes file
[11:09] <cjwatson> I'd be surprised if wgrant had been happy with such a thing
[11:09] <cjwatson> It sounds scary
[11:09] <cjwatson> And not obviously easy
[11:09] <rbasak> Another thought (maybe related): git-ubuntu could look for suitable MPs that appear approved according to some criteria
[11:09] <rbasak> I could do that without changes in Launchpad right now maybe
[11:10] <rbasak> But it would require uploaders to push an MP, which some uploaders won't want to bother with I expect
[11:10] <rbasak> In git-ubuntu I now have a place where I can hook all of this very easily, including using multiple methods
[11:11] <rbasak> 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] <cjwatson> 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] <cjwatson> Do you have a good way to get the .changes for a given primary archive publication at the moment?
[11:13] <rbasak> I haven't thought it through
[11:13] <rbasak> I have a source_package_publishing_history reference
[11:14] <rbasak> And some snippets of code to follow that through pocket copies to get to a package_upload
[11:14] <rbasak> I think
[11:16] <rbasak> For an initial implementation maybe pocket copies aren't important to implement.
[11:16] <rbasak> There's always the fallback of synthesizing a commit
[11:16] <rbasak> So in that case, I think I can get the changes file for a straightforward upload
[11:16] <rbasak> spph.package_upload.changes_file_url?
[11:17] <cjwatson> 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] <rbasak> Does Launchpad need adjusting to pass new changes file fields through?
[11:26] <cjwatson> 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] <rbasak> I don't think I need Launchpad to parse them.
[11:27] <rbasak> I'm imagining two fields (semantically at least, whether collapsed into one or not). URL to the git repository, and commit-ish
[11:27] <rbasak> And I think that's all I need, if everyone is happy with that.
[11:28] <cjwatson> Should be an actual commit rather than a commit-ish.
[11:28] <cjwatson> *actual commit ID
[11:29] <cjwatson> I'm OK with that, but wouldn't mind a sanity-check from wgrant.
[11:29] <rbasak> actual commit> Yes, on reflection, I agree. It should be locked in.
[11:30] <cjwatson> 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] <rbasak> Initially I could have git-ubuntu require the URL to match a regexp or something
[11:30] <rbasak> Yes - in that case I'll fall back to a synthesized commit
[11:30] <rbasak> 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] <rbasak> (in the upload tag hack we're using now)
[11:31] <cjwatson> Perhaps ideally don't fall back if the error can be identified as temporary
[11:31] <cjwatson> 5xx, say
[11:31] <rbasak> Not 4xx?
[11:32] <cjwatson> 4xx -> you screwed up   5xx -> we screwed up
[11:32] <rbasak> OK
[11:32] <rbasak> I see
[11:32] <rbasak> Currently I don't have a concept of a temporary failure.
[11:32] <cjwatson> Very roughly :-)
[11:32] <rbasak> However, I can fail the import entirely
[11:32] <rbasak> And it's idempotent
[11:32] <rbasak> So it will catch itself up
[11:32] <cjwatson> You may also be using launchpadlib, in which case it will back off and retry
[11:32] <rbasak> That would do for now
[11:32] <cjwatson> At least for some errors
[11:32] <rbasak> Depends on the length of an outage I guess
[11:33] <rbasak> There's a watchdog that kills an import attempt after a few hours
[11:34] <rbasak> 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"