Re: [Tails-dev] GitLab is now in production
Hi, intrigeri (2020-05-29): > Where to ask questions and report problems > == > > There are most certainly some rough edges, confusion, and bugs caused > by this migration, so: > > - If you have questions or trouble with the new *workflow*, please >either email or attend one of the two "Ask Me >Anything" sessions I'll host on the tails-dev XMPP chatroom: > > - Wednesday, June 3, 11:00-12:00 CEST This happened. Here are the notes I took: - confusion about project-level and group-project settings (e.g. labels) → https://gitlab.tails.boum.org/tails/tails/-/issues/17753 should fix that - Q: Can I save custom queries for the issue lists? A: Not really. there's the "Recent searches" thing, but apart of that the best we can do is store useful URLs in other places. See for examples the links on https://tails.boum.org/contribute/working_together/roles/foundations_team/ - Q: "Create merge request" button on an issue creates a branch that, by default, does not follow our branch naming standards. A: One can click the "↓" button to choose a different branch name. Also, perhaps we could be less rigid wrt. our branch naming standards? Other ways to create a merge request while choosing the branch name: - push one's branch and click the link that "git push" displays, which offers to create a MR - push one's branch with Git push options: https://docs.gitlab.com/ee/user/project/push_options.html#push-options-for-merge-requests Next one is tomorrow: > - Thursday, June 4, 16:00-17:00 CEST > > - If you encounter *bugs* in the GitLab setup or *security issues*, >please instead email . > > Thanks for your patience, > cheers, ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GitLab is now in production
Hi, Cyril Brulebois (2020-06-01): > I'll share some more, spotted during the last few days and while > finalizing the contents of 4.7 thanks to anonym's help: > > * It would be nice if we could close tickets from a commit message, >e.g. when merging a branch, as we used to be able to with “Closes: >#N”. It might not be important on the long run if we standardize for >always using a MR, but I'd be happy not to have to remember closing >tickets manually while we deal with the many topic branches we have. >Various attempts seems to have failed (d4ffd3ebc60c, 7f5361119001). > > * One might think “just use a MR” as a reply to the aforementioned >point but right now, I'm not convinced… The commit message doesn't >mention bug(s) getting fixed, doesn't contain a direct link to the >MR, and just a reference the interested reader needs to resolve on >their own. Of course, for single-bug topic branches, the name might >be sufficient. For longer-lived branches (overlayfs, secure boot, >etc.), I'm pretty sure all bugs won't be mentioned in the branch's >name. I hear you and I personally find these problems annoying as well. To sum up what I see: - Regarding "mention all relevant issues in the commit message", one workaround is to do what we would have done pre-GitLab, that is: manually edit the merge commit message to include the desired info (be it via the GitLab web UI or by merging locally). But of course it would be better to automate this! - We do have a regression wrt. closing issues while merging, compared to Redmine. I've looked deeper into this topic a couple days ago after our conversation on XMPP, and here's what I found: 1. The "close referenced issues when merging" behavior only works for the main branch, i.e. currently "master" in our case. One lead I'd like to investigate is making "devel" our main branch (and in passing, perhaps rename "master" to "website"). I did not verify what would happen under that config in the most common scenarios, that is when the target branch of the MR is stable, and then one merges stable manually into devel. 2. When merging a MR into the main branch, the merge commit message generated by GitLab does mention the issues being closed. Example: commit 12fdeb9995503b0263134f8284f8aeebc284b7b0 Merge: bc4dcec41b 015ef0767f Author: intrigeri Date: Sat May 30 06:02:49 2020 + Merge branch 'feature/17133-update-signing-key' into 'master' Bump our signing key's expiration date Closes #17133 See merge request tails/tails!17 But that's not the case when merging into a non-main target branch, and I've found no way to customize this (it seems fully hard-coded in GitLab's code). So for now, manually editing the commit message (i.e. like we did with Redmine) is the only way to go. All this seems to boil down to GitLab being optimized for 1-main-branch workflows. I'd like to spend some time thinking about how we could adjust our workflow to fit better. I'll focus on the regression (closing issues via merge commits) to start with. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GitLab is now in production
Hi, sajolida (2020-05-29): > intrigeri: >> - Our translation platform is not integrated with GitLab yet. > > What are the practical implications of this? > > Strings are not automatically updated in Weblate and translations in > Weblate are not automatically applied to the website? I believe that's correct but I'm not sure I'm up-to-date, so adding zen to the loop. ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GitLab is now in production
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 (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-sysadm...@boum.org. > > 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 Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GitLab is now in production
Hi, Cyril Brulebois (2020-05-29): > > Where to ask questions and report problems > > == > > > > There are most certainly some rough edges, confusion, and bugs caused > > by this migration, so: > > > > - If you have questions or trouble with the new *workflow*, please > >either email or attend one of the two "Ask Me > >Anything" sessions I'll host on the tails-dev XMPP chatroom: > > > > - Wednesday, June 3, 11:00-12:00 CEST > > - Thursday, June 4, 16:00-17:00 CEST > > I'll try and join the sessions, even if the first one seems early in the > day, and a little close to the 4.7 release. > > > The following items don't call for immediate replies, I'm merely > mentioning them right now as “food for thoughts”: > > * On MRs: “Comment” vs. “Start thread” → maybe make “Start thread” the >default if that's possible? > > * 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.) > > * 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'll share some more, spotted during the last few days and while finalizing the contents of 4.7 thanks to anonym's help: * It would be nice if we could close tickets from a commit message, e.g. when merging a branch, as we used to be able to with “Closes: #N”. It might not be important on the long run if we standardize for always using a MR, but I'd be happy not to have to remember closing tickets manually while we deal with the many topic branches we have. Various attempts seems to have failed (d4ffd3ebc60c, 7f5361119001). * One might think “just use a MR” as a reply to the aforementioned point but right now, I'm not convinced… The commit message doesn't mention bug(s) getting fixed, doesn't contain a direct link to the MR, and just a reference the interested reader needs to resolve on their own. Of course, for single-bug topic branches, the name might be sufficient. For longer-lived branches (overlayfs, secure boot, etc.), I'm pretty sure all bugs won't be mentioned in the branch's name. Recent examples: ,--- | commit c59cd2a32e3c524e3b5b08dd5e87f57d1b63d5ca | Merge: 49497a9f28 931dd90d88 | Author: anonym | Date: Mon Jun 1 08:53:05 2020 + | | Merge branch 'feature/17710-tor-browser-9.5+force-all-tests' into 'stable' | | Upgrade to Tor Browser 9.5 | | See merge request tails/tails!27 `--- ,--- | commit 49497a9f285ee89e76f3155b1955061181dd1c20 | Merge: d4ffd3ebc6 9cae0960c5 | Author: anonym | Date: Mon Jun 1 08:46:56 2020 + | | Merge branch 'test/17718-17719-new-homepage-and-gitlab+force-all-tests' into 'stable' | | Update test suite for new homepage and migration to GitLab | | See merge request tails/tails!25 `--- Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GitLab is now in production
intrigeri: > To follow the transition instructions, see: > > https://tails.boum.org/contribute/working_together/GitLab/transition/ Very useful! The full list and the `git remote set-url` command is much easier that editing each .git/config file by hand as I've been doing during the week :) > 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-sysadm...@boum.org. Aaahhh! I've been wondering twice already whether the website was broken when my changes were not reflected :) > - Our translation platform is not integrated with GitLab yet. What are the practical implications of this? Strings are not automatically updated in Weblate and translations in Weblate are not automatically applied to the website? -- sajolida Tails — https://tails.boum.org/ UX · Fundraising · Technical Writing ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GitLab is now in production
Hi, intrigeri (2020-05-29): > This was announced to core contributors last week, let's now make this > official: we've switched to GitLab! mmm m m m" " mmm m mm m mm mmm mm#mm mmm # # #" "# #" # #" "# #" " " ### "# # # # # # # # # m"""## """m" "mmm" "#m#" # # "#m"# # "mm"#"mm "mmm"# m # "" > What was migrated > = > > We have migrated: > > - all information that previously lived on Redmine, >such as issues, milestones, and user accounts > > - many, but not all, of our Git repositories Right, I think half of my repositories had to stay the same (which arguably shouldn't be the case for most contributors). The transition was quite smooth though, and rather quick (even if manual). > 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-sysadm...@boum.org. 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. > Where to ask questions and report problems > == > > There are most certainly some rough edges, confusion, and bugs caused > by this migration, so: > > - If you have questions or trouble with the new *workflow*, please >either email or attend one of the two "Ask Me >Anything" sessions I'll host on the tails-dev XMPP chatroom: > > - Wednesday, June 3, 11:00-12:00 CEST > - Thursday, June 4, 16:00-17:00 CEST I'll try and join the sessions, even if the first one seems early in the day, and a little close to the 4.7 release. The following items don't call for immediate replies, I'm merely mentioning them right now as “food for thoughts”: * On MRs: “Comment” vs. “Start thread” → maybe make “Start thread” the default if that's possible? * 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.) * 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… Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] GitLab is now in production
Hi! This was announced to core contributors last week, let's now make this official: we've switched to GitLab! Table of contents = - What was migrated - What you should do now - Known issues - Where to ask questions and report problems What was migrated = We have migrated: - all information that previously lived on Redmine, such as issues, milestones, and user accounts - many, but not all, of our Git repositories What you should do now == To follow the transition instructions, see: https://tails.boum.org/contribute/working_together/GitLab/transition/ The documentation about how we use GitLab starts there: https://tails.boum.org/contribute/working_together/GitLab/ 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-sysadm...@boum.org. - Our translation platform is not integrated with GitLab yet. Where to ask questions and report problems == There are most certainly some rough edges, confusion, and bugs caused by this migration, so: - If you have questions or trouble with the new *workflow*, please either email or attend one of the two "Ask Me Anything" sessions I'll host on the tails-dev XMPP chatroom: - Wednesday, June 3, 11:00-12:00 CEST - Thursday, June 4, 16:00-17:00 CEST - If you encounter *bugs* in the GitLab setup or *security issues*, please instead email . Thanks for your patience, cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
