Bug #17172
Clarify usage of Salsa/Gitlab reviews for Tails
0%
Description
Some months ago some people have started using Gitlab, Debian’s instance of it - to be precise, ie. salsa.d.o.
It has been suggested to do reviews there, the FT is already practising this.
Other people could benefit from it too, but I’m afraid that the usage is not entirely clear, at least not to me, see comments on https://salsa.debian.org/tails-team/tails/commit/1163ae808f9b6009b7a446a99dc25d3dd9982477
In the future, we will move everything to Gitlab, so a question for clarification arises even more.
I also see that there are merge requests on this repository: https://salsa.debian.org/tails-team/tails/merge_requests
What’s happening to them? They are open since 5-6 months, so I understand that they are not merged there?
Maybe we should clarify the usage, benefits and expectations of doing reviews over Gitlab’s web interface? In a very informal way, for example, by exchanging best practices or simply writing an email about how this should be used.
Is there any documentation written by/for the FT that clarifies this and that I or other people could read?
Or is this something that we will address by writing contributor documentation once we’ve really moved to Gitlab?
Subtasks
Related issues
|
Related to Tails - |
Resolved | 2018-08-30 | |
|
Related to Tails - |
Duplicate |
History
#1 Updated by Anonymous 2019-10-21 14:21:50
- Subject changed from Clarify usage of Salsa/Gitlab for Tails to Clarify usage of Salsa/Gitlab reviews for Tails
- Description updated
#2 Updated by intrigeri 2019-10-21 19:27:15
Hi!
> It has been suggested to do reviews there, the FT is already practising this.
Right. To be honest, in practice, even on the FT, we’ve used it for a tiny subset of our merge requests:
- Most of our branches are too tiny to be worth the extra paperwork: we still have to keep Redmine up-to-date too. OTOH, some bigger branches were reviewed on GitLab and it’s been occasionally useful.
- The FT members who are more familiar/comfortable with GitLab tend to use it when it makes sense. Other FT members tend to ignore it for now, which is totally OK: it was meant to be an opt-in experiment.
> Other people could benefit from it too, but I’m afraid that the usage is not entirely clear, at least not to me, […]
Right. I’ve tried this once to showcase reviews on GitLab to you but that was premature, as shown by the discussion you’re pointing to and by this very ticket.
I’ve learnt from this experience and did not try again.
> In the future, we will move everything to Gitlab, so a question for clarification arises even more.
Absolutely (see below).
> I also see that there are merge requests on this repository: https://salsa.debian.org/tails-team/tails/merge_requests
> What’s happening to them? They are open since 5-6 months, so I understand that they are not merged there?
You understood correctly that they were not merged yet. Here’s why:
- One is a Work In Progress merge request, i.e. a place to discuss proposed changes that are not ready for prime time. Of course WIP is always a problem but this one only mirrors the exact same problem we have in the corresponding Redmine ticket.
- The other one was created during the FT sprint in April to play a bit with GitLab. anonym did not reply since. I’ve pinged him on XMPP today about it, thanks to your reminder. I’ll close this MR soon unless anonym expresses further interest: he’ll have plenty of other (and more relevant) opportunities to try this new system out :)
Rest assured that more serious/complete merge requests are acted upon under the same conditions as other FT reviews: 34 of them were merged already.
> Maybe we should clarify the usage, benefits and expectations of doing reviews over Gitlab’s web interface? In a very informal way, for example, by exchanging best practices or simply writing an email about how this should be used.
I would love if someone did this. But I can’t personally commit to work on this now, so the GitLab team will have to handle it. As far as I’m concerned, that’s fine: the initial experiment was meant to be an internal FT one and that would be good enough. I apologize for having over-enthusiastically tried to extend it and caused you trouble; but I can’t afford this mistake of mine leading to extra commitments/expectations that I won’t be able to honor.
> Is there any documentation written by/for the FT that clarifies this and that I or other people could read?
Nope. This was meant to be a cheap experiment. I did update https://tails.boum.org/contribute/merge_policy/ a bit but that explains only Tails-specific bits, not general GitLab usage, benefits, and expectations.
> Or is this something that we will address by writing contributor documentation once we’ve really moved to Gitlab?
We will definitely have to do that. Personally, I would advocate in favour of pointing to the official GitLab doc (and improving it if needed), for anything that’s not specific to Tails — just like we did for Redmine. Some starting points may include:
#3 Updated by intrigeri 2019-10-21 19:30:37
- Category set to Infrastructure
- Assignee deleted (
intrigeri)
I hope I’ve clarified current usage sufficiently; if not, please ask :) Regarding future usage, that’s for the GitLab team and we have “update the contributors doc” explicitly listed in the GitLab team’s tasks, so I’m confident we won’t forget. So perhaps this ticket can be closed?
#4 Updated by Anonymous 2019-10-21 19:33:19
- Category deleted (
Infrastructure) - Status changed from New to Rejected
- Assignee set to intrigeri
intrigeri wrote:
> Hi!
>
> > It has been suggested to do reviews there, the FT is already practising this.
>
> Right. To be honest, in practice, even on the FT, we’ve used it for a tiny subset of our merge requests:
>
> * Most of our branches are too tiny to be worth the extra paperwork: we still have to keep Redmine up-to-date too. OTOH, some bigger branches were reviewed on GitLab and it’s been occasionally useful.
> * The FT members who are more familiar/comfortable with GitLab tend to use it when it makes sense. Other FT members tend to ignore it for now, which is totally OK: it was meant to be an opt-in experiment.
Thanks for the clarification :)
> > Other people could benefit from it too, but I’m afraid that the usage is not entirely clear, at least not to me, […]
>
> Right. I’ve tried this once to showcase reviews on GitLab to you but that was premature, as shown by the discussion you’re pointing to and by this very ticket.
> I’ve learnt from this experience and did not try again.
Ah ok, I would have been okay with redoing it, but I lack pointers on how to get the best parts out of it.
> > In the future, we will move everything to Gitlab, so a question for clarification arises even more.
>
> Absolutely (see below).
>
> > I also see that there are merge requests on this repository: https://salsa.debian.org/tails-team/tails/merge_requests
> > What’s happening to them? They are open since 5-6 months, so I understand that they are not merged there?
>
> You understood correctly that they were not merged yet. Here’s why:
>
> * One is a Work In Progress merge request, i.e. a place to discuss proposed changes that are not ready for prime time. Of course WIP is always a problem but this one only mirrors the exact same problem we have in the corresponding Redmine ticket.
> * The other one was created during the FT sprint in April to play a bit with GitLab. anonym did not reply since. I’ve pinged him on XMPP today about it, thanks to your reminder. I’ll close this MR soon unless anonym expresses further interest: he’ll have plenty of other (and more relevant) opportunities to try this new system out :)
Ack.
> Rest assured that more serious/complete merge requests are acted upon under the same conditions as other FT reviews: 34 of them were merged already.
Wow!
> > Maybe we should clarify the usage, benefits and expectations of doing reviews over Gitlab’s web interface? In a very informal way, for example, by exchanging best practices or simply writing an email about how this should be used.
>
> I would love if someone did this. But I can’t personally commit to work on this now, so the GitLab team will have to handle it. As far as I’m concerned, that’s fine: the initial experiment was meant to be an internal FT one and that would be good enough. I apologize for having over-enthusiastically tried to extend it and caused you trouble; but I can’t afford this mistake of mine leading to extra commitments/expectations that I won’t be able to honor.
Understood. So we can keep this as a discussion for a later point in time.
> > Is there any documentation written by/for the FT that clarifies this and that I or other people could read?
>
> Nope. This was meant to be a cheap experiment. I did update https://tails.boum.org/contribute/merge_policy/ a bit but that explains only Tails-specific bits, not general GitLab usage, benefits, and expectations.
Ok.
> > Or is this something that we will address by writing contributor documentation once we’ve really moved to Gitlab?
>
> We will definitely have to do that. Personally, I would advocate in favour of pointing to the official GitLab doc (and improving it if needed), for anything that’s not specific to Tails — just like we did for Redmine. Some starting points may include:
>
> * https://salsa.debian.org/help/user/index.md
> * https://salsa.debian.org/help/user/project/merge_requests/index.md
> * https://salsa.debian.org/help/user/discussions/index.md
Yes.
Fully agreed: we can close this ticket.
#5 Updated by intrigeri 2019-11-12 14:56:07
- related to
Bug #15186: Evaluate moving to GitLab for merge requests added
#6 Updated by intrigeri 2019-11-12 15:13:58
- related to
Feature #17226: Point to GitLab MR upstream documentation added