Subject: Re: Alpine Linux aports codestyle
To: Drew DeVault <sir@cmpwn.com>, alpine-devel@lists.alpinelinux.org
References: <BVQOWGQIT8S3.13BUNCYTR9AJV@homura>
From: Olliver Schinagl <oliver+list@schinagl.nl>
Message-ID: <40d0e45b-52a3-94d9-b4ef-35f6e05fbbd8@schinagl.nl>
Date: Wed, 24 Jul 2019 09:08:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <BVQOWGQIT8S3.13BUNCYTR9AJV@homura>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit

Hi Drew,

On 23-07-2019 16:01, Drew DeVault wrote:
> On Tue Jul 23, 2019 at 8:28 AM Olliver Schinagl wrote:
>> over the past year or so, I've started to contribute to Alpine Linux's
>> aports, and have met various codestyles. To get to the bottom of what is
>> 'the' Alpine Linux codestyle, I came up empty handed, there is no
>> CODESTYLE.md, no search query that finds anything nor on the wiki.
> 
> Informally I gather that the basics are:
> 
> - snake_case
> - Indent with a single tab
> - 1 blank line after the initial set of variables, then again between
>    each function
> - Wrap to 80 columns
> - Local variables (e.g. not pkgname, options, etc) named with an
>    underscore prefix

But that really depends on who the maintainer is, and more importantly, 
who the person is who accepts the ticket or worse, simply overwrites to 
adhere to his style. This inconsistency makes very frustrating for 
contributers, which pick an APKBUILD file as an example work on that, 
and then get told they are doing it wrong.

However, one big downside of having flexibility of course it reduces 
exclusivity and thus contributions. However arguing about style and then 
not having a contribution merged, is of course far worse.

> 
> I also generally alpha-sort when I have lots of things which can be
> arbitrarily ordered. When in doubt pick a couple of nice looking
> APKBUILDs to keep as a reference. I use this page as a reference for
> Python packages:
> 
> https://wiki.alpinelinux.org/wiki/Python_package_policies
> 
> abuild will also warn you on several common errors automatically. I
> think there's a second package you can install somewhere which expands
> the list of lintable problems, which probably ought to be merged into
> abuild proper.
> 
>> As I was about to do a version bump to community/mtd-utils, I noticed a
>> lot of activity on the package, a great thing!. Sadly I came to the
>> realization, that in the 'default' aports workflow, the
>> maintainers/contributers do not get CC-ed on changes. As I'm mostly only
>> familiar with Linux, U-Boot and busybox development, I missed the
>> 'get_maintainers' step, where people involved in abuild's would be kept
>> in the loop.
> 
> I use the email based workflow and send patches to
> ~alpine/aports@lists.alpinelinux.org. When I do this I often copy/paste
> the Maintainer and/or Contributor lines into the email and swap them for
> Cc. You can get git send-email to open your editor for reviewing/editing
> the email by passing --annotate or setting git config --global
> sendemail.annotate yes.
>