[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 <christian@heusel.eu> --- tu-bylaws.adoc | 19 ++++--------------- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/tu-bylaws.adoc b/tu-bylaws.adoc index 376d909..70a8a27 100644 --- a/tu-bylaws.adoc +++ b/tu-bylaws.adoc @@ -170,21 +170,10 @@ These bylaws may be amended at any time. A TU must motion for an amendment by sending an announcement to https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general]. -The message must either contain, or have attached, a Git-formatted patch -against this document which accomplishes the suggested change. The patch should -be based on the master branch of the official -https://gitlab.archlinux.org/archlinux/tu-bylaws.git/[tu-bylaws repository] and should -be sent "inline" (i.e. using `git send-email`) so that other TUs can easily -comment on specific parts. The strings `[PATCH]` and `[tu-bylaws]` should be -included in the subject. `git send-email --annotate` can be used to edit a -patch before sending it to the mailing list. - -Sending multiple patches is generally discouraged and should only be done if no -more than one of the patches are subject for debate (the remaining patches -might be formatting changes or minor wording changes). If multiple patches are -sent as part of one proposal, a cover letter describing the changes must be -included. The `--cover-letter` option of `git send-email` can be used to -achieve this. +The message must contain a link to a merge reqest in the official +https://gitlab.archlinux.org/archlinux/tu-bylaws[tu-bylaws repository] and the +merge request description should contain a meaningful description and +motivation for the change. SVP is commenced at the time of the motion, with a discussion period of 5 days, a quorum of 75%, and a voting period of 7 days. -- 2.42.0
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.
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
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 <polarian@polarian.dev> To: Johannes Löthberg <johannes@kyriasis.com> Hello, This amendment is proposing the change from patches sent through the mailing list (which is hard to bot and also isn't as simple for a lot of users) to merge requests, which is possible for the endpoint to be spammed, and is very user friendly allowing anyone to do it. PS: You forgot to reply to the mailing list. Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev
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
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