For discussion of Alpine Linux development and developer support

20 10

[alpine-devel] Improving Alpine Linux documentation

Consus
Details
Message ID
<20171212201302.GA9334@eddy>
Sender timestamp
1513109585
DKIM signature
missing
Download raw message
Hello,

I'm writing this email to start an archived discussion about the future
of the Alpine Linux documentation.

Earlier this day we (clandmeter, _ikke_, ncopa, TBK and your humble
author) were discussing on IRC (check out the new #alpine-docs channel)
how the current state of the project documentation can be improved.

For now the primary source of knowledge is the MediaWiki running on
https://wiki.alpinelinux.org. It does contain a lot of useful info,
however it lacks proper structure, the spam level is very high and
newcomers often get banned during the infamous grace period after the
account creation.

The other problem with the publicly edited Wiki (mentioned by Natanael)
is that one cannot fully trust the content. So malicious edits in Wiki
sections describing policies, BTC wallets for donations or secure
network configurations can harm the project. The question if existing
security methods (user groups with different permissions, ability to
lock a Wiki page) are enough to address this issue is open for
discussion.

We currently have (at least) three proposals:

1. The MediaWiki stays as it is (we just need to add the proper
   structure and harden it against the Evil Bot Horde).

2. We move the core project documentation somewhere else
   (https://alpinelinux.org or https://docs.alpinelinux.org) but keep
   Wiki in place for the community. This way the core project
   documentation is stored somewhere safe (probably in Git) and GitHub
   pull-requests or patches via ML are used to update it.

3. We completely move to some sort of https://docs.alpinelinux.org
   (no matter in it's current form or not) and all user contributions.
   Hardcore variant of #2.

Of course, every proposal have have it's own Pros and Cons.

The main concern with Git-based documentation solutions is that the
standalone patch review system should be rolled out (patchworks,
ReviewBoard, you name it) because as (AFAIK) clandmeter stated we cannot
fully rely on GitHub. However, it gives the developers the full control
over the content

It worth mentioning that the problems with Wiki can be addressed in a
number of ways.

First of all, currently Alpine Wiki does not require a email address to
create an account. Requiring a validated email address should reduce the
spam level considerably.

Sensitive information (like PGP keys, donation options, etc) stored in
the Wiki can be restricted for developer accounts only. If user finds an
error in the document he can raise an issue in the Discussion tab.

Please, share your opinions on this topic so we can improve the state of
things.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<20171212202301.GA26329@miku>
In-Reply-To
<20171212201302.GA9334@eddy> (view parent)
Sender timestamp
1513110182
DKIM signature
missing
Download raw message
I don't really have any advice for what to do with the wiki, but
regarding Alpine's core documentation I have some thoughts. Something
that bothers me about Alpine (and that I'd like to contribute to
improving) is the lack of man pages for Alpine core stuff. I think a
substantial portion of the core docs can and should be done this way,
rather than on the wiki - though it would be nice to render the man
pages to HTML for display on the web, too.

No one likes writing roff so I've been working on a tool recently to
help with this:

https://git.sr.ht/~sircmpwn/scdoc

If there's no opposition to this I was hoping to start writing man pages
for apk shortly.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<20171212203147.GA27466@miku>
In-Reply-To
<20171212202626.GB9334@eddy> (view parent)
Sender timestamp
1513110707
DKIM signature
missing
Download raw message
On 2017-12-12 11:26 PM, Consus wrote:
> Try http://mdocml.bsd.lv. It is used by the OpenBSD project. I was writing man pages
> using it myself, it's pretty okay.

mdocml is basically roff with lipstick on, I don't like it much more
than I liked roff. There are other man page generators, too, but they're
almost all written in high level languages and require some kind of
runtime (god forbid, XSLT). The new tool I'm working on is a small POSIX
C99 tool with no dependencies. Its syntax is much easier to write, read,
and maintain than mdoc.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
A. Wilcox
Details
Message ID
<5A304BC7.3020401@adelielinux.org>
In-Reply-To
<20171212201302.GA9334@eddy> (view parent)
Sender timestamp
1513114567
DKIM signature
missing
Download raw message
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/12/17 14:13, Consus wrote:
> Earlier this day we (clandmeter, _ikke_, ncopa, TBK and your
> humble author) were discussing on IRC (check out the new
> #alpine-docs channel) how the current state of the project
> documentation can be improved.


Is this channel available on Matrix as well?


> We currently have (at least) three proposals:
> 
> 2. We move the core project documentation somewhere else 
> (https://alpinelinux.org or https://docs.alpinelinux.org) but keep 
> Wiki in place for the community. This way the core project 
> documentation is stored somewhere safe (probably in Git) and
> GitHub pull-requests or patches via ML are used to update it.


This is how we do it in Adélie.  It seems to work well.


> The main concern with Git-based documentation solutions is that
> the standalone patch review system should be rolled out
> (patchworks, ReviewBoard, you name it) because as (AFAIK)
> clandmeter stated we cannot fully rely on GitHub. However, it gives
> the developers the full control over the content


I'm glad that Alpine core still realises that.  I have been worried
lately that there is too much buy-in to GitHub from the Alpine
developers.  Do we really want all of that valuable discussion about
PRs and such locked away in a corporation's databases?  How long will
GitHub stay afloat before turning to ads, pay-to-use, or even just
plain disappear from the Internet?


> First of all, currently Alpine Wiki does not require a email
> address to create an account. Requiring a validated email address
> should reduce the spam level considerably.


Reduce, but not eliminate.  Honestly, the only true way to eliminate
spam is to have closed registrations (you have to poke an Alpine
person to get an account on the wiki).  But that adds a lot of work,
so it probably isn't a good solution.  Requiring valid email will take
out 80% of it so I suppose that's a very good start.


> Sensitive information (like PGP keys, donation options, etc) stored
> in the Wiki can be restricted for developer accounts only. If user
> finds an error in the document he can raise an issue in the
> Discussion tab.


I don't think any of this should be stored on the wiki.  All of this
should be on the main site, and never on the Wiki.  It certainly won't
change very often, so there's no reason to need for the community to
be able to edit it.


Meanwhile, I am going to work on mdoc'ing up apk and friends and hope
to have this done by the weekend.

Best,
- --arw


- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJaMEvEAAoJEMspy1GSK50USF0P/0BtvmEXOzxD7mJWydJkHi6F
HHkx2nb5bsAhKxVif0h/k3qZMShyCbn2dS68+znuPPKRCouHXHUlCWoiLNdZY1Y7
rBqjmAMXZezBt7xgS4CflmCpeTofDWBBcJQzbqIHJhf8/j4KA8lYZii+/EpIhbGd
8Uz/z9ZRw52s8Tn052jV96QJXIkD3jt+Tuk9v3BptYta2RuWD9GgAd70T17BRUq3
ugqwcXUa58RbvtsxT0psDb2+xQwfN9b4eK0K+CsMYioC7icWMj5QhBg+bcUX1442
6/oJBngd7fUt2oAgEuG3xiOps0uN5kTmFvW+TDuyDy0v6TaH2GUeAWJNcOciFmNZ
tggjc1E15rTnt43KzUtN2oJc7vPXcaJL3NWb4WxFKOC3rhfnN+XjbBxthp911i9a
YXlMX9+zXKJidIaKW5GXy4VVwwvX4PbIENkbucptTa39NjEtG4JNzwXeF8noWiQZ
y1J7ED0P9U5sxefILR+ypqSMadrM8aknSEDF3V+1p2yT6o5FVOO4s+m0hLhJyAbA
fdpO0npamDxxR1fjrF4PVadzlGCYhUYuNacRIB1MV9m/6yfKt7xjM5y6mGeEMxiK
k+/6mt5myXIHbSW1YtPjb8hk/zDkEWroeco4Y83q4dRhn2wqHMO6LcN3Z9eKZtSr
/kLeL7TYRDIkZs3VSM0S
=JQlb
-----END PGP SIGNATURE-----


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
A. Wilcox
Details
Message ID
<5A304CE2.3030707@adelielinux.org>
In-Reply-To
<20171212203455.GC9334@eddy> (view parent)
Sender timestamp
1513114850
DKIM signature
missing
Download raw message
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/12/17 14:34, Consus wrote:
> On 15:31 Tue 12 Dec, Drew DeVault wrote:
>> On 2017-12-12 11:26 PM, Consus wrote:
>>> Try http://mdocml.bsd.lv. It is used by the OpenBSD project. I 
>>> was writing man pages using it myself, it's pretty okay.
>> 
>> mdocml is basically roff with lipstick on, I don't like it much 
>> more than I liked roff. There are other man page generators,
>> too, but they're almost all written in high level languages and
>> require some kind of runtime (god forbid, XSLT). The new tool I'm
>> working on is a small POSIX C99 tool with no dependencies. Its
>> syntax is much easier to write, read, and maintain than mdoc.
> 
> True. But this is more about the high-level documentation, not the
>  tool's synopsis.


(Haha, I didn't even read this part of the thread before sending my
last mail.)

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJaMEziAAoJEMspy1GSK50UcF4QALF4Qog6HvqKI24iT0CXuGQm
MJkIH+RyB2WApGaQdnVQiCkKZ/0rTEnmK/8nKtTrzykAA6hbztsI3k4avNRBxQs8
DzjfuP0klc6NapDSiHm2JxI6oUPXv2IbGf8IDJl1mxquKi+YxM7u137xXO3VReBp
cf6bwHf1R9b7fWWYyOJn0D0W+c0Eo6ZCzepsUaARq85eJNEBHvL9knZkEgsoNaGT
T1gqsFklF4GitYEz84qVPEkLtZQbAGml+tq8GZywxCi6aPWMKWlZZUV7DSA7Khtp
UG3caRR1LNR3Fjitt5k7LbXI+HGtX4a9G5kpPcIU/3AKzx9k6sZOVQk8dX2dQBZR
8JulGiJHIaD3oclxYEQZL0aQOJQvPBWtjTlXW4UIkKjojso3+Pw9s1iMmemV3WBH
6gN+rbJi7h5Yki2/HZycfMhAcN7sC1OH8dYkNVg3ELr+5XIBURFfdLLvQ3cIkpAm
kJ2f50g67qKASbq/wm3dKISlXzc5x/Vs7KgbXgoAbEZKkiTCTbsqeBIvXScOLZR+
b7hUat2YwlSWCjZi2I5HsqnqvSxV24qTCUFLDxRbhYeiKPKrvn30JB92BzqXycEn
ILtzATHPqR+wStw302isIglwswE96FdlgL42A4KAM2gXwLeBE9NKtSABrtHjsyFu
Fsg09H55B7mv1YHrhAzW
=hjIB
-----END PGP SIGNATURE-----


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
William Pitcock
Details
Message ID
<CA+T2pCG0f6S9R70kca3GMX03g886ZsiJ8rRb4AoUt4hjCmsL4g@mail.gmail.com>
In-Reply-To
<20171212202301.GA26329@miku> (view parent)
Sender timestamp
1513116324
DKIM signature
missing
Download raw message
Hi,

On Tue, Dec 12, 2017 at 2:23 PM, Drew DeVault <sir@cmpwn.com> wrote:
> I don't really have any advice for what to do with the wiki, but
> regarding Alpine's core documentation I have some thoughts. Something
> that bothers me about Alpine (and that I'd like to contribute to
> improving) is the lack of man pages for Alpine core stuff. I think a
> substantial portion of the core docs can and should be done this way,
> rather than on the wiki - though it would be nice to render the man
> pages to HTML for display on the web, too.
>
> No one likes writing roff so I've been working on a tool recently to
> help with this:

I don't mind writing roff with the mdoc macro package.  It seems fine to me.

> https://git.sr.ht/~sircmpwn/scdoc
>
> If there's no opposition to this I was hoping to start writing man pages
> for apk shortly.

We prefer to have apk's documentation in mdoc, since it does not
require any preprocessing, but maybe your tool can be useful for other
Alpine projects.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
William Pitcock
Details
Message ID
<CA+T2pCF+XEnB0jOcSRLk08EbgPLCjbrmtvSBtjXhFpLE7UpxOg@mail.gmail.com>
In-Reply-To
<20171212215314.GA4441@miku> (view parent)
Sender timestamp
1513116524
DKIM signature
missing
Download raw message
Hi,

On Tue, Dec 12, 2017 at 3:53 PM, Drew DeVault <sir@cmpwn.com> wrote:
> On 2017-12-12 11:34 PM, Consus wrote:
>> True. But this is more about the high-level documentation, not the
>> tool's synopsis.
>
> Man pages are not limited to the synopsis of tools. Large portions of
> information currently on the wiki is on-topic for man pages:
>
> https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management
>
> apk(8)
>
> https://wiki.alpinelinux.org/wiki/Apk_spec
>
> apk-database(7)
>
> https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
> https://wiki.alpinelinux.org/wiki/APKBUILD_Reference
>
> abuild(1)
>
> APKBUILD(7)
>
> and so on. If an overhaul of the core docs on the wiki is due, then I
> think lots of it should be moved into man pages as the single source of
> truth.

I agree, with the exception that the apk-related manpages should be
written in mdoc (as I said elsewhere).  I think it makes sense also to
be consistent with that policy in apk for abuild, too.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<20171212215314.GA4441@miku>
In-Reply-To
<20171212203455.GC9334@eddy> (view parent)
Sender timestamp
1513115595
DKIM signature
missing
Download raw message
On 2017-12-12 11:34 PM, Consus wrote:
> True. But this is more about the high-level documentation, not the
> tool's synopsis.

Man pages are not limited to the synopsis of tools. Large portions of
information currently on the wiki is on-topic for man pages:

https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management

apk(8)

https://wiki.alpinelinux.org/wiki/Apk_spec

apk-database(7)

https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
https://wiki.alpinelinux.org/wiki/APKBUILD_Reference

abuild(1)

APKBUILD(7)

and so on. If an overhaul of the core docs on the wiki is due, then I
think lots of it should be moved into man pages as the single source of
truth.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
William Pitcock
Details
Message ID
<CA+T2pCHw9mSZ0N04uTKhSGT+CpfihLKK3EKtQ0W2uvuXfwXUzQ@mail.gmail.com>
In-Reply-To
<20171212223049.GA2084@homura> (view parent)
Sender timestamp
1513119601
DKIM signature
missing
Download raw message
Hello,

On Tue, Dec 12, 2017 at 4:30 PM, Drew DeVault <sir@cmpwn.com> wrote:
> On 2017-12-12  4:05 PM, William Pitcock wrote:
>> We prefer to have apk's documentation in mdoc, since it does not
>> require any preprocessing, but maybe your tool can be useful for other
>> Alpine projects.
>
> Summarizing the discussion from IRC on the ML:
>
> mdoc requires either preprocessing or an extra runtime dependency.
> Saying mdoc doesn't require preprocessing is like saying JVM bytecode
> doesn't require compilation.

That is not an accurate summarization.  Alpine's man command includes
the mdoc macro package.

> scdoc is a very light compile-time dependency and is extremely portable.
> The syntax is much friendlier than mdoc (which is unavoidable as long as
> mdoc is based on roff), which makes it easier for more people to
> contribute. mdoc/roff syntax _has_ been a significant barrier for people
> to contribute to projects that use them in the past.

In the case of apk and probably also abuild, it makes most sense that
the documentation be written by the maintainers of that software.
Accordingly, it makes sense that they should use the tools they wish
to use, which in the case of apk, would be mdoc.

> It seems like it's been set in some of your minds that mdoc is the way
> forward. I don't think it's a very rational choice.

Finally, as somebody who is involved in maintenance of apk, I am
stating that I intend to write a manpage for apk at some point during
the 3.8 development cycle.  I just need to get pkgconf 1.4 out the
door first, which ironically, is also blocking on docs right now.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<20171212223049.GA2084@homura>
In-Reply-To
<CA+T2pCG0f6S9R70kca3GMX03g886ZsiJ8rRb4AoUt4hjCmsL4g@mail.gmail.com> (view parent)
Sender timestamp
1513117849
DKIM signature
missing
Download raw message
On 2017-12-12  4:05 PM, William Pitcock wrote:
> We prefer to have apk's documentation in mdoc, since it does not
> require any preprocessing, but maybe your tool can be useful for other
> Alpine projects.

Summarizing the discussion from IRC on the ML:

mdoc requires either preprocessing or an extra runtime dependency.
Saying mdoc doesn't require preprocessing is like saying JVM bytecode
doesn't require compilation.

scdoc is a very light compile-time dependency and is extremely portable.
The syntax is much friendlier than mdoc (which is unavoidable as long as
mdoc is based on roff), which makes it easier for more people to
contribute. mdoc/roff syntax _has_ been a significant barrier for people
to contribute to projects that use them in the past.

It seems like it's been set in some of your minds that mdoc is the way
forward. I don't think it's a very rational choice.

--
Drew DeVault


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Kiyoshi Aman
Details
Message ID
<CAML-UdvdwmUu99ExY=jjKd4LcboBrOBptQrbmCmxrua-sH4LMg@mail.gmail.com>
In-Reply-To
<20171212223049.GA2084@homura> (view parent)
Sender timestamp
1513119583
DKIM signature
missing
Download raw message
Hi,

As an end user, I really couldn't care less how the documentation is
generated. It needs to be complete, thorough, readable for plebes such as
myself, and available. (It also needs to be compatible with enduser
toolchains like mandb and mdoc, since those are the man providers used by
Adélie and Alpine, respectively.)

Please stop squabbling over manpage backend formats and focus on the
relevant issues. Namely, what to do about the wiki, what documentation
needs to be provided and where, and so on.

Thanks,
Kiyoshi

On Tue, Dec 12, 2017 at 4:31 PM Drew DeVault <sir@cmpwn.com> wrote:

> On 2017-12-12  4:05 PM, William Pitcock wrote:
> > We prefer to have apk's documentation in mdoc, since it does not
> > require any preprocessing, but maybe your tool can be useful for other
> > Alpine projects.
>
> Summarizing the discussion from IRC on the ML:
>
> mdoc requires either preprocessing or an extra runtime dependency.
> Saying mdoc doesn't require preprocessing is like saying JVM bytecode
> doesn't require compilation.
>
> scdoc is a very light compile-time dependency and is extremely portable.
> The syntax is much friendlier than mdoc (which is unavoidable as long as
> mdoc is based on roff), which makes it easier for more people to
> contribute. mdoc/roff syntax _has_ been a significant barrier for people
> to contribute to projects that use them in the past.
>
> It seems like it's been set in some of your minds that mdoc is the way
> forward. I don't think it's a very rational choice.
>
> --
> Drew DeVault
>
>
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
>
> --
-- Kiyoshi Aman
Consus
Details
Message ID
<20171212202626.GB9334@eddy>
In-Reply-To
<20171212202301.GA26329@miku> (view parent)
Sender timestamp
1513110386
DKIM signature
missing
Download raw message
On 15:23 Tue 12 Dec, Drew DeVault wrote:
> I don't really have any advice for what to do with the wiki, but
> regarding Alpine's core documentation I have some thoughts. Something
> that bothers me about Alpine (and that I'd like to contribute to
> improving) is the lack of man pages for Alpine core stuff. I think a
> substantial portion of the core docs can and should be done this way,
> rather than on the wiki - though it would be nice to render the man
> pages to HTML for display on the web, too.
> 
> No one likes writing roff so I've been working on a tool recently to
> help with this:
> 
> https://git.sr.ht/~sircmpwn/scdoc
> 
> If there's no opposition to this I was hoping to start writing man pages
> for apk shortly.

Try http://mdocml.bsd.lv. It is used by the OpenBSD project. I was writing man pages
using it myself, it's pretty okay.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Consus
Details
Message ID
<20171212203455.GC9334@eddy>
In-Reply-To
<20171212203147.GA27466@miku> (view parent)
Sender timestamp
1513110896
DKIM signature
missing
Download raw message
On 15:31 Tue 12 Dec, Drew DeVault wrote:
> On 2017-12-12 11:26 PM, Consus wrote:
> > Try http://mdocml.bsd.lv. It is used by the OpenBSD project. I was writing man pages
> > using it myself, it's pretty okay.
> 
> mdocml is basically roff with lipstick on, I don't like it much more
> than I liked roff. There are other man page generators, too, but they're
> almost all written in high level languages and require some kind of
> runtime (god forbid, XSLT). The new tool I'm working on is a small POSIX
> C99 tool with no dependencies. Its syntax is much easier to write, read,
> and maintain than mdoc.

True. But this is more about the high-level documentation, not the
tool's synopsis.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Consus
Details
Message ID
<20171212225931.GA14643@eddy>
In-Reply-To
<5A304BC7.3020401@adelielinux.org> (view parent)
Sender timestamp
1513119573
DKIM signature
missing
Download raw message
On 15:36 Tue 12 Dec, A. Wilcox wrote:
> Is this channel available on Matrix as well?

Honestly, I don't know. It was not me who created it.
 
> This is how we do it in Adélie.  It seems to work well.

Do you have third-party (non-core) contributors? I believe that this
model adds additional complexity for the regular folks. It would be nice
to have a positive example.
 
> I'm glad that Alpine core still realises that.  I have been worried
> lately that there is too much buy-in to GitHub from the Alpine
> developers.  Do we really want all of that valuable discussion about
> PRs and such locked away in a corporation's databases?  How long will
> GitHub stay afloat before turning to ads, pay-to-use, or even just
> plain disappear from the Internet?

Well, it's Git. If GitHub goes dark, there is gitlab / bitbucket / etc.
The migration will be instant. But still, it's better to have the tool
that you can control yourself.
 
> Reduce, but not eliminate.  Honestly, the only true way to eliminate
> spam is to have closed registrations (you have to poke an Alpine
> person to get an account on the wiki).  But that adds a lot of work,
> so it probably isn't a good solution.  Requiring valid email will take
> out 80% of it so I suppose that's a very good start.

Actually, I want to have a chat with Archlinux wiki maintainers about
the spam-reducing. They solved this problem somehow.
 
> I don't think any of this should be stored on the wiki.  All of this
> should be on the main site, and never on the Wiki.  It certainly won't
> change very often, so there's no reason to need for the community to
> be able to edit it.

Yeah, sure, why not. Archlinux an Gentoo just keep this stuff on the
site directly. This opens a question: what else may be considered
sensitive enough? If nothing more than that, than (in my opinion) Wiki
is the perfect match for now, if the spam problem will be solved.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
A. Wilcox
Details
Message ID
<5A32142A.10501@adelielinux.org>
In-Reply-To
<3b2ba193-76a7-c2a3-d93f-e72bdc602c08@bitmessage.ch> (view parent)
Sender timestamp
1513231402
DKIM signature
missing
Download raw message
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/12/17 18:14, Oliver Smith wrote:
> Consus:
>> On 15:36 Tue 12 Dec, A. Wilcox wrote:
>>> Is this channel available on Matrix as well?
>> 
>> Honestly, I don't know. It was not me who created it.
>> 
> clandmeter said he could "fix" this after the matrix server is 
> migrated to new hardware. I'd also like to join the chat once the 
> matrix channel is up and running.


Good to know, thanks!


>>> This is how we do it in Adélie.  It seems to work well.
>> 
>> Do you have third-party (non-core) contributors? I believe that 
>> this model adds additional complexity for the regular folks. It 
>> would be nice to have a positive example.
>> 
> I see it the same way, I'd much rather edit a wiki by clicking on 
> "edit", changing something, looking at a preview, and then saving
> it. There are more arguments, which in my opinion, make MediaWiki
> a superior choice for Alpine, when compared with a git repository


Yes, actually, we only have 3 people on core and 7 total developers
(everyone with commit).  Everyone else is a contributor with no
affiliation.  Our core docs are written in DocBook (an install guide,
which is mostly done, and a developer guide, which is still in draft),
and are written entirely by horst@ and I.  The wiki is written by
everyone.


>> Actually, I want to have a chat with Archlinux wiki maintainers 
>> about the spam-reducing. They solved this problem somehow.
>> 
> 
> I think the Arch wiki has a clever registration questions, which 
> reduces a lot of spam accounts from being created in the first
> place. Right now they have (I don't know if/how often they rotate
> these, and pacman is their package manager, so you'd need to run
> Arch Linux more or less to answer this one):
>> What is the output of "pacman -V|base32|head -1"
> 
> So we could do something similar with `apk` and/or busybox instead
> of pacman.


This might still be confusing for people who are not used to command
lines.  Let's remember that not everyone who uses Alpine wants to (or
/can/) use the command line like that.

I do agree that some Alpine-related questions might be useful.  There
could be more than one, even.


> PS: I don't think requiring a valid e-mail address helps at all.
> It's just annoying and very easy to work around.


Annoying?  I'm genuinely curious to know why having a valid email is
annoying, considering that virtually everyone with an internet
connection at least has an ISP email box.

It is somewhat easy to work around with a sophisticated enough script,
but it is just another way to verify reality.  Maybe not necessary if
we get Alpine-related questions in the wiki sign-up page, but it never
hurts.


Best,
- --arw


- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJaMhQnAAoJEMspy1GSK50UsnYP+wQ5tNVVDtuOy/Jm09yzHs44
Ox82a2z6UFFKhwYCzI799WuRKWArIEe1qLPzbeNwpBedS9xRAki28wpLOeA7MJ6a
EHm1MGtaaVXJVCaEo6tRYc/1kOJWZ1GqqMYkpkmK86w6YMeUBjFKmhyzerr2bMBk
zdE4P31spW9VH+EAf972SIz8CaL6RGIqO+MYkuwkmSQM4yW61ClMSB6YJ1B1z2xU
QxgTJqHzP0/QXiX8OXHKJ2HBhhen2F86uwNaDV3n2X8vtGtnFhaFFIgkdgFqPG5a
5WfjVaH8UUNfjfZrM0xOOJUv6zmDkSpF1vm2xzo51YXpo0uKcL133v/ES0K9/ouW
XZioh5on1XM0Swf7RKavazzPGNUOmBdaLcceIXl6PfgOUx/4kcrvTNGDFS1dcegh
jL8qLRF+dzKTEJtxwxgu/ieDujTeF4ygyZCXlaeMWQLRW5sgjSGZOXXN5evTtGeZ
blVhIDYtlmNRGEx77z3Zlv3lMeUNtjSYTsmIxFAmSZgadEqSW75Zx+FW+ifgvMFN
9k59ser0CXzxWBvOXM6IS+qa6OD/05P3ch78HwjZFeVif88BfLcf1jvFvmlMYJe5
DqmOY6l3wWWSmQxtEKRjOUNjrQcRJtC34ykK/doFbp/ydOaGn2nk7FMF7C2U4K44
V00xY6lRt7VvNhTXSEtm
=I1q/
-----END PGP SIGNATURE-----


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Oliver Smith
Details
Message ID
<3b2ba193-76a7-c2a3-d93f-e72bdc602c08@bitmessage.ch>
In-Reply-To
<20171212225931.GA14643@eddy> (view parent)
Sender timestamp
1513210440
DKIM signature
missing
Download raw message
Hi there,

I like writing documentation in wikis (I'm less interested in man pages, though I
think it's good to have them).

Consus:
> On 15:36 Tue 12 Dec, A. Wilcox wrote:
>> Is this channel available on Matrix as well?
> 
> Honestly, I don't know. It was not me who created it.
>  
clandmeter said he could "fix" this after the matrix server is migrated to
new hardware. I'd also like to join the chat once the matrix channel is up
and running.

>> This is how we do it in Adélie.  It seems to work well.
> 
> Do you have third-party (non-core) contributors? I believe that this
> model adds additional complexity for the regular folks. It would be nice
> to have a positive example.
>  
I see it the same way, I'd much rather edit a wiki by clicking on "edit",
changing something, looking at a preview, and then saving it. There are more
arguments, which in my opinion, make MediaWiki a superior choice for Alpine,
when compared with a git repository:
* It's used for a lot of good distro wikis already (e.g. Arch, Gentoo) and people
  coming from those distros will have it easier to contribute content.
* It's easier to edit when you don't need to make a pull request for everything
* You have actual previews
* You can search the wiki easily
* It is possible to use templates and categorie

>> I'm glad that Alpine core still realises that.  I have been worried
>> lately that there is too much buy-in to GitHub from the Alpine
>> developers.  Do we really want all of that valuable discussion about
>> PRs and such locked away in a corporation's databases?  How long will
>> GitHub stay afloat before turning to ads, pay-to-use, or even just
>> plain disappear from the Internet?
> 
> Well, it's Git. If GitHub goes dark, there is gitlab / bitbucket / etc.
> The migration will be instant. But still, it's better to have the tool
> that you can control yourself.
>
>> Reduce, but not eliminate.  Honestly, the only true way to eliminate
>> spam is to have closed registrations (you have to poke an Alpine
>> person to get an account on the wiki).  But that adds a lot of work,
>> so it probably isn't a good solution.  Requiring valid email will take
>> out 80% of it so I suppose that's a very good start.
> 
> Actually, I want to have a chat with Archlinux wiki maintainers about
> the spam-reducing. They solved this problem somehow.
>

I think the Arch wiki has a clever registration questions, which reduces
a lot of spam accounts from being created in the first place. Right now
they have (I don't know if/how often they rotate these, and pacman is
their package manager, so you'd need to run Arch Linux more or less to
answer this one):
> What is the output of "pacman -V|base32|head -1"

So we could do something similar with `apk` and/or busybox instead of pacman.

Source: <https://wiki.archlinux.org/index.php?title=Special:CreateAccount&returnto=Main+page>

Meanwhile, Alpine's questions are autogenerated and in the form of:

> Given the number three hundred forty-four million one hundred thirty thousand
> two, what is the seventh digit?

Source: <https://wiki.alpinelinux.org/w/index.php?title=Special:UserLogin&returnto=Main+Page&type=signup>

Not fun to answer, less effective because you can answer it without having Alpine
running. And it could be that bots already know how to answer these automatically
(unless Alpine wrote a specific plugin for this).

But if all that does not help with the spam problem, I have found an extension
that might be suitable. Citing from <https://bugs.alpinelinux.org/issues/6774>
with updated dates:
>> How does it work?
>> 1. Every edit (or image upload) by a new user is being sent to moderation.
>> 2. Until the moderator approves this edit, the page is unchanged. Pending 
>>    edit is neither in page history nor on RecentChanges.
>> 3. The user can see his/her edit and continue editing his/her own version of 
>>    the page.
> https://www.mediawiki.org/wiki/Extension:Moderation
> https://github.com/edwardspec/mediawiki-moderation
> From what I can tell they have a maintained code base (last git commit was on 
> 2017-11-06, last release on 2017-10-16), some test cases and also use it in 
> production (that's what they say on the MediaWiki page). Looks good to me, but 
> I have not tried out the extension myself or reviewed the code.

PS: I don't think requiring a valid e-mail address helps at all. It's just annoying
and very easy to work around.

>> I don't think any of this should be stored on the wiki.  All of this
>> should be on the main site, and never on the Wiki.  It certainly won't
>> change very often, so there's no reason to need for the community to
>> be able to edit it.
> 
> Yeah, sure, why not. Archlinux an Gentoo just keep this stuff on the
> site directly. This opens a question: what else may be considered
> sensitive enough? If nothing more than that, than (in my opinion) Wiki
> is the perfect match for now, if the spam problem will be solved.
> 
> 
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
> 
> 

Thanks,
Oliver Smith



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Carlo Landmeter
Details
Message ID
<CA+cSEmM3=qJ2E=AdxEsUparfF1w-gzGryzyUqzbmxh9tcH5SaA@mail.gmail.com>
In-Reply-To
<5A32142A.10501@adelielinux.org> (view parent)
Sender timestamp
1513246989
DKIM signature
missing
Download raw message
On 14 December 2017 at 07:03, A. Wilcox <awilfox@adelielinux.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 13/12/17 18:14, Oliver Smith wrote:
> > Consus:
> >> On 15:36 Tue 12 Dec, A. Wilcox wrote:
> >>> Is this channel available on Matrix as well?
> >>
> >> Honestly, I don't know. It was not me who created it.
> >>
> > clandmeter said he could "fix" this after the matrix server is
> > migrated to new hardware. I'd also like to join the chat once the
> > matrix channel is up and running.
>
>
> Good to know, thanks!
>
>
synapse migration is finished and the room is available.

I also talked to nangel and he would make an email address mandatory (not
sure thats done already).


-carlo
Paul Zillmann
Details
Message ID
<CAHadr3ON7JkRDfV-7tdVdXOO0kEpm9=0yS_sZ=tEQAWdy7oB=A@mail.gmail.com>
In-Reply-To
<3b2ba193-76a7-c2a3-d93f-e72bdc602c08@bitmessage.ch> (view parent)
Sender timestamp
1513250775
DKIM signature
missing
Download raw message
>From a user's perspective:

The wiki registration isn't hard at all. Trouble I had: the proxyserver
gave me an error message[1]
Two days later I registered myself successfully. I wanted to edit a section
which doesn't contain any IP addresses [2], but I couldn't save.
The error message was that I'm not allowed to publish IP addresses in the
wiki.

After that I looked up any contact information about the doc team (Wiki
administrators, moderators or any mailing list etc.) but I couldn't find
any.
Obviosly the alpine-user list doesn't bother with documentation problems.

I heard about docs.alpinelinux.org in this thread for the first time.
Where is the difference to the wiki?

[1] https://lists.alpinelinux.org/alpine-user/0205.html
[2]
https://wiki.alpinelinux.org/wiki/Configure_Networking#Enabling_IPv6_.28Optional.29

Greetings,
Paul
Natanael Copa
Details
Message ID
<20171215091236.324b290c@ncopa-desktop.copa.dup.pw>
In-Reply-To
<20171212201302.GA9334@eddy> (view parent)
Sender timestamp
1513325556
DKIM signature
missing
Download raw message
On Tue, 12 Dec 2017 23:13:05 +0300
Consus <consus@ftml.net> wrote:

> Hello,
> 
> I'm writing this email to start an archived discussion about the future
> of the Alpine Linux documentation.

Hi!

Thank you for bringing this up. I agree that we need to improve
documentation and I have been thinking about it for a while.

...

> 2. We move the core project documentation somewhere else
>    (https://alpinelinux.org or https://docs.alpinelinux.org) but keep
>    Wiki in place for the community. This way the core project
>    documentation is stored somewhere safe (probably in Git) and GitHub
>    pull-requests or patches via ML are used to update it.

This is the solution I would like to go for, that is, some of the
official documentation is moved out from mediawiki to something else,
like docs.alpinelinux.org and manpages, while much of the docs stays on
wiki.

We need to keep in mind that there are different kinds of
documentation. For example:

install doc: how to do the install
administrator doc: the overview doc on how to do basic things in alpine
manpages: technical docs and specifications for individual tools
contributor doc: how to get involved in the project
developer doc: how to get started with development
infra doc: documentation of our infra structure
community docs: how to set up some specific hard/software


If you are first time user of alpine, and wonder how to get started,
then man pages may not be that helpful. You need an install doc that
can guide you throught the install. What is the difference between
sys/data/diskless install? When do you use what?

After the install is done, the user may need some guidance to do the
basic admin stuff, like (re)configure network, add users, change
password, find and install software, start and stop services.

Those docs can link to the manpages, which are more in-depth docs for
each tool. I don't have strong opinion on the format of the man pages.
Personally I would prefer write things in markdown or asciidoc, but I
don't mind writing directly in mdoc. (would be nice to have a filter
for cgit to parse mdoc)

The contributor and developer docs includes the Alpine linux project
processes and policies. How do you report bugs? How do you submit
patches? How do we include new developers? How do you become an aports
maintainer? How/when do new developers get git push access? What do we
do when someone leaves? How do a developer tag a new Alpine release?
Who are on the infra team? Who are the core developers? How/when are
releases made?

The community docs are things like, how do I get this USB wifi dongle
to work under alpine? How to install and set up apache, nginx, postfix
etc.


The question is now, how much of the above do we keep in wiki and how
much do we move out from wiki?

I think that manpages should be kept in the project it belongs to (eg
apk man pages should be stored in the apk-tools git repo, etc).

I think we should move things that are policies out of wiki too, things
like how to become a developer, how to contribute monetary, how the
release process works
(https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases)

I also don't think we can expect to move everything out from wiki and
moving things will take time. So we need to keep the wiki in good shape.

What I think we should do with the wiki:

- fix the registration process for new users
  (https://lists.alpinelinux.org/alpine-user/0205.html)

- Remove duplicates:
  https://wiki.alpinelinux.org/wiki/Alpine_Linux:Mailing_lists
  https://wiki.alpinelinux.org/wiki/Alpine_Linux:IRC

- Remove obsolete/outdated docs

- Write how to create good content on the wiki (something like
  https://wiki.archlinux.org/index.php/Help:Editing)

- Update the style/css?


I think that would be a good start at least.

What documentation is currently missing?

Other thing I think we should do is to make sure that every git repo
has a README, which includes:
- what is the purpose of the software project
- how do you get started (how to build)
- where to find info on how to report bugs and get involved (links)

Thanks!

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
A. Wilcox
Details
Message ID
<5A345AC2.6060003@adelielinux.org>
In-Reply-To
<20171215091236.324b290c@ncopa-desktop.copa.dup.pw> (view parent)
Sender timestamp
1513380546
DKIM signature
missing
Download raw message
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/12/17 02:12, Natanael Copa wrote:
> We need to keep in mind that there are different kinds of 
> documentation. For example:
> 
> install doc: how to do the install administrator doc: the overview
> doc on how to do basic things in alpine manpages: technical docs
> and specifications for individual tools contributor doc: how to get
> involved in the project developer doc: how to get started with
> development infra doc: documentation of our infra structure 
> community docs: how to set up some specific hard/software


I agree this is a good split of the docs.


> Those docs can link to the manpages, which are more in-depth docs
> for each tool. I don't have strong opinion on the format of the man
> pages. Personally I would prefer write things in markdown or
> asciidoc, but I don't mind writing directly in mdoc. (would be nice
> to have a filter for cgit to parse mdoc)


This may already be true.  It depends on what syntax highlighter
Alpine cgit is using:

https://wiki.archlinux.org/index.php/Cgit#Syntax_highlighting

Unfortunately `highlight` does not support man (or asciidoc!), but
`pygments` does support both:

http://pygments.org/docs/lexers/#lexers-for-non-html-markup-languages


> I think that manpages should be kept in the project it belongs to
> (eg apk man pages should be stored in the apk-tools git repo,
> etc).


Yes, definitely.


> Other thing I think we should do is to make sure that every git
> repo has a README, which includes: - what is the purpose of the
> software project - how do you get started (how to build) - where to
> find info on how to report bugs and get involved (links)


Would rST format be okay for this?  I could use the templates we have
in Adélie for README / CONTRIBUTING files and write some for apk-tools
and abuild if you like.  Here is an example:

https://code.foxkit.us/adelie/shimmy/raw/master/README.rst
https://code.foxkit.us/adelie/shimmy/raw/master/CONTRIBUTING.rst


Best to you and yours,
- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJaNFq/AAoJEMspy1GSK50UGjQQAKtj8W5dnWK7PtwUS/rdsSs3
pIDAFE+XFxXs1nyugvOaIHIQ+qXBehp+ryq2kNP8DZOVr5GiYUZmU+iFWbZ6HucV
Q4XtWnSKJFBSQ3isDp1HHTMPlZB1SBFHE+R60Xptdv8wdKsWqA2LUmI2HminO0nB
U2Mo0oMm9ojEXBHY/CBoFsN28GTub1FmgU4EZs5MNORUPlMo6N6pKe5E976Qr9Sp
bJj5agyQk0h7eTBYJQBGTLDFvb+KZCxhmsCLyoYP+74A1XSoJkUYQ2TNMvvDrID/
YlvEwvhm6BOL7Ck9E/nbU1VJRxOtxNc2fBWqBjtXH28sA3tK3XOFnkmzpD3f5XnK
ZFszcoA8u5FWyIb358WIASk+2eBTSa7o9dwoPoCR3qHHuyAid8n1exNNWlO8EAW/
w8SYOuc385M805iCFRYn/opP3+jyHEVJwgcFS1ea8e7hMItQmv2DgzyyEWjRwgQ1
ZR/mIHfuNPxTmdknNxYW81WbzTFPEFwc2/n7v4sd9NPctDkmDi/Lve2qAPQ2inrr
2UdveVw1YfYDbKF11+VnpMcdWarS2x1tqIakGrSwPsBISxaz6ZKYvdtal8dg+C4t
yQuyZU96NsB5AYNeXMNJljxGcfVzw7bCQ1F1hACrqla24p06Lvb4vB/gffONexTi
+joyzbluEL/KaEt9jYAv
=gInG
-----END PGP SIGNATURE-----


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Stuart Cardall
Details
Message ID
<d15f7c25-b11e-e308-334e-dc09cb89c83c@it-offshore.co.uk>
In-Reply-To
<20171215091236.324b290c@ncopa-desktop.copa.dup.pw> (view parent)
Sender timestamp
1513369419
DKIM signature
missing
Download raw message
I started creating README.alpine docs with notes to get things working:

musl64 [~/aports]$ find . -type f -name README.alpine
./community/elasticsearch/README.alpine
./community/runit/README.alpine
./community/lxcfs/README.alpine
./community/autossh/README.alpine
./community/mini-sendmail/README.alpine
./testing/pass/README.alpine

Stuart.


On 12/15/2017 08:12 AM, Natanael Copa wrote:
> On Tue, 12 Dec 2017 23:13:05 +0300
> Consus <consus@ftml.net> wrote:
>
>> Hello,
>>
>> I'm writing this email to start an archived discussion about the future
>> of the Alpine Linux documentation.
> Hi!
>
> Thank you for bringing this up. I agree that we need to improve
> documentation and I have been thinking about it for a while.
>
> ...
>
>> 2. We move the core project documentation somewhere else
>>    (https://alpinelinux.org or https://docs.alpinelinux.org) but keep
>>    Wiki in place for the community. This way the core project
>>    documentation is stored somewhere safe (probably in Git) and GitHub
>>    pull-requests or patches via ML are used to update it.
> This is the solution I would like to go for, that is, some of the
> official documentation is moved out from mediawiki to something else,
> like docs.alpinelinux.org and manpages, while much of the docs stays on
> wiki.
>
> We need to keep in mind that there are different kinds of
> documentation. For example:
>
> install doc: how to do the install
> administrator doc: the overview doc on how to do basic things in alpine
> manpages: technical docs and specifications for individual tools
> contributor doc: how to get involved in the project
> developer doc: how to get started with development
> infra doc: documentation of our infra structure
> community docs: how to set up some specific hard/software
>
>
> If you are first time user of alpine, and wonder how to get started,
> then man pages may not be that helpful. You need an install doc that
> can guide you throught the install. What is the difference between
> sys/data/diskless install? When do you use what?
>
> After the install is done, the user may need some guidance to do the
> basic admin stuff, like (re)configure network, add users, change
> password, find and install software, start and stop services.
>
> Those docs can link to the manpages, which are more in-depth docs for
> each tool. I don't have strong opinion on the format of the man pages.
> Personally I would prefer write things in markdown or asciidoc, but I
> don't mind writing directly in mdoc. (would be nice to have a filter
> for cgit to parse mdoc)
>
> The contributor and developer docs includes the Alpine linux project
> processes and policies. How do you report bugs? How do you submit
> patches? How do we include new developers? How do you become an aports
> maintainer? How/when do new developers get git push access? What do we
> do when someone leaves? How do a developer tag a new Alpine release?
> Who are on the infra team? Who are the core developers? How/when are
> releases made?
>
> The community docs are things like, how do I get this USB wifi dongle
> to work under alpine? How to install and set up apache, nginx, postfix
> etc.
>
>
> The question is now, how much of the above do we keep in wiki and how
> much do we move out from wiki?
>
> I think that manpages should be kept in the project it belongs to (eg
> apk man pages should be stored in the apk-tools git repo, etc).
>
> I think we should move things that are policies out of wiki too, things
> like how to become a developer, how to contribute monetary, how the
> release process works
> (https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases)
>
> I also don't think we can expect to move everything out from wiki and
> moving things will take time. So we need to keep the wiki in good shape.
>
> What I think we should do with the wiki:
>
> - fix the registration process for new users
>   (https://lists.alpinelinux.org/alpine-user/0205.html)
>
> - Remove duplicates:
>   https://wiki.alpinelinux.org/wiki/Alpine_Linux:Mailing_lists
>   https://wiki.alpinelinux.org/wiki/Alpine_Linux:IRC
>
> - Remove obsolete/outdated docs
>
> - Write how to create good content on the wiki (something like
>   https://wiki.archlinux.org/index.php/Help:Editing)
>
> - Update the style/css?
>
>
> I think that would be a good start at least.
>
> What documentation is currently missing?
>
> Other thing I think we should do is to make sure that every git repo
> has a README, which includes:
> - what is the purpose of the software project
> - how do you get started (how to build)
> - where to find info on how to report bugs and get involved (links)
>
> Thanks!
>
> -nc
>
>
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
>