[arch-dev-public] Proposal: Build a ruleset for new packages and package quality
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_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. 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
On 12/12/19 1:21 PM, Christian Rebischke via arch-dev-public wrote:
8.2 I can't find any list about punishments for violations of these rules.
Best regards, Chris
Do we have such lists of punishment in any of our other guidelines? I think we generally assume that other team members are acting in good faith, if someone is doing something by mistake - point them towards it and I'm sure you can figure it out. All without threatening someone with /punishments/. -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On Thu, Dec 12, 2019 at 01:40:19PM +0100, Public mailing list for Arch Linux development wrote:
On 12/12/19 1:21 PM, Christian Rebischke via arch-dev-public wrote:
8.2 I can't find any list about punishments for violations of these rules.
Best regards, Chris
Do we have such lists of punishment in any of our other guidelines?
I think we generally assume that other team members are acting in good faith, if someone is doing something by mistake - point them towards it and I'm sure you can figure it out. All without threatening someone with /punishments/.
-- Rob (coderobe)
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
This is indeed an argument, although it's difficult to differ between a mistake and a "mistake". If you get what I mean. Chris
On Thu, 2019-12-12 at 13:21 +0100, Christian Rebischke via arch-dev-public wrote:
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.
For the ones that were not in the discussion about caddy: The caddy devs consider 2.0.0-beta10 stable software but not stable API. From https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_version...
Stable packages package stable releases
I think this means stable software *and* stable API. Projects that depend on a certain library are not expected to be using beta releases. They will most likely only update once the library authors commit to a certain API. For most cases I don't think we should be packaging unstable APIs.
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?)
No punishments. As coderobe said, we should assume good faith. If someone is breaking the rule, ask them to fix it. If they continue to do it then I think it's means for disciplinary action, even removal if needed. I believe this should apply to both TUs and Devs.
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).
This should be in the packaging guidelines, not on some community or TU specific guilelines. I also think any sort of bylaws are not the correct place for this, there are to many exceptions for this to be correctly described in that kind of document.
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
Well, it depends on the case. As a general rule just don't package -beta.
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?
True. We can't make rules based on version strings, each case needs to be analyzed. If the software is stable and the API is stable then package it.
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
This is the same as 2), assume good faith. If people abuse it then that should be grounds for disciplinary action.
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.
It's not trivial to document and I don't think we should spend huge amounts of time deciding what to write. I think [1] is good enough, the team can discuss situations on a case-by-case basis. [1] https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_version...
9. Do we consider packages, that are build from the latest git tag, as alphas or betas? >> pacman -Ss|grep -E '\+[0-9]+\+g'
Generally, yes. Please note that pacman -Ss|grep -E '\+[0-9]+\+g' does not represent anything of sorts, people can be checking out a specific commit.
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?
If it's not clear, yes.
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.
I answered this already, but basically try your best to not package unstable 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
Thank you, Filipe Laíns
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
[2019-12-12 13:21:42 +0100] Christian Rebischke via arch-dev-public:
1. find a consensus on rules which packages we allow in our repositories and which don't.
There's no need for hard rules except "don't put stuff in the repos that will cause legal problems". We certainly strive to ship stable versions. But for some projects those are outdated and there are valid reasons to prefer shipping a newer release even if it's tagged as unstable by upstream. Those decisions are left to the best judgment of individual maintainers. If a conflict arises, it should be discussed on this mailing list.
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?)
If there's a disagreement as to what should or should not be packaged, it should be discussed here on a case-by-case basis. If consensus is reached that the package should be removed, then the packager must remove it. Obviously if the packager does not abide the decision made, there will be serious repercussions. But there's no need to set anything in stone: this will be decided on a case-by-case basis.
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
We shouldn't aim to replace those packages just because they have alpha or beta in their name. Assume the individual maintainers made an informed decision. Now if someone has a good reason why we should ship a different version than the above for a given package, please bring it up and we can discuss it. I can only speak for hddtemp and tsocks: they're old releases, but there hasn't been any newer one and their last stable release are really ancient. Those "beta" releases provide the best feature/stability for our users.
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
If it's something as trivial as a pkgrel bump and rebuild, no permission is required. If it's something more substantial, it should be discussed before. As usual, if a conflict arises, it should be discussed here.
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.
They're just guidelines. Try to abide them and when you don't make sure you have a really good reason not to.
8.2 I can't find any list about punishments for violations of these rules.
Again, punishment is uncalled for at this stage. If a packager repeatedly ignores warnings and repeatedly violates decisions made by consensus, then sure, we'll start a discussion about removing them. Cheers. -- Gaetan
On 12/12/19 10:21 pm, Christian Rebischke via arch-dev-public wrote:
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)
Any chance that can be posted somewhere visible to those that aren't TUs? Allan
participants (6)
-
Allan McRae
-
Christian Rebischke
-
Eli Schwartz
-
Filipe Laíns
-
Gaetan Bisson
-
Robin Broda