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