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 <[email protected]> (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 [email protected]. > > 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! _______________________________________________ Tails-dev mailing list [email protected] https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
