=== pabs3 is now known as Guest616
[09:47] <laney> using the api, what's the best way to go from an spph to its build records? i'm finding that getBuilds() isn't populated if the package was copied forward (i.e. built in a previous series). currently I am going through the bpphs back to the build record but this is quite slow.
[09:48] <laney> as you get one bpph for each (binary, arch) built from the source
=== JanC_ is now known as JanC
[12:26] <cjwatson> Ugh, that's all pretty awful.  The same-series restriction seems pretty arbitrary given that it _does_ return builds that were built in a different archive and copied into the SPPH's archive.
[12:27] <cjwatson> There would probably be some fallout from fixing it, but that inconsistency between series and archives does seem like a bug.
[12:27] <cjwatson> laney: ^
[13:53] <rbasak> cjwatson: thank you for triaging bug 1993290. For this and (just filed) bug 1993303, it might be worth specifying exactly how git-ubuntu staging will work, before you commit to effort. But my suspicion is that both of these will make sense and be part of any solution.
[13:53] -ubottu:#launchpad- Bug 1993290 in Launchpad itself "git repository ACLs do not support a 'person who can upload this package' type" [High, Triaged] https://launchpad.net/bugs/1993290
[13:53] -ubottu:#launchpad- Bug 1993303 in Launchpad itself "Cannot set default git ACLs for a team" [Undecided, New] https://launchpad.net/bugs/1993303
[14:29] <rbasak> might be worth specifying exactly how git-ubuntu staging will work> I mean I will have to specify it, not you :)
[14:29] <rbasak> But that's perhaps a conversation to have.
[15:47] <cjwatson> rbasak: heh, so I'd independently put something quite similar to the second of those on our roadmap for another reason.  Useful, thanks.  Does it need to be per-team as well as per-distribution?
[15:52] <rbasak> cjwatson: what would per-distribution and not per-team mean? AIUI, repositories are attached to teams, and only via distributions via the default target setting. So if it were per-distribution only, wouldn't it be confusing that effective ACLs change if the default changes?
[15:53] <rbasak> Oh, that's not quite right.
[15:53] <rbasak> Of course a repository has a target distribution regardless of the default and that doesn't change.
[15:54] <rbasak> But still, wouldn't it be confusing for the target to determine the repository ACL in effect, instead of the team's settings?
[15:54] <rbasak> From my POV, I'd expect to be able to set the default ACL based on git-ubuntu's requirements, rather than the distribution as a whole.
[15:55] <rbasak> That way it would be guaranteed not to impact non git-ubuntu workflows.
[16:06] <cjwatson> rbasak: I'd been thinking of a default policy that the distribution owner could set for all default repositories for all packages, regardless of who owns them.  That seems like a reasonable thing for a distribution owner to be able to do, in general
[16:07] <cjwatson> rbasak: But I can see we might want to refine this and make sure we've joined all the dots
[16:07] <rbasak> cjwatson: that could work for git-ubuntu, but I think it depends on some specifics.
[16:08] <rbasak> If we implement staging using some subset of the branch namespace in the official git-ubuntu repositories themselves, then I think it would be tricky, since the ACL would need to encode our schema for the branch namespace, which would be git-ubuntu specific.
[16:08] <rbasak> But I don't like that approach anyway, because I think it overloads the official repository namespace.
[16:09] <rbasak> OTOH, if we use some other team's repositories with the same Ubuntu+package target for staging repositories, then the entire namespace would be available to that team, so there wouldn't have to be anything in the default ACL to encode some kind git-ubuntu workflow specific branch name schema.
[16:10] <rbasak> In that case I think it would be sufficient to be distribution specific only. But I need to think about it some more.
[16:10] <cjwatson> rbasak: breakout session with a whiteboard next week sometime maybe?
[16:11] <rbasak> Yes please. With vorlon too if possible.
[16:21] <cjwatson> scheduled
[16:22] <rbasak> Thanks!
=== blaze1 is now known as blaze
[16:50] <vorlon> rbasak, cjwatson: I'm not in Prague physically next week and this is at 2am my time.  Hopefully my last feedback by email to rbasak was clear enough that y'all can run with it without me
[16:50] <rbasak> Ah, sorry, OK.
[16:51] <rbasak> vorlon: how would you feel about a staging area being defined but owned by a separate team, parallel to but not part of the git-ubuntu repositories?
[16:51] <cjwatson> vorlon: I just picked the first free slot in the calendar - is there a time you intend to overlap?  (But we can probably consider you as optional)
[16:51] <rbasak> I'd expect to automatically add it as a remote with "git ubuntu clone"
[16:53] <vorlon> cjwatson: I am provisionally attending the Foundations roadmap session in the afternoon which is 4:30am my time, so maybe right after that?
[16:54] <vorlon> rbasak: I certainly don't have a horse in the race when it comes to launchpad namespace questions here :) what I care about is that 'git ubuntu clone' gives me the right thing when checked out, and then something reasonably close to 'git push' does the right thing for pushing to the staging area (details TBD, because of course I would also like a dgit-like 'push' to work for pushing to the archive)
[16:56] <rbasak> vorlon: OK, thanks. One other issue I'm not sure how to solve yet is that the staging branch wouldn't exist until someone wants to stage something. So it's awkward to present the right thing to a user by default (ie. a local branch based on git-ubuntu ubuntu/devel if nothing is staged, or a local branch based on the staging branch if something is staged).
[16:57] <cjwatson> vorlon: hmm, can we maybe make it half an hour immediately after the PM break if you don't mind skipping the two foundations standups at that time?  And we can stretch into the following half-hour slot if we need to
[16:57] <rbasak> I might have to code the logic into "git ubuntu clone" which I don't like particularly, but I don't see a way of solving that with git configuration alone.
[16:57] <vorlon> right, I would expect this logic to happen in 'git ubuntu clone', sorry :)
[16:57] <rbasak> OK
[16:58] <rbasak> Those were the main reasons I wanted you involved.
[16:58] <rbasak> But it sounds like you don't mind too much of the implementation details apart from the final UX.
[16:59] <vorlon> cjwatson: welllll I don't normally attend those standups anyway which are 7am my time so I certainly don't miss them.  I am certainly open to trying to attend at that time, I just can't commit because I'm not doing a full time-shift due that week given my other committment Tuesday-Thursday
[16:59] <vorlon> rbasak: quite
[16:59] <vorlon> so I might wake up at 4am and pass out again by 6
[16:59] <cjwatson> vorlon: OK, understood, I'll move to that time so that at least it's in principle possible for you, and mark you optional
[16:59] <rbasak> So maybe it's OK for you to skip if it's awkward, and hopefully there won't be any major objections on a final spec when I have that ready.
[17:15] <laney> cjwatson: alright, cheers. do you happen to know if there's a bug for this already or should I file one?
[17:16] <cjwatson> laney: I was about to say no, but seems like there's an old one where people were just as perplexed as me about what those constraints were doing there: https://bugs.launchpad.net/launchpad/+bug/783613
[17:16] -ubottu:#launchpad- Launchpad bug 783613 in Launchpad itself "SPPH.getBuilds only returns builds in the same series" [Low, Triaged]
[17:16] <laney> oh nice, ye olde buge