[PATCH][tu-bylaws] bylaw amendments: switch to gitlab merge requests
Most of our worflows have moved from mailing lists and patches to merge
requests on gitlab. Until now amending the TU Bylaws formally requires
sending patches via mail which this amendment intends to replace with
merge requests on the gitlab repository.
Signed-off-by: Christian Heusel
On 23/08/24 01:33AM, Christian Heusel wrote:
Most of our worflows have moved from mailing lists and patches to merge requests on gitlab. Until now amending the TU Bylaws formally requires sending patches via mail which this amendment intends to replace with merge requests on the gitlab repository.
As per the rules for amending the bylaws discussion period for the proposal will last until Monday 28th August (5 days) with the voting started afterwards and running until 4th September (7 days). I view as a rather formal change but if anyone objects I am happy to discuss. cheers, gromit
Hello, Sorry I am not a TU, and shouldn't really respond to said thread, but I have a question/problem I would like to bring up. If you enable the merge request functionality of Gitlab, what will stop the hundreds (potential thousands) of people who want to contribute to the official repositories? I know a lot of people will look at this and say "Isn't this a good thing?" but, until now the TUs have maintained the official repositories, and I am aware it was part of the goal of migrating to git, allowing for more community contributions, not just from Arch Staff however the opening of the merge request feature could cause thousands of people spamming the endpoints. If you only want TUs to be able to open them, how will you enforce this? If you want everyone to open merge requests and to contribute to official repositories, the TU's will no longer be maintaining the official repositories, instead will be reviewing and merging thousands of merge requests which simply bump the version of the package. This is a major issue within Alpine Linux, where merge/pull requests are free to be open by anyone in the community, but then you get tons of people demanding you merge their version bump, even though it is untested. So, in conclusion there is two issues which needs to be considered. If merge requests are Arch Staff only, then you will have thousands of merge requests which need to be closed, you will need some way of validating whether a user can or cant open said merge request (unless gitlab provides this?) or patch gitlab to distinguish between staff and community user. If merge requests are open to all, then you will potentially have thousands of package bumps to review, and test, and build. Your job will shift from maintainers of the official repositories to patch reviewers, or you will need to have some users who look through all the issues and automatically close package bumps. Again not a TU, this was a concern I had back during the migration from svn to git, however I remember being told (I believe by Jelle) that the migration was just the VCS and that issues/MR will be disabled until further notice. Is this the day(s) that will open the arch repository to the arch community? Or am I overreacting? Thank you! Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev
(Sorry for double-sending, I fucked up the reply recipients.) On 24/08/2023 21.48, Polarian wrote:
If you enable the merge request functionality of Gitlab, what will stop the hundreds (potential thousands) of people who want to contribute to the official repositories? That is entirely unrelated to this amendment to the TU bylaws which is specifically about amendments to the TU bylaws.
Hello,
Please see my response which was sent directly to the user as they did
not respond to the mailing list.
-------- Forwarded Message --------
Subject: Re: [PATCH][tu-bylaws] bylaw amendments: switch to gitlab merge
requests
Date: Thu, 24 Aug 2023 20:57:20 +0100
From: Polarian
On 24/08/2023 21.58, Polarian wrote:
This amendment is proposing the change from patches sent through the mailing list (<snip>) to merge requests, which is possible for the endpoint to be spammed, and is very user friendly allowing anyone to do For TU bylaw amendments. In what way do you figure that the manner in which TU bylaw amendments are to be proposed is related to people filing MRs for the official repositories?
Hello,
For TU bylaw amendments. In what way do you figure that the manner in which TU bylaw amendments are to be proposed is related to people filing MRs for the official repositories?
Because in order for the bylaws to be valid, the functionality must be supported. It is pointless allowing MR within the bylaws if you currently can't make MR isn't it? They work hand in hand! Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev
On 24/08/2023 22.17, Polarian wrote:
Because in order for the bylaws to be valid, the functionality must be supported.
It is pointless allowing MR within the bylaws if you currently can't make MR isn't it? All people who have the right to propose TU bylaw amendments are currently already able to file MRs against the relevant repository, so I do not understand your point.
Hello,
All people who have the right to propose TU bylaw amendments are currently already able to file MRs against the relevant repository, so I do not understand your point.
Ah, so you can do that within gitlab enterprise. Sorry for the noise on this thread, I did say this was a question and you just answered it (thank you!). I didn't know that a feature existed to restrict access to the MR, I just assumed they were disabled entirely, but they are in fact, just restricted. Again sorry for the noise, and thanks for the clarification. Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev
Hi Polarian On 24/08/2023 22:48, Polarian wrote:
Hello,
Sorry I am not a TU, and shouldn't really respond to said thread, but I have a question/problem I would like to bring up.
If you enable the merge request functionality of Gitlab, what will stop the hundreds (potential thousands) of people who want to contribute to the official repositories?
The proposal (patch) that gromit suggests it to move any future TU-bylaws changes instead of ML patches to Gitlab Merge Requests. This change according to the bylaws needs to be voted from current TUs. Hope it clears the picture. Cheers, -- Leonidas Spyropoulos PGP: 59E43E106B247368
On 8/24/23 13:08, Christian Heusel wrote:
Most of our worflows have moved from mailing lists and patches to merge requests on gitlab. Until now amending the TU Bylaws formally requires sending patches via mail which this amendment intends to replace with merge requests on the gitlab repository. As per the rules for amending the bylaws discussion period for the
On 23/08/24 01:33AM, Christian Heusel wrote: proposal will last until Monday 28th August (5 days) with the voting started afterwards and running until 4th September (7 days).
The vote is now live: https://aur.archlinux.org/tu/148
On 8/28/23 21:01, Christian Heusel wrote:
On 8/24/23 13:08, Christian Heusel wrote:
Most of our worflows have moved from mailing lists and patches to merge requests on gitlab. Until now amending the TU Bylaws formally requires sending patches via mail which this amendment intends to replace with merge requests on the gitlab repository. As per the rules for amending the bylaws discussion period for the
On 23/08/24 01:33AM, Christian Heusel wrote: proposal will last until Monday 28th August (5 days) with the voting started afterwards and running until 4th September (7 days).
The vote is now live: https://aur.archlinux.org/tu/148
There are three days left and we still need at least 18 people to vote to achieve the quorum of 75%. Please go vote everybody :)
On 23/09/02 01:24AM, Christian Heusel wrote:
On 8/28/23 21:01, Christian Heusel wrote:
On 8/24/23 13:08, Christian Heusel wrote:
Most of our worflows have moved from mailing lists and patches to merge requests on gitlab. Until now amending the TU Bylaws formally requires sending patches via mail which this amendment intends to replace with merge requests on the gitlab repository. As per the rules for amending the bylaws discussion period for the
On 23/08/24 01:33AM, Christian Heusel wrote: proposal will last until Monday 28th August (5 days) with the voting started afterwards and running until 4th September (7 days).
The vote is now live: https://aur.archlinux.org/tu/148
There are three days left and we still need at least 18 people to vote to achieve the quorum of 75%.
Please go vote everybody :)
The proposal was voted as follows and is therefore accepted: - Yes: 49 - No: 2 - Abstain: 1 - Participation: 82.54% Thanks for participating everybody! ^_^ Chris / gromit
participants (4)
-
Christian Heusel
-
Johannes Löthberg
-
Leonidas Spyropoulos
-
Polarian