Re: [Tails-project] [Tails-dev] GitLab is now in production

Delete this message

Reply to this message
Author: intrigeri
To: The Tails public development discussion list
CC: Public mailing list about the Tails project
Subject: Re: [Tails-project] [Tails-dev] GitLab is now in production

(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:

>  * 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?