| 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:09 |
| ubot5 | https://oops.canonical.com/?oopsid=OOPS-83c7013fe3bbdb2b34e2c5afbc6d17df | 00:09 |
| enyc | No doubt that will help somebody figure out the problem(s) =) | 00:10 |
| === 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 | ||
| 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:03 |
| cjwatson | rbasak: I, uh, don't remember anything about this right now, so might need a reminder | 11:04 |
| rbasak | It was a long time ago. | 11:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| cjwatson | Do you have a good way to get the .changes for a given primary archive publication at the moment? | 11:12 |
| rbasak | I haven't thought it through | 11:13 |
| rbasak | I have a source_package_publishing_history reference | 11:13 |
| rbasak | And some snippets of code to follow that through pocket copies to get to a package_upload | 11:14 |
| rbasak | I think | 11:14 |
| 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:16 |
| 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:17 |
| rbasak | Does Launchpad need adjusting to pass new changes file fields through? | 11:18 |
| 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:26 |
| 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:27 |
| cjwatson | Should be an actual commit rather than a commit-ish. | 11:28 |
| cjwatson | *actual commit ID | 11:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| rbasak | There's a watchdog that kills an import attempt after a few hours | 11:33 |
| 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" | 11:34 |
| === hellswor1 is now known as hellsworth | ||
| === ijohnson is now known as ijohnson|lunch | ||
| === ijohnson|lunch is now known as ijohnson | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!