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

[Eli Schwartz]

On 12/12/19 7:21 AM, Christian Rebischke via arch-dev-public wrote:

> 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

qt5-webkit is a security-critical component (a browser), and upstream
has not historically been good about updating the version of webkit they
build on. Currently, there is a years-long effort by annulen, to fix
this and get webkit back into good shape. Given a choice between no
qt5-webkit, a qt5-webkit which is so ancient it's intolerably dangerous,
and packaging the resuscitated annulen version, this is an acceptable
exception.

> 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

I know this one too:
https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/hydrogen&id=bf63a0be79e954863a014bb9ea23157aaf70d7c4

We needed to upgrade to the beta in order to migrate from qt4, which was
in the process of being dropped, to qt5. It was not a lightly made decision.

> 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

I'm unsure / have insufficiently researched the other cases, but I do
dearly hope that their respective maintainers considered the tradeoffs
before packaging an unstable release.

> 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?

Semantic versioning defines 0.* as stable, so this is not a question.

As per semantic versionining, a version indicator ending in one of the
globs:

-alpha*
-beta*

is considered an alpha or beta prerelease and therefore unstable.

> 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.

The most likely place to find out about exceptions is by reading the
svntogit commit logs, which is an excellent place to store information
about, well, changes made to the package, and I encourage people to make
use of that fact. :)

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

Well, those don't build from "the latest git tag", they build from "the
latest git commit" perhaps. Given it is not tagged upstream as a stable
release, nor is it tagged upstream as an alpha or beta, it seems obvious
to me that they are not alphas or betas or even stable releases... they
are *-git packages.

> 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?

Semantic versioning as well as common convention states that they are
stable, if upstream says that it's actually only beta quality then I
encourage you to do some soul searching about whether to package it.

Most software with a 0.* version will be versioned that way because "we
are not ready to commit to a stable API, so any new version has the
potential to change how the software works, to the same degree that a
semver major version can". Alternatively, the software is not yet
"feature-complete".

That doesn't mean they are "unstable". I'm not going to refuse to
package, for example, community/sigil because they have been a 0.*
release for 10 years, and are currently running alphas in preparation
for their celebratory 1.0 release now that they have a stable plugin
ecosystem *and* removed the ancient restrictions on a .epub's internal
directory layout.

I'm also *not* packaging "Sigil-0.9.991 (pre Sigil-1.0) Alpha Release",
even though the version tag, "0.9.991", does not contain the scary
"-alpha*" suffix. And even though "but it's only a 0.* release, so
obviously this is YOLO alpha software and what's the difference between
packaging one alpha version and another alpha version"... no. I can tell
the difference between 0.9.18 (stable) and 0.9.991 (alpha), and github
releases even helpfully provides semantic labels for this:

0.9.991 has the orange "Pre-release" label
0.9.18 has the green "Latest release" label

> 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.

The whole package is considered to require effort to migrate from one
version to another, to the same degree that a semver major update
changes around APIs in completely arbitrary ways.

Would you argue that migrating from version 6.8 of some software, to
7.0, is "unstable API"?

Many users rely on Debian for software development, because they'd
rather use the same old API for 5 years.

Many others use Arch Linux because they'd like to test out and adapt to
new semver major versions of an API before e.g. Debian breaks, and also
because new stuff is nice. Should we penalize them as well as every
other user altogether, by utterly refusing to package the software in
the first place, "because its API isn't stable from one version to the
next yet"?

I really do not understand why you are conflating semver-stable 0.* with
semver-unstable -alpha*, it's totally not how things work.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

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