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