[aur-general] [tu-bylaws] [PATCH 0/2] TU bylaws amendment
Ok, sending this before the voting period for Xyne's proposal is over since it is already clear that it will be accepted. More than 65% of all TUs voted "yes" and there are zero "no" votes so far :) The first patch is a follow-up to Xyne's proposal and is something he simply forgot when writing the patch. The second patch adds some information on how to submit patches for TU bylaws amendments. It answers following questions and solves following issues: * Where is the official bylaws Git repository? * Proposals with bad formatting that are hard to comment on. * How to submit formatting changes and actual changes at once without creating messy patches. Let the discussion period begin. Lukas Fleischer (2): Add note on when the number of TUs is recorded Add details on patch submissions tu-bylaws.txt | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) -- 1.8.4.rc3.500.gc3113b0
The quorum section does not mention when the number of TUs is recorded.
Add a note that this is done at the beginning of the voting period. This
makes it easy to implement automated quorum calculation in the AUR.
Signed-off-by: Lukas Fleischer
* Mention the tu-bylaws.git repository.
* Mention Git-formatted patches and subject keywords.
* Promote `git send-email`.
* Add note on submitting several patches at once.
Signed-off-by: Lukas Fleischer
On 2013-08-20 18:14 +0200 Lukas Fleischer wrote:
+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.
Use the same formulation as the "Removal of a TU" section:
Following the motion, standard voting procedure commences with a discussion period of 5 days, a quorum of 75%, and a voting period of 7 days.
You can also replace "standard voting procedure" with "SVP" throughout the document after its definition.
+be sent "inline" (i.e. using `git send-email`) so that other TUs can easily
I would change "i.e." to "e.g." as I see no reason to mandate that users actually send the message with git directly (as this requires sendmail configuration, and some users may only have access to webmail). The formatting of the message itself is what matters. To be honest, I don't see the problem with accepting the resulting document either. Copying over a single document is no more work than applying a patch. Perhaps we could also add an additional minor change to this patchset to say that the SVP voting period ends either after the designated time OR after all TUs have voted. With the upcoming changes to the AUR this will be apparent, and the AUR can stop the vote itself an possibly send an email to the list.
On Wed, Aug 21, 2013 at 12:07:47PM +0000, Xyne wrote:
On 2013-08-20 18:14 +0200 Lukas Fleischer wrote:
+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.
Use the same formulation as the "Removal of a TU" section:
Following the motion, standard voting procedure commences with a discussion period of 5 days, a quorum of 75%, and a voting period of 7 days.
You can also replace "standard voting procedure" with "SVP" throughout the document after its definition.
Note that I did not touch this sentence apart from formatting changes.
+be sent "inline" (i.e. using `git send-email`) so that other TUs can easily
I would change "i.e." to "e.g." as I see no reason to mandate that users actually send the message with git directly (as this requires sendmail configuration, and some users may only have access to webmail). The formatting of the message itself is what matters.
Git does not require sendmail. It requires an MTA but something simple and lightweight like msmtp(1) does the job. It takes about 5 minutes to setup. Around 90% of all patches that are sent by Git rookie without using `git send-email` are broken in some way. Most common errors are: * Wrong patch format. Patches created with diff(1) or something else. * Patch is not sent inline. This makes it damn hard to comment on specific parts. * Broken indentation and line wraps. This often happens when patches are sent using webmail. Webmail should never be used to send patches unless you know exactly what you are doing. When applying your patch, I had to export your proposal mail to an mbox file, edit that mbox file and remove the parts that do not belong to the patch, save the resulting file and apply it using `git am`. This is why I came up with this... If there is a generally accepted format which is very convenient, why not use it? Also, the document says "should be sent" -- not "must be sent". Everyone who knows what he/she is doing can send the patch using another tool and hardly anyone will notice.
To be honest, I don't see the problem with accepting the resulting document either. Copying over a single document is no more work than applying a patch.
1. Most people want to see a diff. Hardly anyone wants to read the whole document over and over again and scan for minor wording changes every time. Sending a document means that every TU has to clone the tu-bylaws Git repository, save the attachment, copy it to the working directory of the clone and invoke `git diff`. Why? 2. Attaching a document makes it a lot harder to comment on specific parts by using the "quote" function of the mail client, like you did when replying to my patch :) 3. The committer will have to write a commit message and adjust the author's e-mail address (and maybe also change the author date).
Perhaps we could also add an additional minor change to this patchset to say that the SVP voting period ends either after the designated time OR after all TUs have voted. With the upcoming changes to the AUR this will be apparent, and the AUR can stop the vote itself an possibly send an email to the list.
Ok, I can add this. But I doubt that there will ever be such a situation. Did we ever have a voting with a participation of 100%? :)
On Wed, Aug 21, 2013 at 05:45:50PM +0200, Lukas Fleischer wrote:
On Wed, Aug 21, 2013 at 12:07:47PM +0000, Xyne wrote:
On 2013-08-20 18:14 +0200 Lukas Fleischer wrote:
+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.
Use the same formulation as the "Removal of a TU" section:
Following the motion, standard voting procedure commences with a discussion period of 5 days, a quorum of 75%, and a voting period of 7 days.
You can also replace "standard voting procedure" with "SVP" throughout the document after its definition.
Note that I did not touch this sentence apart from formatting changes.
+be sent "inline" (i.e. using `git send-email`) so that other TUs can easily
I would change "i.e." to "e.g." as I see no reason to mandate that users actually send the message with git directly (as this requires sendmail configuration, and some users may only have access to webmail). The formatting of the message itself is what matters.
Git does not require sendmail. It requires an MTA but something simple and lightweight like msmtp(1) does the job. It takes about 5 minutes to setup.
It doesn't even require an MTA. git is able to send directly to an SMTP server via the perl script that manages mail. See the --smtp-* options in 'git-send-email(1)'. Specifically, the --smtp-server option defaults to 'localhost' which means that it defaults to using a locally found MTA.
Around 90% of all patches that are sent by Git rookie without using `git send-email` are broken in some way. Most common errors are:
* Wrong patch format. Patches created with diff(1) or something else.
* Patch is not sent inline. This makes it damn hard to comment on specific parts.
* Broken indentation and line wraps. This often happens when patches are sent using webmail. Webmail should never be used to send patches unless you know exactly what you are doing.
When applying your patch, I had to export your proposal mail to an mbox file, edit that mbox file and remove the parts that do not belong to the patch, save the resulting file and apply it using `git am`. This is why I came up with this... If there is a generally accepted format which is very convenient, why not use it?
Also, the document says "should be sent" -- not "must be sent". Everyone who knows what he/she is doing can send the patch using another tool and hardly anyone will notice.
To be honest, I don't see the problem with accepting the resulting document either. Copying over a single document is no more work than applying a patch.
1. Most people want to see a diff. Hardly anyone wants to read the whole document over and over again and scan for minor wording changes every time. Sending a document means that every TU has to clone the tu-bylaws Git repository, save the attachment, copy it to the working directory of the clone and invoke `git diff`. Why?
2. Attaching a document makes it a lot harder to comment on specific parts by using the "quote" function of the mail client, like you did when replying to my patch :)
3. The committer will have to write a commit message and adjust the author's e-mail address (and maybe also change the author date).
Perhaps we could also add an additional minor change to this patchset to say that the SVP voting period ends either after the designated time OR after all TUs have voted. With the upcoming changes to the AUR this will be apparent, and the AUR can stop the vote itself an possibly send an email to the list.
Ok, I can add this. But I doubt that there will ever be such a situation. Did we ever have a voting with a participation of 100%? :)
The discussion period has ended. Please cast your votes [1]. The voting period ends on 2013-09-02. [1] https://aur.archlinux.org/tu/?id=71
On Mon, Aug 26, 2013 at 04:30:12PM +0200, Lukas Fleischer wrote:
The discussion period has ended. Please cast your votes [1]. The voting period ends on 2013-09-02.
The proposal has been accepted. Yes: 25 No: 0 Abstain: 7 Thanks to everybody who voted.
participants (3)
-
Dave Reisner
-
Lukas Fleischer
-
Xyne