For discussion of Alpine Linux development and developer support

Re: Alpine Linux aports codestyle

Olliver Schinagl
Details
Message ID
<f6d77f53-860d-7ed6-decd-ed3d377ee8c9@schinagl.nl>
DKIM signature
missing
Download raw message
Hey Tcely,

On 23-07-2019 08:52, tcely wrote:
> There isn't one, as far as I know. The last consensus I saw was that 
> style should be left to the maintainer to decide.
That's actually a really good concensus, but (at least on github) hasn't 
played out so well yet :) where others request changes to match their 
style, rather then what the maintainer and author wants :)

In any case, after this reply, lets move discussion over to the gitlab 
ticket!

https://gitlab.alpinelinux.org/alpine/aports/issues/10689

> 
> So, Kevin's commit imposing his preferences over yours and presenting 
> those preferences as project decisions was at best a mistake.
> 
I'm sorry to have singled out Kevin, this is by no means intended 
directly at him (nor is he the only one).

> I wrote down the reasons for the style I use for packages I maintain 
> at: https://gist.github.com/tcely/8ef31809f04a494a27ad79d49afdf167
As you adhere to the same style I do, I think I recall you and I 
commenting on some of my PR's where others wanted to see something else 
(on items I offered maintainership for). I think in the end you did 
merge it :)

> 
> The preference some others have expressed to me for making APKBUILD as 
> short as possible does not make much sense to me. That's why I wrote 
> down these specific points first.
That's becaues it doesn't make sense. An APKBUILD file is as much 
documentation as it is implementation. Readability and thus 
maintainability triumph all forms of 'keeping it shorter'.

> 
> No, using braces doesn't hurt anyone. Also, no, I won't be removing 
> lines I did not need to fill in from the template. In fact, I think not 
> having options in our template leads to less consistency because options 
> ends up at various places in the file.
Aye, I think the template should either be reduced to a bare minimum or 
just removed (or maybe fully featured :)

To be fair however, I do prefer to keep unused variables out (shellcheck 
wanrs about this)

Olliver

> 
> On Jul 23, 2019 2:28 AM, Olliver Schinagl <oliver+list@schinagl.nl> wrote:
> 
>     Hey list,
> 
>     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.
> 
>     Now of course, the document could be hiding out of plain site, and if
>     that is the case, other then saying 'make it findable', I appologize
>     for
>     even bringing anything up here.
> 
>     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.
> 
>     Never the less, what triggered for me to address the mailing list
>     however was commit 57d39405ad74 ("community/mtd-utils: adhere to aports
>     code style"). As the subject already states, 'adhere to aports code
>     style' is mentioned, but as mentioned earlier, I cannot seem to find
>     this aforementioned code style. It should be obvious then of course,
>     that when asking people to adhere to a coding style, this style needed
>     to be documented (and more importantantly rationalized). It shouldn't
>     needed to be mentioned, by having a guide (that can be checked with
>     linters/checkers) makes life easier, for both developers and reviewers
>     (passes automated code checks, no need to argue about style anymore).
> 
>     So in short, where is the style guide that everybody keeps talking
>     about :)
> 
>     Thank you,
> 
>     Olliver
> 
>