=== chihchun_afk is now known as chihchun
=== pbek_ is now known as pbek
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
[13:55] <gQuigs> trying to login to staging.launchpad.net -> login-lp.staging.ubuntu.com, but it doesn't seem to like my password from prod
[13:56] <gQuigs> following this doc - https://help.launchpad.net/StagingServer, and I know I've logged into staging before...
[13:58] <gQuigs> aside: my actual goal is to test out using teams that automatically expire to assert that someone (likely employees) has reviewed certain documents every 3 months or year, etc  - then compare it against their primary group to see those that haven't done the required action
[14:01] <cjwatson> gQuigs: that's an SSO problem, not Launchpad
[14:02] <cjwatson> and if 2FA is involved, then https://help.ubuntu.com/community/SSO/FAQs/2FA#Why_doesn.27t_my_2F_login_work_on_staging.3F will apply
[14:03] <cjwatson> gQuigs: but if you're planning to compare team memberships on production vs. staging, are you aware that staging is resynced from production once a week?
[14:05] <gQuigs> cjwatson: oh yea, I just want to mock it up on staging, not use that for the comparison
[14:06] <cjwatson> gQuigs: you could alternatively mock it up on qastaging then, which uses production SSO, thereby sidestepping whatever the problem is with your staging SSO account
[14:07] <gQuigs> cjwatson: tried, I can't get qastaging.launchpad.net to load
[14:09] <gQuigs> or am I using the wrong URL?
[14:10] <cjwatson> it's possible it's currently broken; it's had some problems
[14:10] <cjwatson> OK, you can try dogfood.paddev.net then, with the caveat that that has even fewer guarantees of being up, it's a dev playground
[14:11] <cjwatson> somebody on #snapstore may be able to help you fix your staging SSO account
[14:12] <gQuigs> np, that works, thanks!
[14:24] <gQuigs> if you have any thoughts on the best way in LP to have everyone on a team signoff on something I'd love to hear it (currently evaluating the groups options, but perhaps blueprints or code could be messaged to do similar
[14:35] <cjwatson> I have no such thoughts
[14:38] <gQuigs> no one has customized the Code of Conduct signing system for other purposes?  it's not per project afaict
[14:38] <cjwatson> Not as far as I know
[15:34] <Laney> is it possible to configure codehosting deny non fast forward git pushes?
[15:34] <Laney> ideally on a per-branch basis
[15:35] <Laney> sort of https://bugs.launchpad.net/launchpad/+bug/1604558 I guess
[15:35] <ubot5`> Ubuntu bug 1604558 in Launchpad itself "[git] Team admins cannot ban "force push"" [Undecided,New]
[15:35] <Laney> although I wouldn't be asking for an ACL like that
[15:37] <nacc> Laney: we've asked for something similar-ish in the past for git-ubuntu
[15:37] <Laney> nacc: probably that bug I just linked
[15:37] <Laney> basically "no" AFAICS
[15:37] <nacc> Laney: yeah, we also have changed our model a bit, and the branches are now never pushed by anyone outside the importer-team (really just the bot now)
[15:38] <nacc> Laney: so it's dropped down our list a bit
[15:40] <Laney> nacc: It's not super urgent for me either, just that sometimes people will reset and push --force rather than reverting, because it's "cleaner" or something. I'd like to prevent that, at least for our ubuntu/* branches. (Since we're planning to move to git for desktop packaging soon.)
[15:41] <nacc> Laney: yep, agreed on that
[15:41] <nacc> Laney: are these source packages, btw?
[15:42] <Laney> We're going to be sharing gbp history with Debian.
[15:42] <nacc> Laney: and yeah reset & push should be very frowned upon :)
[15:42] <Laney> Using DEP14 style layouts
[15:43] <nacc> Laney: we are changing the 'default' Git repository for imported source pacakges (about to be all of main) to our imported repositories -- would you rather we didn't for yours? (they will still obviously be there, just not the default, if not)
[15:43] <nacc> Laney: the idea being every source package in main has the git-ubuntu layout, so it's always possible to use that workflow
[15:44] <Laney> nacc: Hmmmmmmmm, I'm not sure.
[15:44] <Laney> There's benefit to having it be identical for all packages, and us having to deal with random non-workflow uploads.
[15:46] <nacc> Laney: yeah
[15:46] <Laney> But then again we might want to steer people towards the official VCSen
[15:46] <nacc> Laney: which you can do in the debian/control still, i think
[15:46] <nacc> Laney: what we'd do if you wanted to make yours the default is special-case those source packages and emit a message like, the 'default repo is at ... '
[15:46] <nacc> (in git-ubuntu)
[15:47] <Laney> nacc: That'd be nice, kind of like what apt source does - except you can't just use Vcs-* as that's often unmodified from Debian.
[15:48] <nacc> Laney: (i have a pending MP to allow update-maintainer to understand vcs changes too)
[15:48] <nacc> Laney: so, for now, i won't special case anything, but if you change your mind, just reach out to rbasak or myself
[15:48] <Laney> ack
[15:56] <nacc> Laney: just filed LP: #1765114 to track that a bit for ourselves
[15:56] <ubot5`> Launchpad bug 1765114 in usd-importer "importer: default alias change has some fallout" [Undecided,New] https://launchpad.net/bugs/1765114
=== sakrecoe1 is now known as sakrecoer
[21:02] <rbasak> nacc, Laney: I'd really prefer for it to be the other way round: the default repository to be our one (a consistent view across all packages). But we can point to the desktop team's one in a message after clone. My reason is that it's really hard to encourage new contributors when everything is an edge case.
[21:02] <nacc> rbasak: fwiw, default repository is ours (or will be)
[21:02] <nacc> rbasak: agreed re: messaging, as mentioned in the bug
[21:02] <nacc> rbasak: i wonder if we should emit a warning if the current branch's VCS field is not ours or something
[21:03] <rbasak> I'd like us all to accept contributions made against the consistent view (git-ubuntu) branches, too. For teams that maintain the "real" VCS somewhere else, I'd like these teams to handle the MP and rebase on to the "real" branch before merging if necessary.
[21:03] <nacc> rbasak: +1
[21:04] <rbasak> nacc: we can warn using Vcs-*, but one catch is that Ubuntu developers rarely mark XS-Vcs-Debian or whatever so we can't tell the difference.
[21:04] <rbasak> This is something I think update-maintainer should do (and for it to be renamed).
[21:04] <nacc> yeah that's a good point
[21:04] <nacc> rbasak: ack, that's what my MP for update-maintainer does (needs to be resubmitte,d probably)
[21:06] <rbasak> Another thought on what I said above: we could even have "git ubuntu lint" and a CI bot handle the rebasing on to the "real" branch automatically.
[21:06] <rbasak> (using Vcs-* when that's sorted)
[21:08] <nacc> rbasak: yeah, that's a good idea (or even a suggested set of commands, perhaps)
=== mwhudson is now known as Guest20250
=== Guest20250 is now known as mwhudson_