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

Thu Dec 12 13:46:46 UTC 2019

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

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_versioning

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20191212/d51c64f7/attachment-0001.sig>