Hello, First of all, sorry for not communicating this before making the changes. I honestly thought this would be considered to be such a minor change and such a minor issue (even though it affects many packages), that it would not be worth communicating first. If I had been aware of previous cases where similar changes were made (by a script), and the changes were communicated first, I would have attempted to follow the example of those. Secondly, this change did not cause any technical problems. There was one case where the description was broken (0.0004% of all affected packages), thanks Gaetan Bisson for pointing it out. As far as I know, that was the exception to the rule (and the package would still build), but any bug is inexcusable, of course. When it comes to double vs single quoting, can we change PKGBUILD.proto to use single quotes? The character '$' only occurs in the package description in 3 of the community packages, and those 3 can still use double quotes. All that aside, would it be okay for you all if I removed "An ...", "A ..." and "Application is ..." from the start of all package descriptions (and making the first letter an uppercase letter)? This adds no information to the description and (IMO) looks ugly. Just this change, no changes to indentation, trailing periods or quoting? Thanks for your understanding. May any distressed individuals find it in their hearts to let go of the outrage and search innner peace and ponies. -- Sincerely, Alexander Rødseth Arch Linux Trusted User (xyproto on IRC, trontonic on AUR)

On Thu, Oct 25, 2012 at 6:39 AM, Alexander Rødseth wrote:

When it comes to double vs single quoting, can we change PKGBUILD.proto to use single quotes? The character '$' only occurs in the package description in 3 of the community packages, and those 3 can still use double quotes.

