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 <[EMAIL PROTECTED]> wrote: > > On Mon, Nov 10, 2008 at 10:31 AM, w9ya <[EMAIL PROTECTED]> 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?).
