[aur-general] [tu-bylaws] [PATCH 2/2] Add details on patch submissions

[Lukas Fleischer]

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%? :)

> 
>