On 4/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > This is a reply to the "Public mailing list for ArchLinux development" > since i > found out that i didn't have write access to it. > > On Tue, 24 Apr 2007 20:40:18 +0200, Aaron Griffin > <[EMAIL PROTECTED]> wrote: > > > On 4/24/07, Dan McGee <[EMAIL PROTECTED]> wrote: > >> First, let's get a few numbers out there. > >> Sizes of official repos: > >> current: 563 > >> extra: 2019 > >> community: 1196 > >> > >> Number of "maintainers": > >> Devs: 27 > >> TUs: 25 > >> > >> The second set of numbers is harder to pin down. For devs, I took the > >> number from the devs page; someone who has been here longer could > >> better state the breakdown between architectures or between active and > >> passive. For TU's, I grabbed it from the AUR front page, once again > >> not knowing how many are active. > >> > >> Given the above numbers, and this repeats what has been stated > >> elsewhere by Alexander, devs have roughly 95 packages each > >> ((563+2019)/27) to maintain if the load was distributed evently. > >> Because we know it is not, Alexander came up with a figure of 16 > >> active maintainers, giving each dev 156 packages. Thats a lot, and it > >> leaves very little room or time for devs to do anything besides > >> package maintenance. > >> > >> Compare this to the TUs workload. Each TU should have roughly 48 > >> packages to maintain, a much more reasonable number and either 1/2 or > >> 1/3 of what a dev is expected to do. This also gives them some time to > >> patrol the AUR and check packages that haven't made it into community. > >> > >> Two proposals to let sit in the pot: > >> 1. Downsize extra to a more reasonable size, and move some of the > >> maintenance to TU's by shifting packages to community. This would > >> likely require a few more TUs being "hired on". > >> 2. Redefine what it means to be a dev. Have a three-tiered system of > >> sorts, with increases in permissions to change things as you move up > >> the ladder. This would basically stick another group between Devs and > >> TUs that could help maintain the huge number of packages we have in > >> extra. This would likely require a few more TUs being hired and some > >> TUs shifted to higher levels of responsibility. > >> > >> Yes, radical ideas, but don't shoot me for them. Comments appreciated. > > > > Not really that radical, I think something similar has come up a few > > times. > > > > I like the multi-tiered approach. Perhaps this fits into what alex > > proposed: that is, TU -> "division member" -> "division lead". > > > > oh my god. this is turning into debian. > > Why can't we have more like a wikipedian system? I haven't sat this > system in stone in my head yet and i would like to present a more > complete thought, but what if everyone could edit the PKGBUILD's > presented in AUR? > > You _could_ say this would be insecure but I would differ it's not. For > every person wanting to wreak havoc there would be 100 people > jumping in fix the PKGBUILD or delete it & notify of the malicious user. > > It's the exact reason wikipedia works. > > You _could_ be really unlucky and be the first person on a malicious > PKGBUILD but that exact danger is inherent in the traditional AUR as > well. Also this IS a distro for advanced users and if we put a notice > somewhere sensible I don't see why we should not do it. > Especially considering the security track record of AUR. (no incidents?) > > That's one part of the equation. Ofcourse one could also improve on > this if one were to implement yes/no hands on security of packages, > x many times downloaded. "locking" of packages etc.. etc.. > > 2. I don't know if the infrastructure is sat in place for this, or easily > achievable(git?) but what if > users could also send updated changes to PKGBUILDS to some kind of > holding area before they get sent to testing/community/extra and > current? > > Then all a TU would have to do is look at the change(diff), optionally test > it and then decide if he want to push the change to the real repos. > > It would increase productivity tenfold, and it's the only real > option if arch grows as exponential as it does now. > > think about it: > * It saves time > * It helps load off the devs/TU's chores > * updates get propagated faster to users > * it will be more motivating for users to contribute as they can just > update the files needed and send them in with a note instead of > having to lookup the maintainer which might or might not be correct, find > the email... maybe they should send an email to ml? or forum or... > We have no real process for this. This will make it more transparent. > * It will be more motivating for devs too as they now don't have to > spend time on petty issues and can concentrate on the larger issues + > * Other devs can update packages if they want to, if one goes on vacation > or whatever as now they might not need so much deep-info as they will > get clues from users helping out. > * probably lots of other points too, but the main advantage is that it will > make the whole system more transparent = easier to contribute > = more motivating = more work gets done. > > And everybody is happier :) > > As you see the old saying "notify the maintainer and he will get to it" is > not very efficient. > > Because in my opinion, even as wonderful as arch is, we're not really using > the potential of people right now and you can see the powerless frustration > manifest itself when people post updated official packages to AUR and > similar. > > So should we increase hierarchy and burecracy/confusion and become the > new debian in a couple of years or should we become the simplest and best > friggin distro on the planet? ;)
I agree with this very much so, but not too many people do. My proposition was as follows: The AUR could be made to work similar to a wiki (though more formatted for PKGBUILDs and the like) with login required and the ability to ban people (for completeness). PKGBUILDs would be run through some aur specific pacbuild instance, which will basically just test if the package builds or not. The package is then exposed via the web interface, if built.... people can test the package, if it's ok, you click "works fine". After a few "approvals", it moves off to the community repo. This will probably never happen, and people are going to say my idea is foolish, but hey, a man can dream.... _______________________________________________ arch mailing list [email protected] http://archlinux.org/mailman/listinfo/arch