The main repos have 2815 occurrences using double quotes, 409 using single quotes. So sounds like we should unify on using double quotes. I think you also missed this case, given that the single quote ' is used quite regularly in the English language: dmcgee@galway ~/projects/arch-repos $ LANG=C grep "pkgdesc=\".*'" */trunk/PKGBUILD achessclock/trunk/PKGBUILD:pkgdesc="Angus' Chess Clock" bootchart/trunk/PKGBUILD:pkgdesc="A 'startup' graphing tool" cdargs/trunk/PKGBUILD:pkgdesc="A replacement for 'cd' that includes bookmarks/browsing for faster navigation" clawsker/trunk/PKGBUILD:pkgdesc="An applet to edit Claws Mail's hidden preferences." claws-mail-themes/trunk/PKGBUILD:pkgdesc="Claws Mail's themes" cvsps/trunk/PKGBUILD:pkgdesc="Generating 'patchset' information from a CVS repository" djvulibre/trunk/PKGBUILD:pkgdesc="Suite to create, manipulate and view DjVu ('déjà vu') documents" emovix/trunk/PKGBUILD:pkgdesc="Create Movix-CD's (also emovix plugin for k3b)" foomatic-db-hpijs/trunk/PKGBUILD:pkgdesc="Foomatic is a system for using free software printer drivers with common spoolers on Unix - Foomatic data for the HP's HPIJS printer drivers" foomatic/trunk/PKGBUILD: pkgdesc="Foomatic - Filter scripts used by the printer spoolers to convert the incoming PostScript data into the printer's native format." foomatic/trunk/PKGBUILD: pkgdesc="Foomatic - Foomatic's database engine generates PPD files from the data in Foomatic's XML database. It also contains scripts to directly generate print queues and handle jobs." fprint_demo/trunk/PKGBUILD:pkgdesc="Simple GTK+ application to demonstrate and test libfprint's capabilities" gimp-dbp/trunk/PKGBUILD:pkgdesc="David's batch processor for the GIMP" go-openoffice/trunk/PKGBUILD:pkgdesc="OpenOffice.org - go-oo.org enhanced version of SUN's office suite" grml-zsh-config/trunk/PKGBUILD:pkgdesc="grml's zsh setup" gtklife/trunk/PKGBUILD:pkgdesc="GtkLife is a fast, featureful, open-source Conway's Life program for *nix" gtkpod/trunk/PKGBUILD:pkgdesc="A platform independent GUI for Apple's iPod using GTK3" hmmer/trunk/PKGBUILD:pkgdesc="Profile hidden Markov models (profile HMMs) can be used to do sensitive database searching using statistical descriptions of a sequence family's consensus" host/trunk/PKGBUILD:pkgdesc="Lightweight alternative to bind's host." iwlwifi-1000-ucode/trunk/PKGBUILD:pkgdesc="Intel wireless firmware for Intel's WiFi Link 1000BGN wireless devices" iwlwifi-5000-ucode/trunk/PKGBUILD:pkgdesc="Intel wireless firmware for Intel's 5100BG, 5100ABG, 5100AGN, 5300AGN and 5350AGN wireless devices" iwlwifi-6000-ucode/trunk/PKGBUILD:pkgdesc="Intel wireless firmware for Intel's 6000 Series wireless devices" jade/trunk/PKGBUILD:pkgdesc="James Clark's DSSSL Engine" jdk/trunk/PKGBUILD:pkgdesc="Sun's Java Development Kit" jre/trunk/PKGBUILD:pkgdesc="Sun's java runtime environment" kernel26mm/trunk/PKGBUILD:pkgdesc="The Linux Kernel and modules, Andrew Morton's -mm tree" kiosktool/trunk/PKGBUILD:pkgdesc="A Point&Click tool for system administrators to enable KDE's KIOSK features or otherwise preconfigure KDE for groups of users" kobodeluxe/trunk/PKGBUILD:pkgdesc="An enhanced version of Akira Higuchi's game XKobo, an addictive space shoot'em up" ladspa/trunk/PKGBUILD:pkgdesc="Linux Audio Developer's Simple Plugin API (LADSPA)" lesstif/trunk/PKGBUILD:pkgdesc="LGPL'd re-implementation of Motif" libdjvu/trunk/PKGBUILD:pkgdesc="Library to process DjVu ('déjà vu') documents" libidl2/trunk/PKGBUILD:pkgdesc="A front-end for CORBA 2.2 IDL and Netscape's XPIDL" libifp/trunk/PKGBUILD:pkgdesc="General-purpose library-driver for iRiver's iFP portable audio players" libmsn/trunk/PKGBUILD:pkgdesc="A reusable, open-source, fully documented library for connecting to Microsoft's MSN" libnice/trunk/PKGBUILD:pkgdesc="An implementation of the IETF's draft ICE (for p2p UDP data streams)" libplist/trunk/PKGBUILD:pkgdesc="A library to handle Apple Property List format whereas it's binary or XML" libwmf/trunk/PKGBUILD:pkgdesc="A library for reading vector images in Microsoft's native Windows Metafile Format (WMF)" libxfixes/trunk/PKGBUILD:pkgdesc="X11 miscellaneous 'fixes' extension library" libytnef/trunk/PKGBUILD:pkgdesc="Yerase's TNEF Stream Reader library (decode winmail.dat)" libzrtpcpp/trunk/PKGBUILD:pkgdesc="A C++ implementation of Phil Zimmermann's ZRTP specification" libzvt/trunk/PKGBUILD:pkgdesc="Zed's virtual terminal library" mcpp/trunk/PKGBUILD:pkgdesc="Matsui's CPP implementation precisely conformed to standards" most/trunk/PKGBUILD:pkgdesc="A terminal pager similar to 'more' and 'less'" nant/trunk/PKGBUILD:pkgdesc="A free .NET build tool, like make but without make's problems" nxclient/trunk/PKGBUILD:pkgdesc="Nomachine's closed source client for NX servers" penguin-command/trunk/PKGBUILD:pkgdesc="This is a clone of the classic 'Missile Command' Game" perl-crypt-openssl-bignum/trunk/PKGBUILD:pkgdesc="OpenSSL's multiprecision integer arithmetic " perl-lmap-cid2spf/trunk/PKGBUILD:pkgdesc="Convert between the two LMAP formats Microsoft's CID and SPF" perl-mozilla-ca/trunk/PKGBUILD:pkgdesc="Mozilla's CA cert bundle in PEM format" python-logilab-astng/trunk/PKGBUILD:pkgdesc="Extend python's abstract syntax tree" qscintilla/trunk/PKGBUILD: pkgdesc="A port to Qt4 of Neil Hodgson's Scintilla C++ editor class" refind-efi/trunk/PKGBUILD:pkgdesc="Rod Smith's fork of rEFIt UEFI Boot Manager" rp-pppoe/trunk/PKGBUILD:pkgdesc="Roaring Penguin's Point-to-Point Protocol over Ethernet client" samba/trunk/PKGBUILD:pkgdesc="Tools to access a server's filespace and printers via SMB" samba/trunk/PKGBUILD:pkgdesc="Tools to access a server's filespace and printers via SMB" schedtool/trunk/PKGBUILD:pkgdesc="Query or alter a process' scheduling policy" swh-plugins/trunk/PKGBUILD:pkgdesc="Steve Harris' LADSPA plug-ins suite" taglib-sharp/trunk/PKGBUILD:pkgdesc="It's a library for reading and writing metadata in media files, including video, audio, and photo formats for Mono" texlive-formatsextra/trunk/PKGBUILD:pkgdesc="TeX Live - collection of extra TeX 'formats'" time/trunk/PKGBUILD:pkgdesc="Utility for monitoring a program's use of system resources" toppler/trunk/PKGBUILD:pkgdesc="Tower Toppler (aka Nebulous) is the reimplementation of an old 'jump and run' game" tuxmath/trunk/PKGBUILD:pkgdesc="'Tux of Math Command' is an educational math tutorial game for elementary school level children" vcdimager/trunk/PKGBUILD:pkgdesc="A full-featured mastering suite for authoring disassembling and analyzing Video CD's and Super Video CD's" vectoroids/trunk/PKGBUILD:pkgdesc="Vectoroids is based on the X-Window PDA game 'Agendaroids,'" webrtc-audio-processing/trunk/PKGBUILD:pkgdesc="AudioProcessing library based on Google's implementation of WebRTC" whois/trunk/PKGBUILD:pkgdesc="The whois client by Marco d'Itri" xcb-util-image/trunk/PKGBUILD:pkgdesc="Utility libraries for XC Binding - Port of Xlib's XImage and XShmImage functions" xorg-xgamma/trunk/PKGBUILD:pkgdesc="Alter a monitor's gamma correction" zeitgeist/trunk/PKGBUILD:pkgdesc="A service which logs the users's activities and events and makes relevant information available to other applications"

