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