[aur-general] Moving some popular games from AUR to community

[Thorsten Töpper]

On Sun, 15 Aug 2010 20:27:29 +0800
Ray Rashif <schivmeister at gmail.com> wrote:
> On 15 August 2010 17:49, Laurent Carlier <lordheavym at gmail.com> wrote:
> > Le dimanche 15 août 2010 09:38:06, Sven-Hendrik Haase a écrit :
> >>  On 15.08.2010 09:16, Angel Velásquez wrote:
> >> > Well, I am not against those games.. and stuff, but, if adding 6
> >> > games == ~3GB .. repos will have to syncronize and waste a lot
> >> > of bandwith with these games.
> >>
> >> The toll will be 1600MB at worst, so not that big of an issue. Even
> >> then, I kind of dislike the use of "waste" here. If these packages
> >> are useful or even fun, how can one be talking of a waste? Also,
> >> 1600MB in either disk space or bandwidth should be not a problem
> >> at all for our mirrors compared to the daily amount
> >> Ubuntu/Debian/Fedora packages, ISO spins and whatnot that they
> >> have to mirror. Debian alone takes 430GB for a full mirror. Arch
> >> is smaller than a tenth of that.
> >>
> >> > I'd say that since games are popular they should have their own
> >> > repo .. like [games] (please don't kill me), last time I said
> >> > that was because of nexuiz .. so people who like to have some
> >> > repos, can decide if download games or not... (I particurarly
> >> > won't do it for my personal purposes since I don't use to game,
> >> > not in pc, not in Linux, not now :P).
> >>
> >> If mirror size and bandwidth are not issues, how to justify a
> >> [games] repo? Also, [games] may only mark the beginning. Why not
> >> also [office], [multimedia] and [dev]? I really don't want to go
> >> there. Adding more repos will only make Arch less simple but what
> >> do we gain?
> >>
> >> > But if those packages are popular and maintainer can handle the
> >> > bandwidth and mirrors won't complain about it, im fine with it.
> >> >
> >> > Cheers
> >>
> >> Well, I said I'd be fine with the maintaining.
> >
> > Lot of packages could be splitted to get a common data part.
> 
> I'm with angvp on this. As long as we don't get any significant
> 'oh-crap' from this being done, I'll be more than happy to have
> allowed you to do this. So, go ahead.
> 
> Btw, third-party repos should never be a factor here. Arch-Games is
> independent (and it works).
> 
> And also, try to refrain from comparing to other distros. It's none of
> our business.
> 
> Caveat: I like UrbanTerror.
 
I fully agree with Angel and Ray, you can't argument with the behaviour
of other distributions, also you can't argument with the mirror size, I
might be wrong but as far as I know there are several mirrors out there
sponsored by private people who only can sponsor them because our repos
are so small and only take up half of their servers space. I haven't
checked the current global situation but I remember one german user who
did so.

So I suggest that we might should think about a special mathematical
rule for package bundles that are larger a certain size(200 / 300MB?)
in order to vaguely determine if it's useful to have them in
[community] or not. An initial idea would be to take an estimated
amount of users and divide this through the sum of the size of the
packages and the vote for them, if the result is smaller y then it's
okay. A sample with urbanterror:

number_of_users = 5000
package_votes = 380
package_size = 730 (fictional sized urbanterror splitted + both arches)

5000 / (380+730) = ~4.5

So if we say "Hey we want the result around [logical-]or beneath 10."
this would be fine.

Now the same for openarena:

number_of_users = 5000
package_votes = 64
package_size = 315 (also fictional, non splitted x86_64 has 307MB)

5000/(64+315) = ~13.2

So we see this package won't fit yet, with some more votes it sure
would (I assume it won't grow in size that much that fast). So if it
get's another load of 64 votes and thus has 128 votes it's ~11.2 and
therefore it's not bad to think about a move for one of us.


However don't forget that except for the number of votes both
calculations were based on more(number of users) and less(packages size)
fictional numbers and this formula is not tested with more than those
two samples.
-- 
Jabber: atsutane at freethoughts.de Blog: http://atsutane.freethoughts.de/
Key: 295AFBF4     FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 222 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/aur-general/attachments/20100815/c2eb71fe/attachment.bin>