Alexander Rødseth wrote:

All that aside, would it be okay for you all if I removed "An ...", "A ..." and "Application is ..." from the start of all package descriptions (and making the first letter an uppercase letter)? This adds no information to the description and (IMO) looks ugly. Just this change, no changes to indentation, trailing periods or quoting?

Thanks for your understanding. May any distressed individuals find it in their hearts to let go of the outrage and search innner peace and ponies.

The lack of communication really is the key issue here. It is disrespectful to other packagers to "improve" their packages this way. It is also dangerous to have one dev or TU who thinks he knows best and who will push sweeping changes without so much as a discussion about his intentions. The other aspect is that this is stylistic. I have long argued that having PKGBUILDs written in Bash is a mistake and that something uniform that is perfectly and safely parsable would be much more preferable. That is, however, not the current state of affairs. PKGBUILDs are Bash and syntactically the only criterion is that they be valid Bash (in both the syntactic and the functional sense). I agree that the proper use of quoting to handle all paths, overall stylish consistency, etc., should be encouraged. Single quotes make sense if nothing in the string requires interpolation, but there is no reason to force it on people as it makes no different for the functionality or legibility of the PKGBUILD, except in cases where the difference is desired behavior. Let the packager decide. For the package descriptions, that should be left up to the packager as well. The description has no programmatic purpose. Its sole purpose is to provide users with information. Sometimes a few words is enough, sometimes a full sentence makes sense. The important thing is the information that it conveys to the users, not the arbitrary aesthetic value that you attribute to it when printed out alongside others in a terminal. So, start a discussion about packaging guidelines. Use a script to find PKGBUILDs that you would like to change and notify the maintainer. Don't mass-update PKGBUILDs without telling anyone about it and then be surprised that you upset some people. Good intentions or not, I find the lack of consideration troubling. Do not take the length of my reply to indicate that I am upset or angry. I simply wanted to explain my own views on this as you do not seem to understand why others consider this a bigger issue than you do. Regards, Xyne

