Suggestion for new package management scheme

Question

As was talked about in the INCOMING thread, Arch is growing and the devs are having trouble keeping up with maintaining packages. Arch is becoming disorganized and messy.
Well, Xentac and I were discussing this for a while, and we both seem to like a voting system. Arch shouldn't try to maintain every package out there, it's simply a waste of effort. If only one or two people want a package, they can build it themselves, it's not hard with ABS.
Arch devs should focus on keeping packages high quality, up to date, etc. They can't do this if there's 10,000 packages. So the solution would be that a package won't be included in the official repos (current, extra, unstable) unless it gets a certain number of votes, showing that lots of people really want the package, and it's "essential".
I don't know how many votes a package would need, but that's a little thing. I would suggest all packages in Extra/Unstable initially go up for this voting (once we implement it) and we make the vote quota be a little lower for this initial slimming, and that'll cut down the repos right there. All those packages that no one uses (that wont even get one vote) can be cut away. People can always vote them back if they become popular.
I don't want to have to do things like KDE, GNOME, etc myself, but I really don't mind maintaining my own little customizations, like Rhythmbox w/ XINE support (instead of Gstreamer). This vote system simply makes sure that a package is worth the developers time.
This goes with my idea of Arch as the perfect "Base" distro. People can build what they want on top of it.
This idea would also remove STAGING, as Arch wouldn't be accepting outside packages (though you're free to run your own repo or post PKGBUILDs on the forum). TESTING would be still used of course.
Suggestions?

Answer 1

beniro wrote:
I haven't really seen a single post in this thread that is without some merit, or at least an attempt at input.
The great thing about not being a larger distro is that the situation isn't as pressurized.  Still, though, we (meaning the community AND developers) still obviously want Arch to be the best it can be and that's what this thread is about.
So...are any of the ideas mentioned here feasible?  What do you think would be the best solution to creating a package release system that can handle Arch's current growth?
What about implementing a vote-based system for everything not in current?  Would this be done with a web-based interface by using "submitrequest/vote" or something...obviously only registered users should be voting, right?
Anyway, I think a great job is being done and this thread is simply a positive indication of the vitality of the community.  I think most of us fully recognize the resources of our developers and are simply wanting to find a way for them to bring us the best possible product.  Arch rules!
I agree. I think what we should do is just take this time that we have while Arch is still young and not as well known among the Linux community, and try to make it great, relieving the pressures that we'd get a lot of later (not to say that we wouldn't get any, just less, hopefully).
As for the package setup, isn't there some way that we could write some system to do this? I had mentioned it before. And, I just came up with a small system. It would work like this:
We get one main server, whose "job" would be to create and store packages, and users could download from that server to install, etc. Now, whenever someone on the package management team finds an updated version of a package, they could log in to a special area of the site meant specifically for those developers. Then, using the special program on the website/server, they could link to the .tar or .bz2 that contains the source and submit it, along with the file's information that would be included with the package when you install it (file name, version, etc.) into the web-based form. Then, they click submit, and the server processes that file after downloading it, runs a makepkg-type thing on it, and stores the produced package in a "Fresh" repository. Then, the developer can download the file and opt to test it. If they're sure that it's okay, then they can replace the new file over the old one.
Just an idea, tell me what you think... :?