TUR on speed -- some thoughts

Haakon · 2004-11-10 13:10:16

I know there is some work going on to replace the current dysfunctional "incoming" scheme. I would like to share some ideas that could make such a system kick-ass, IMHO.

There is a web system, where you register a user for yourself. Now you can upload your own PKGBUILD files, and when it arrives at the system, its dependencies are analysed. If some of them can't be resolved (meaning the system has no such dependency installed or available for installation), the user is given immediate feedback and can fix it. Otherwise, it is put in a queue for a "super user" to administer. This super user looks through the PKGBUILD for any errors or dangerous behaviors, and if it looks fine, he presses "OK" and the PKGBUILD is sent to the cool part of the system: the build process. If the file was uploaded by a super user in the first place, the file goes straight to the build process. If the PKGBUILD is not OK, in the eyes of the super-user, it is denied and a reason is sent to the contributor.

The build process first analyses the PKGBUILD to check if it has all dependencies needed to build. If it doesn't, we know it can install additional packages to fix it, and so it does. Now it builds the package. One of two things can happen:
· The build fails for whatever reason. The log is sent to the guy who uploaded the PKGBUILD, and he can try again.
· It builds successfully.
In the latter case, the resulting package is added to a "testing" repository, where brave users can try them out. If a user finds that the package works fine, he logs into the website and votes for it as stable. If he found it unstable, he votes it as unstable. When stablevotes - unstablevotes == V (that is, V more people find it stable than those who find it unstable), and I imagine V could be set to 3, the package is marked as stable, and moved to a "stable" repository. If a package proves very popular over time, it is of course moved into the main "current" or "extras" repos.

Now, people take lots of exception to this proposal, so lets address the points I imagine can come up:
· What about updates and maintenance? Well, people can upload updated PKGBUILDs even if they're not the original contributor. This ensures updates packages as long as at least one user cares about it.
· Won't we have plenty of idiot users who upload half-hearted updates to complex packages (think Firefox) without understanding the finer points of the PKGBUILD? Yes, that is true. However, it is the responsibility of the super users to turn down such packages unless the contributor has a history of providing sane updates to that package (which the web system lets you check).
· What if the voting process results in a package marked as "stable" that isn't really stable? Think: how does the current TUR system protect against this? It doesn't at all. If it becomes a problem, we could increase V, at the cost of slower updates to "stable".
· What about different architectures? We may want to include x86_64 in the future. I'm not sure. It would certainly require more hardware resources at the system end.
· Who are the super users? The gang of super users starts out with trusted and skilled members of the ArchLinux community. As the system is used, you notice who the dedicated and smart users are, and promote them to super users.
· Sure sounds fine, let me know when you've coded it. Please -- something like this needs concerted effort and debate. When the time comes, I would only be thrilled to help out with the implementation.

sarah31 · 2004-11-10 16:14:57

the amount of automation and administration sound cumbersome. eric has been working on a replacement system for incoming for some time now i think it would be most prudent to wait for that before dreaming of a system such as this that would simply not work under the current structure here. it sounds like way too much work for people who don't get paid.

as well i could see countless modified versions of existing packages show up which i really don't like to see. it creates too much confusion and wastes space and time.

phrakture · 2004-11-10 18:59:36

i agree it sounds cumbersome and error prone - let's take this instance:
someone adds a gvim pkgbuild with --enable-pythoninterp added, another adds one with --enable-perlinterp, another with --enable-rubyinterp, and all the different permutations (total of 7). The "superuser" would probably get irritated seeing 7 gvim packages pop up every version update, and allow them all, or only one or something like that - which could cause end-user problems.
There are many cases where I can forsee a "superuser" getting lazy. Also, you now have the fact that people may start sending new package builds instead of flagging packages out of date...

it just seems messy to me.

Haakon · 2004-11-10 19:28:03

phrakture wrote:

i agree it sounds cumbersome and error prone - let's take this instance:
someone adds a gvim pkgbuild with --enable-pythoninterp added, another adds one with --enable-perlinterp, another with --enable-rubyinterp, and all the different permutations (total of 7). The "superuser" would probably get irritated seeing 7 gvim packages pop up every version update, and allow them all, or only one or something like that - which could cause end-user problems.

Yes, which configure options to use, and what libs to link against and what dependencies to demand could become an issue of conflict, and with no set package maintainer, you would need an additional arbitration process.

phrakture wrote:

Also, you now have the fact that people may start sending new package builds instead of flagging packages out of date...

But that's the number one advantage with the system! Many times, upgrading to a new version would only require reading through the Changelog to see if anything radical changed, and if not (that is, in most cases), just bump the version number and run makepkg. (Ok, a lot of maintainers would/will take exception to this and call me naive and worse, and for the most, they'd be right, so my accept my preemtive apologies So in that case, you would just help with the workload.

But I do agree upon reflection that the system would probably be prone to errors because of conflicting views of how a PKGBUILD should look, and because of the lack of direction that comes with no set maintainer. I like automation, because it could free up human resources if done right. If done wrong or to too strong a degree, it could backlash, however, and take up resources instead of freeing them.

I'm looking forward to the new system, and hope it can automate the right things, so we can get
· package updates in a timely fashion for
· a large number of packages that exist because it's so handy to contribute/maintain them
I was basically looking at the forum "New and Requested Packages" and thinking "what if all this posting of PKGBUILD files was done in an automated and streamlined system instead of in a dumb web forum?" [/list]

contrasutra · 2004-11-10 20:24:20

This is basically a screwy version of AUR (which we are going to be using) and pacbuild, which Xentac has been working on.

You're new, so I won't complain, but these things have been discussed to death (and none of this is original). We have all the ideas layed out, we just need the code finished. If you'd like to help, talk to Eric about coding.

And why wasn't this on the TUR list? Considering we're the ones who have to make the decision, you'd probably want us to know about it.

sarah31 · 2004-11-10 21:48:12

Haakon wrote:

I'm looking forward to the new system, and hope it can automate the right things, so we can get
· package updates in a timely fashion for
· a large number of packages that exist because it's so handy to contribute/maintain them
[/list]

excuse me but what is a timely fashion? would you rather a package be released for the sake of having it first or would you rather the maintainer do it right. you do have abs in case you are really impatiant. in most cases our packages are upgraded within minutes to days of official release. is that so bad?

more packages means more cruft imo. there are about 300 packages that i would deem important while the rest are just cruft. useful cruft but cruft all the same.

phrakture · 2004-11-10 22:27:07

cruft, eh?

I agree on the timely fashion remark though - there was somewhere were people were saying "packageX is version 1.2.3 not 1.2.4" and the proof was pointing to the arch package web interface which had version 1.2.4

Arch Linux

#1 2004-11-10 13:10:16

TUR on speed -- some thoughts

#2 2004-11-10 16:14:57

Re: TUR on speed -- some thoughts

#3 2004-11-10 18:59:36

Re: TUR on speed -- some thoughts

#4 2004-11-10 19:28:03

Re: TUR on speed -- some thoughts

#5 2004-11-10 20:24:20

Re: TUR on speed -- some thoughts

#6 2004-11-10 21:48:12

Re: TUR on speed -- some thoughts

#7 2004-11-10 22:27:07

Re: TUR on speed -- some thoughts

Board footer