The community repository should still exist as there several packages that i use daily or weekly in fact such as amsn, dar, openobex, obexfs, compiz.
Please don't remove the repository as i would like to see my daily applications being updated and easily downloaded. There are also some other useful package in community repository that i would like to try and not easily available from the previous distro I use. It is just 3 months that I have use Arch linux and I have yet to exploit the full power and unlimited possibilities of Arch linux. :-( On Tue, Nov 11, 2008 at 9:39 AM, <[EMAIL PROTECTED]> wrote: > Send aur-general mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://archlinux.org/mailman/listinfo/aur-general > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of aur-general digest..." > > > Today's Topics: > > 1. Re: Packages in Community and votes. (Aaron Griffin) > 2. Re: pkgstats and community - attempt 2 (Ond?ej Ku?era) > 3. Re: pkgstats and community - attempt 2 (Brandon Martin) > 4. Re: pkgstats and community - attempt 2 (Ronald van Haren) > 5. Re: Packages in Community and votes. (Aaron Schaefer) > 6. Re: Packages in Community and votes. (Loui Chang) > 7. Re: Packages in Community and votes. (Aaron Schaefer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 10 Nov 2008 17:05:40 -0600 > From: "Aaron Griffin" <[EMAIL PROTECTED]> > Subject: Re: [aur-general] Packages in Community and votes. > To: "Discussion about the Arch User Repository (AUR)" > <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=UTF-8 > > On Mon, Nov 10, 2008 at 4:32 PM, Daenyth Blank <[EMAIL PROTECTED]> wrote: >> 1) The server is being strained (what parts exactly?) by the community repo. > > It's primarily disk space and IO load issues. > > The community repo and AUR are fairly large. A cron job which WAS > keeping the AUR's permissions in check was actually pegging our system > with so much load that we had to remove any handling of the AUR files > (hope the code is good enough for that). > > The AUR backend daemon opens every single package file (wtf?) when it > runs, which is a HUGE resource hog. In an ideal world, someone would > rewrite this to work the same way the offical repos work - with > repo-add and a separate decoupled script to load the mysql database > from a pacman DB. > > Sizes on disk: > community: 11G > extra: 11G > core: 330M > unsupported: 800M > > > ------------------------------ > > Message: 2 > Date: Tue, 11 Nov 2008 00:17:20 +0100 > From: Ond?ej Ku?era <[EMAIL PROTECTED]> > Subject: Re: [aur-general] pkgstats and community - attempt 2 > To: "Discussion about the Arch User Repository (AUR)" > <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-2; format=flowed > > Hi, > > Allan McRae wrote: >> So lets start there. What should the [community] repo be doing? What >> is its purpose? There is no point discussing anything else until that >> is well defined. >> All responses must start with "The [community] repo is ..." > > The [community] repo is - in my non-dev, non-TU very humble opinion - a > repository for packages that are perhaps not as widely used as those in > [core] or those in [extra] but still used by enough users, so that it's > reasonable to provide them in binary form, providing that there is a way > to do so. I always figured that there is only so many devs and only so > many packages a single dev can maintain, which leads to a limited number > of packages in [core]/[extra]. That's why there are TUs and that's why > there is [community] - so that the number of packages provided in binary > form (by people that hopefully can be trusted) is larger. > > But what I actually wanted most to say was "amen" to your e-mail, Allan, > I think you've summarized feelings of many people... > > Ond?ej > > > -- > Cheers, > Ond?ej Ku?era > > > ------------------------------ > > Message: 3 > Date: Mon, 10 Nov 2008 17:23:43 -0600 > From: Brandon Martin <[EMAIL PROTECTED]> > Subject: Re: [aur-general] pkgstats and community - attempt 2 > To: "Discussion about the Arch User Repository (AUR)" > <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="UTF-8" > > On Tue, 11 Nov 2008 00:17:20 +0100, Ond?ej Ku?era > <[EMAIL PROTECTED]> wrote: >> Hi, >> >> Allan McRae wrote: >>> So lets start there. What should the [community] repo be doing? What >>> is its purpose? There is no point discussing anything else until that >>> is well defined. >>> All responses must start with "The [community] repo is ..." >> >> The [community] repo is - in my non-dev, non-TU very humble opinion - a >> repository for packages that are perhaps not as widely used as those in >> [core] or those in [extra] but still used by enough users, so that it's >> reasonable to provide them in binary form, providing that there is a way >> to do so. I always figured that there is only so many devs and only so >> many packages a single dev can maintain, which leads to a limited number >> of packages in [core]/[extra]. That's why there are TUs and that's why >> there is [community] - so that the number of packages provided in binary >> form (by people that hopefully can be trusted) is larger. >> >> But what I actually wanted most to say was "amen" to your e-mail, Allan, >> I think you've summarized feelings of many people... > > The [community] repo is - > > Very well put this is what I thougth the community repo was for also. > > -- > Brandon Martin > > > > ------------------------------ > > Message: 4 > Date: Tue, 11 Nov 2008 01:17:09 +0100 > From: "Ronald van Haren" <[EMAIL PROTECTED]> > Subject: Re: [aur-general] pkgstats and community - attempt 2 > To: "Discussion about the Arch User Repository (AUR)" > <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-2 > > 2008/11/11 Ond?ej Ku?era <[EMAIL PROTECTED]>: >> Hi, >> >> Allan McRae wrote: >>> >>> So lets start there. What should the [community] repo be doing? What is >>> its purpose? There is no point discussing anything else until that is well >>> defined. >>> All responses must start with "The [community] repo is ..." >> >> The [community] repo is - in my non-dev, non-TU very humble opinion - a >> repository for packages that are perhaps not as widely used as those in >> [core] or those in [extra] but still used by enough users, so that it's >> reasonable to provide them in binary form, providing that there is a way to >> do so. I always figured that there is only so many devs and only so many >> packages a single dev can maintain, which leads to a limited number of >> packages in [core]/[extra]. That's why there are TUs and that's why there is >> [community] - so that the number of packages provided in binary form (by >> people that hopefully can be trusted) is larger. >> >> But what I actually wanted most to say was "amen" to your e-mail, Allan, I >> think you've summarized feelings of many people... >> >> Ond?ej >> >> >> -- >> Cheers, >> Ond?ej Ku?era >> > > IMO all that but without your last argument. Quite some TUs are also > Devs at this very moment, so for the workload for them it doesn't > matter. Still most of the packages they maintain should stay in > community. Packages in community should be there because they are used > by quite some people, but not enough to have them in extra, or > packages that are a hype and have to prove that they are there to stay > before they are put into extra (bmpx in extra comes to mind which > development has stopped after like little over 1 year (?),just an > example to make clear what I mean). Alpha software (for example e17) > should also never be included in extra IMO (though some packages may > not follow this rule if needed). > > Hope it is clear enough, it's already late :p > > Ronald > > ------------------------------ > > Message: 5 > Date: Mon, 10 Nov 2008 19:22:01 -0500 > From: "Aaron Schaefer" <[EMAIL PROTECTED]> > Subject: Re: [aur-general] Packages in Community and votes. > To: "Discussion about the Arch User Repository (AUR)" > <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=UTF-8 > >> It's primarily disk space and IO load issues. > > I have questions, mostly meant to get people thinking about > alternatives and ramifications of any solutions... > > If the real issue is disk space and IO, what about the possibility of > a hardware upgrade? What about moving the largest packages to > unsupported (or something like arch-games) instead of basing it on > votes? It looks like eliminating just the top 10 largest community > packages would save 1.8 GB of space! See > http://rafb.net/p/Xfw0gh39.html for package sizes. What about putting > community on it's own server? What about fixing the AUR backend? What > about adding a CVS commit hook in the mean time to fix permissions on > upload instead of running a single cron job? > > If we make these proposed changes, how will they actually impact the > server and it's current problems? How will they effect Arch users? > What is the price of convenience that the community repo provides to > Arch users? Will there be a way to easily differentiate packages in > unsupported that are actually maintained by TUs? How can we reliably > tell what is popular? Download numbers, voting, pkgstats, etc. all > have their own issues and biases...is there a better way? What makes > the most sense in the long run when there are sure to be more TUs and > packages in community eventually? Should we worry about things that > are currently in community, or just new packages? > > My main point is that there are many options, and any solution that > gets acted upon needs to be based on hard evidence for improvement and > account for all consequences of that change rather than just basing it > on what sounds good. There has been a lot of rabble-rousing and not > much investigation into the underlying problems and proposed > solutions. > > -- > Aaron "ElasticDog" Schaefer > > > ------------------------------ > > Message: 6 > Date: Mon, 10 Nov 2008 20:00:10 -0500 > From: Loui Chang <[EMAIL PROTECTED]> > Subject: Re: [aur-general] Packages in Community and votes. > To: "Discussion about the Arch User Repository (AUR)" > <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > On Mon, Nov 10, 2008 at 07:22:01PM -0500, Aaron Schaefer wrote: >> > It's primarily disk space and IO load issues. >> >> I have questions, mostly meant to get people thinking about >> alternatives and ramifications of any solutions... >> >> If the real issue is disk space and IO, what about the possibility of >> a hardware upgrade? What about moving the largest packages to >> unsupported (or something like arch-games) instead of basing it on >> votes? It looks like eliminating just the top 10 largest community >> packages would save 1.8 GB of space! See >> http://rafb.net/p/Xfw0gh39.html for package sizes. What about putting >> community on it's own server? What about fixing the AUR backend? What >> about adding a CVS commit hook in the mean time to fix permissions on >> upload instead of running a single cron job? >> >> If we make these proposed changes, how will they actually impact the >> server and it's current problems? How will they effect Arch users? >> What is the price of convenience that the community repo provides to >> Arch users? Will there be a way to easily differentiate packages in >> unsupported that are actually maintained by TUs? How can we reliably >> tell what is popular? Download numbers, voting, pkgstats, etc. all >> have their own issues and biases...is there a better way? What makes >> the most sense in the long run when there are sure to be more TUs and >> packages in community eventually? Should we worry about things that >> are currently in community, or just new packages? >> >> My main point is that there are many options, and any solution that >> gets acted upon needs to be based on hard evidence for improvement and >> account for all consequences of that change rather than just basing it >> on what sounds good. There has been a lot of rabble-rousing and not >> much investigation into the underlying problems and proposed >> solutions. > > I've said this already in discussions but I'll say this again. > Fixing the community back end, removing large packages, and removing > unused packages are all possible solutions to the problem. > > If we implement all the solutions, then we get an incremental > improvment. Each solution will build upon the others. We shouldn't only > implement one measure. We should implement ALL measures within reason. > > I only raised the issue of unused or barely used packages in Community > and pruning the repo. We should really be focusing on that before > diverting the discussion and delving into other areas. > > http://wiki.archlinux.org/index.php/Community > > > > ------------------------------ > > Message: 7 > Date: Mon, 10 Nov 2008 20:39:25 -0500 > From: "Aaron Schaefer" <[EMAIL PROTECTED]> > Subject: Re: [aur-general] Packages in Community and votes. > To: "Discussion about the Arch User Repository (AUR)" > <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=UTF-8 > > On Mon, Nov 10, 2008 at 8:00 PM, Loui Chang <[EMAIL PROTECTED]> wrote: >> I only raised the issue of unused or barely used packages in Community >> and pruning the repo. We should really be focusing on that before >> diverting the discussion and delving into other areas. > > I know we've discussed this in IRC, but again my question is _why_ > should this be the focus? Does it give us the most improvement for the > least effort? Does it inconvenience users the least? Is it the > cheapest? By how much? Is it the fastest? Why? Why? Why? > > I'm open-minded about suggestions, but need something more substantial > to back them up than just saying "we should do this". Where are the > numbers to support the claim? Also, it seems as though the issue of > popularity/voting and the community repo might be altogether different > than the issue of server resources. Are we linking the two together > because of a twist of fate with timing and pkgstats coming to > fruition? > > > Aaron "ElasticDog" Schaefer > > p.s. my link for package sizes will disappear in a day, here's a > better one: http://omploader.org/vd3Vx > -- > > > ------------------------------ > > _______________________________________________ > aur-general mailing list > [email protected] > http://archlinux.org/mailman/listinfo/aur-general > > > End of aur-general Digest, Vol 49, Issue 17 > ******************************************* >
