[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