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

[Gaetan Bisson]

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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20191212/67f8e863/attachment.sig>