Sparemint website progress this time

Maybe my life is boring, but I encountered what I feel to be a major problem. The new sparemint site is designed to be 100% community controlled, perhaps with a web administrator to handle db emergencies and such, but it's designed such that so long as a few people are around, sparemint can progress. Not to say Frank Naumann will disappear at any point in time, but I firmly believe bringing the community into the process will help to germinate a growth in MiNT. Because of this, one of the most complex parts of the website is the package upload section. The way this works is that a user will upload a package to a specific dir on the ftp server. Once they do, they will show up in a directory listing provided for the user when he hits "upload a package". Now just to make sure it picks the right ones, it asks the user to select his packages residing in this folder (rather than guessing). All packages have at least a source and binary rpm. Some packages have multiple binary rpm's. This creates an interesting management issue. Do you allow users to vote for whether or not individual portions of an upload are correct or the entire thing? I chose the entire thing, and as such, when a user uploads for instance curl, curl-devel and curl.src.rpm, the site has to make heads or tails of what the user is providing to it. The source is easy to figure out, but how do you figure out the "primary" binary package. Well that's easy just use "curl" .. the base name. "curl-devel" and "curl-docs" will be "child" packages. Simple enough until today. libungif has two binary packges. libungif-devel and libungif-progs. Do you see the problem? ;) No primary package was selected due to no package having the name "libungif" and hence two primary packages were shown! I decided that what will work best is to simply use the first package in a db return as the "primary" package and make any other packages dependent. The effect that making this kind of decision provides is that when a user logs in and sees packages to approve or disapprove, he will see one approve/disapprove option for "python", and it will show all the child packages "python-devel", "python-libs" etc.

The voting systems has changed immensely in the last couple days. There's now a separate lookup table for it and you can now vote to approve or disapprove a package. The package uploader has full delete powers. If he finds an issue he can immediately kill the package and reupload it. Once a package is uploaded, two other users will have to either vote to approve or disapprove the package. Disapprovals must enter a special reason which will be displayed. All in all when it's done, it'll be very nifty I think. I feel it'll create a sense of warmth when people upload packages and see that multiple atari users test their contribution and say "I agree, this works well :)".

There's a lot of polish that needs done before it's really ready for prime time and before it's really something I'd want to attach my name to. Those who have seen my PHP helpdesk suite might understand - pretty much everything is clickable and interrelated on every screen and it makes for an interesting navigational experience. Everything is logged and every serious action must have a reason tagged to it. If something like this gets put into the sparemint site (which it is) users will be able to see the rationale behind decisions. It should be pretty nice. I'm trying to make it smart too - don't flood your homepage with packages, show the first 5 and give the option to list more. After a package gets approved or disapproved it shouldn't just disappear from the homepage but should stick as a news item possibly with the reasons why disapproved. No reasons for approved though - the package is approved because it works!

The most supreme benefit however is the repository system IMHO. We can create a new "test" repository which is setup for glib2, gtk2, a new x server, gcc3, etc. One thing that will make building this all much easier is a proper working chroot in freemint. I've looked into implementing this but I just got confused ;) Without this, I'll have to bootstrap on a whole new partition. The entire time I'm doing this, my falcon will be unuseable for anything else. I don't like that and it's going to be tough to make real progress under that circumstance.

On a side note, check out zview beta 6! Wow! Is that an atari program? So gorgeous, so perfectly working! First time I've ever managed to render a single pdf on my atari without using a direct unix port like xpdf. The polish on this program is AMAZING. Reminds me of a professional pc or mac application.


I swear I already posted a reply.. maybe I didn't submit it?? Guess I'm losing it!

But anyways, Why not add some radio buttons Mark on the upload page stating if the file is primary, doc.. etc.
To be honest, I haven't tried the system. I just recreated my account on the test site today.


Rob, the new account is approved and you already had an account created. The password request forms and confirmation email code isn't finished yet since that's also "polish". I could have done the radio buttons or checkboxes or whatnot but I think this system will work. The primary package in inheritance only matters for package approvals/disapprovals so the only point is to ensure that they get grouped together as an upload. For most packages the automatic determination will be perfect, for some it may be slightly off, but we'll worry about it if it becomes an issue.