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

[Dave Reisner]

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