[arch-dev-public] Proposal: Build a ruleset for new packages and package quality

Thu Dec 12 12:21:42 UTC 2019

Hello everybody,

Due to a longer discussion around alpha and beta packages in our
repositories in IRC yesterday, I would like to start a hopefully more
constructive discussion around this topic on the ML.

Short summary for everybody what happened:

I wanted to get caddy2.0.0-beta into [community], people started
discussing that we don't ship betas in our repositories and I should
either wait or ship the stable caddy v1 release.

I don't want to start this discussion around caddy again (I will wait
for a stable release). What I want to accomplish with this mail is:

1. find a consensus on rules which packages we allow in our repositories
and which don't.

2. find a consensus on rules on violating our rules regarding package
requirements. (e.g. What happens when TU/Dev XY violates our package
requirements? what is the punishment?)

3. revive the discussion around better PKGBUILD quality (see also Eli's
thread about  PKGBUILD quality on arch-tu:
https://lists.archlinux.org/private/arch-tu/2019-November/000083.html)

4. I would like to have this rules written down somewhere, either in the
TU bylaws (in dev bylaws if this exists) or in a new format like
"community bylaws" (maybe we could combine this with the question about
a new leader).

5. What do we do with the existing beta and alpha packages? Are they
granted asylum? Or do we remove them, to be consistent?

extra libmspack 1:0.10.1alpha-2
extra qt5-webkit 5.212.0alpha3-6
community d-containers 0.8.0alpha.19-1
extra frozen-bubble 2.2.1beta1-14
extra hddtemp 0.3.beta15.53-1
extra libcaca 0.99.beta19-2
extra tsocks 1.8beta5-8
community hydrogen 1.0.0beta1-1
community lablgtk3 3.0.beta6-2
community modclean 3.0.0beta.1-1
community sdedit 4.2beta8-1
community sniffit 0.3.7.beta-17
community vbindiff 3.0_beta5-1
community wqy-microhei 0.2.0_beta-9
community wqy-microhei-lite 0.2.0_beta-9

6. How do we define stable packages? beta or alpha is just a human made
word. I've seen devs who said their "1.0" version is unstable and
shouldn't be used in production. Should such a software get packaged?
And what about projects who use semantic versioning (the devs said so),
but they have a 0.* prefix release?

7. Another topic is a rule about "touching packages of others". In the
#archlinux-tu channel we came to the conclusion that TUs or devs should
ask the package maintainer before touching another devs/TUs package, how
do we want to handle this? Is this the consensus, or are touches without
prior question allowed? What do we do if somebody violates our rules?
etc

8. A few guys in the IRC pointed me to this guidelines in our wiki:

Note: This page is only editable with Wiki-Admin/Dev Permission.

https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_versioning

My questions to this guidelines:

8.1. under which consensus where this rules defined? Are these rules the
result of a developer vote? of a leader decision? Or are they made up by
a few persons without consensus.

8.2  I can't find any list about punishments for violations of these
rules.

8.3 There is no documentation about our alpha and beta packages. I see
that there are exceptions for alpha and betas, but it's not clear for me
how these exceptions apply to the packages we have in our repositories.

This needs to be documented, otherwise every person could push an alpha
package and just 'claim' that one of those exceptions apply for the
package and if nobody checks this claim, the package will be in the
repository.

9. Do we consider packages, that are build from the latest git tag, as
alphas or betas? >> pacman -Ss|grep -E '\+[0-9]+\+g'

10. Do we need to ask software developers in the future if they consider
their project stable? It's not clear which versioning schema the devs
use, some consider their 0.1 release as unstable, some consider it as
stable. Is semantic versioning applied? Do they follow a different
schema?

11. What do we do when a package is stable, but the API is unstable? Is
the whole package considered unstable? The current guidelines are not
clear about APIs, but many users use Arch Linux for software development
and maybe rely on stable APIs.

Disclaimer: I don't know how we want to find concensus yet (TUs have a
transparent vote process, but devs don't have an equivalent for this),
therefore I hope for a "final decision" of our still-leader aaron.
This topic doesn't need to be decided this year. I am fine with reviving
this thread in January or late replies in January.

Best regards,
Chris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20191212/f7c6577a/attachment.sig>