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

Delete this message

Reply to this message
Autor: Cyril Brulebois
Data:  
Para: The Tails public development discussion list
CC: Public mailing list about the Tails project
Assunto: Re: [Tails-project] [Tails-dev] GitLab is now in production
Hi,

Cyril Brulebois <ckb@???> (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 <tails-dev@???> 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 <anonym@???>
| Date:   Mon Jun 1 08:53:05 2020 +0000
| 
|     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 <anonym@???>
| Date:   Mon Jun 1 08:46:56 2020 +0000
| 
|     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 (ckb@???)