On Mon, Nov 10, 2008 at 06:47:32PM +0100, Angel Velásquez wrote:
On Mon, Nov 10, 2008 at 6:21 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Nov 10, 2008 at 10:31 AM, w9ya <w9ya@qrparci.net> wrote:
1 - I maintain an offshoot version of archlinux, derived from faunos, called "shackstick". It is used and is becoming quite popular amongst the ham radio community. It is packaged as a whole and the user does NOT download packages or even is part of the arch linux community, so NO votes are taken. Yet it uses over 25 of my packages that would seem to otherwise be without votes.
Just to point out a flaw here. Users of these packages are not ArchLinux users. They are shackstick users. So votes don't make sense for ArchLinux. These packages would not make sense in an ArchLinux repo, on an ArchLinux server, for use by 1 or 2 ArchLinux users, and a few hundred users of another distribution. So, in the case you have outlined, the voting is working perfectly as intended.
The explain that bfinch shows is not the case, as I said (second time this day), there is an amount of packages (aspell,i18n related) which break the rule about "votes needed". I mean, maybe there is not chinesse support in Arch Linux, but why if we got a TU or Dev who speaks chinesse and he wants to move chinesse language packages to community?, he won't be able cause the packages aren't enough voted? this is very unfair, and that's why I think votes isn't the unique point to focus when a package is moved to community. I understand the fact about moving -non-popular or unuseful- packages to community and waste resources, is bad, and I know that exists hundres of packages without votes, IMHO the correct way to handle this is simply, the TU who add packages with very few votes should give a good reason about why he did it, and in case other TUs aren't agree the TU who upload the package should find better reasons, and try later. And again *language packages break the rule* simply.
Thanks
Yeah I agree there should be room for some exceptions. Dependencies would be the obvious exceptions, and maybe perhaps i18n packages should be included as well (optdepends?).