Hi,
(keeping tails-project@ in the loop, because I don't know how to
resolve the tension between "not everyone who should read this is on
tails-dev@ so some of us prefer to reply on -project@" and
"tails-project@'s topic is explicitly documented to be for
non-technical matters so this sort of discussions may make it less
welcoming a place for those who are interested in non-technical
matters but not so much in technical details")
Cyril Brulebois (2020-05-29):
> intrigeri <intrigeri@???> (2020-05-29):
>> Known issues
>> ============
>>
>> - Updates to repositories used to build our website (tails.git and
>> any of its underlay repositories, such as mirror-pool.git) are not
>> automatically propagated to our production website. Only sysadmins
>> can manually propagate such updates.
>>
>> So far I've been synchronizing tails.git's master branch to our
>> production website at least once a day. If you need anything beyond
>> that, ask me or tails-sysadmins@???.
>
> Alright! That was my main concern 1 or 2 hours into my transitioned
> Tails world, with an updated calendar that wasn't published, and the
> apparent lack of git hook getting run when pushing. If that's expected,
> all good.
>
> But that means I'll have to sync with sysadmins when publishing the
> release on Tuesday.
>
> Unless something could be cronned to run at least every hour or
> something like that? No pressure or absolute need, just thinking out
> loud.
JFTR, zen implemented a temporary trick that allowed kibi to
workaround this problem during the 4.7 release process.
> * On MRs: “Comment” vs. “Start thread” → maybe make “Start thread” the
> default if that's possible?
I could not find a way to configure this in GitLab.
I'd like to take it easy on this front.
Redmine had no comment threading feature, so:
- every time we use "Start thread", we get some extra benefits
- when we don't use "Start thread" (but should have), we're back to
Redmine experience, i.e. not a regression
> * Probably for release managers mainly/only: How to massively
> unsubscribe, and/or avoid auto-subscribing to issues when changing
> metadata en masse? (Usual “move remaining issues to the next
> milestone” step is likely the reason why I'm receiving bug mail for
> many items I never touched.)
FTR, kibi and I discussed it further elsewhere and I'm working
on a different solution to this problem:
https://gitlab.tails.boum.org/tails/tails/-/issues/17747
> * Avoid link to create MR when pushing a main branch (e.g. stable):
> There's a “Show link to create/view merge request when pushing from
> the command line” setting but it seems global, rather than
> per-branch…
I've checked and only one branch (the "main branch" i.e. "master"
currently) won't display that link. I found no way to configure GitLab
to disable this behavior for other branches. That's a bit unfortunate.
Would you like to file a feature request upstream about this?
Cheers!
