| === 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 | ||
| 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:55 |
|---|---|---|
| gQuigs | following this doc - https://help.launchpad.net/StagingServer, and I know I've logged into staging before... | 13:56 |
| 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 | 13:58 |
| cjwatson | gQuigs: that's an SSO problem, not Launchpad | 14:01 |
| 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:02 |
| 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:03 |
| gQuigs | cjwatson: oh yea, I just want to mock it up on staging, not use that for the comparison | 14:05 |
| 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:06 |
| gQuigs | cjwatson: tried, I can't get qastaging.launchpad.net to load | 14:07 |
| gQuigs | or am I using the wrong URL? | 14:09 |
| 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:10 |
| cjwatson | somebody on #snapstore may be able to help you fix your staging SSO account | 14:11 |
| gQuigs | np, that works, thanks! | 14:12 |
| 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:24 |
| cjwatson | I have no such thoughts | 14:35 |
| 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 | 14:38 |
| Laney | is it possible to configure codehosting deny non fast forward git pushes? | 15:34 |
| Laney | ideally on a per-branch basis | 15:34 |
| 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:35 |
| 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:37 |
| nacc | Laney: so it's dropped down our list a bit | 15:38 |
| 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:40 |
| nacc | Laney: yep, agreed on that | 15:41 |
| nacc | Laney: are these source packages, btw? | 15:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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 | 15:56 |
| === sakrecoe1 is now known as sakrecoer | ||
| 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:02 |
| 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:03 |
| 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:04 |
| 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:06 |
| nacc | rbasak: yeah, that's a good idea (or even a suggested set of commands, perhaps) | 21:08 |
| === mwhudson is now known as Guest20250 | ||
| === Guest20250 is now known as mwhudson_ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!