[2012-10-25 20:58:48 +0200] Alexander Rødseth:

Of course, if people cling to their packages, believe every man is an island and put much pride in their package descriptions, I can understand why it can be perceived as disrespectful

Adding insult to injury - way to go my friend! Guess where the only pride I can see comes from... -- Gaetan

Alexander Rødseth wrote:

I disagree with you here, for two reasons. Firstly, I view the package ownership as a collective ownership, where the package maintainers of Arch Linux maintain all the packages together. At least for [community]. This is reflected on how we help each other out on TODO-lists, with bugs and with updates on packages. I certainly wouldn't mind if someone fixed a problem with one of the PKGBUILDs I maintain, or ran a script (that could easily be rolled back) that made a series of minor positive changes (like converting every PKGBUILD in [community] to UTF-8). Secondly, the changes were made on so many packages, that it's hard to believe anyone would take it personally or view the change as disrespectful. Of course, if people cling to their packages, believe every man is an island and put much pride in their package descriptions, I can understand why it can be perceived as disrespectful, but I still insist that it is not.

I think my meaning was misunderstood. Of course the PKGBUILDs and everything else in the repos belong to Arch, not each individual packager. I didn't mean that it was disrespectful in the sense of encroaching on others' "property". I meant that it was disrespectful in the sense that you concluded that most of the other packagers were producing substandard packages and that you needed to help them do it right. I could clarify further but this is already too far off topic and likely to create tension.

...

Good intentions or not, I find the lack of consideration troubling.

I found your implication that my intentions may not have been good troubling...

"Good intentions or not" is an idiomatic expression. It conveys that I thought your intentions were good, but that it doesn't change what follows. Compare "believe it or not" [1]. Concluding, I don't think it was a big issue but it's bigger than you think, I know it was meant well, and no animals were harmed in the making of this change, so everything's fine. Just discuss it first next time. ;) [1] http://idioms.thefreedictionary.com/believe+it+or+not

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/10/12 12:32, Alexander Rødseth wrote:

Hi Xyne,

Hi Xyne, Alexander, Evangelos and the rest of the gang.

2012/10/27 Xyne :

...

Of course the PKGBUILDs and everything else in the repos belong to Arch, not each individual packager. I didn't mean that it was disrespectful in the sense of encroaching on others' "property". I meant that it was disrespectful in the sense that you concluded that most of the other packagers were producing substandard packages and that you needed to help them do it right.

Let me quote the Arch Packaging Guidelines [1]: When creating a package description for a package, do not include the package name in a self-referencing way. For example, "Nedit is a text editor for X11" could be simplified to "A text editor for X11".

And the DeveloperWiki:Bash Coding Style page [2]: Use single quotes if a string does not contain parseable content.

These are not policies and guidelines that have originated from my own head, from belief in my own superiority nor out of any disrespect. If you think otherwise, you're wrong.

I wanted to implement lots of small changes, that people otherwise won't bother with, that are in compliance with the current guidelines.

I am having a hard time believing you find this to be disrespectful.

<snip> I understand the "angry" of the effect of this, but I think Alexander's mistake was not to tell us his idea and apply it by his own (as many other people said). Enough discussion about this, he do had good intentions, he do apologize with us, so let's move on. I support the idea of do a planning examining the results of Alexander's tool in order to clean a little bit some of our packages, but with planning and awareness about what will be done. Please let's advance with this. Cheers. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQjqPnAAoJEEKh2xXsEzutpWQH/it6xd/9x6DIcOp402buJM6x oJY5mFSwO1GzYNRq2UoiZAMDude9KQtAcpuTq+/dvUPRbB1YI8Qet7xwHMqbzgwb RfV5AQfltvz8sidXS5Ps6RW6YZrP7XSJ7Wsm+4fV5t3xryeFUXonepobrijMpRqK idvSNDGvbPn/o0SiqZTOpz8JJTvNA6i47E88j9hxU5gIZpdCcgJVPxCUL/L9ZrMC YkhJx7Uwmdq/4VJBKV9PqImnK6pVwRulxyCemMz+fsq2lW3dN85YPh1Zt6MVZrmU TUS8ew3/o92HBWI9TJeq1l+dgOyP+MXow383aWNXJR5b5zPZbChSagJlMMwzYIk= =t3SU -----END PGP SIGNATURE-----

On 26 October 2012 01:23, Xyne wrote:

Alexander Rødseth wrote:

...

All that aside, would it be okay for you all if I removed "An ...", "A ..." and "Application is ..." from the start of all package descriptions (and making the first letter an uppercase letter)? This adds no information to the description and (IMO) looks ugly. Just this change, no changes to indentation, trailing periods or quoting?

Thanks for your understanding. May any distressed individuals find it in their hearts to let go of the outrage and search innner peace and ponies.

The lack of communication really is the key issue here. It is disrespectful to other packagers to "improve" their packages this way. It is also dangerous to have one dev or TU who thinks he knows best and who will push sweeping changes without so much as a discussion about his intentions.

The other aspect is that this is stylistic. I have long argued that having PKGBUILDs written in Bash is a mistake and that something uniform that is perfectly and safely parsable would be much more preferable. That is, however, not the current state of affairs. PKGBUILDs are Bash and syntactically the only criterion is that they be valid Bash (in both the syntactic and the functional sense). I agree that the proper use of quoting to handle all paths, overall stylish consistency, etc., should be encouraged.

Single quotes make sense if nothing in the string requires interpolation, but there is no reason to force it on people as it makes no different for the functionality or legibility of the PKGBUILD, except in cases where the difference is desired behavior. Let the packager decide.

For the package descriptions, that should be left up to the packager as well. The description has no programmatic purpose. Its sole purpose is to provide users with information. Sometimes a few words is enough, sometimes a full sentence makes sense. The important thing is the information that it conveys to the users, not the arbitrary aesthetic value that you attribute to it when printed out alongside others in a terminal.

So, start a discussion about packaging guidelines. Use a script to find PKGBUILDs that you would like to change and notify the maintainer. Don't mass-update PKGBUILDs without telling anyone about it and then be surprised that you upset some people. Good intentions or not, I find the lack of consideration troubling.

Do not take the length of my reply to indicate that I am upset or angry. I simply wanted to explain my own views on this as you do not seem to understand why others consider this a bigger issue than you do.

Regards, Xyne

I think Xyne touched on this a little bit but the only issue I see here is really just an invasion of stylistic choices in the absence of a proper style guideline (which has also been discussed a number of times without results). Whenever editing someone else's PKGBUILD I always take care to not mess with the "cosmetic" stuff. Language (desc), I may try to make better (not really something a script should be changing in the first place), but not coding style (I leave indents, bracing and quoting variables alone). Not directed particularly at Alexander or anyone (his intentions were definitely pure), just holler next time you see a chance for a mass edit of minor things. This was just a mistake, so don't be discouraged :) -- GPG/PGP ID: C0711BF1