diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101129/001479.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101129/001479.html | 355 |
1 files changed, 355 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101129/001479.html b/zarb-ml/mageia-dev/20101129/001479.html new file mode 100644 index 000000000..6fa7e0db8 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001479.html @@ -0,0 +1,355 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129002441.GB2419%40sisay.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + + <LINK REL="Next" HREF="001484.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Michael scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129002441.GB2419%40sisay.ephaone.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">misc at zarb.org + </A><BR> + <I>Mon Nov 29 01:24:42 CET 2010</I> + <P><UL> + + <LI>Next message: <A HREF="001484.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1479">[ date ]</a> + <a href="thread.html#1479">[ thread ]</a> + <a href="subject.html#1479">[ subject ]</a> + <a href="author.html#1479">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Sat, Nov 27, 2010 at 08:00:17PM +0200, Thomas Backlund wrote: +><i> Michael scherer skrev 27.11.2010 10:43: +</I>><i> >On Fri, Nov 26, 2010 at 10:29:14PM +0200, Thomas Backlund wrote: +</I>><i> [...] +</I>><i> > > +</I>><i> > > Then we come to the "problematic" part: +</I>><i> > +</I>><i> >This part look really too complex to me. +</I>><i> > +</I>><i> > > ------ +</I>><i> > > /x86_64/ +</I>><i> > > /media/ +</I>><i> > > /codecs/ (disabled by default) +</I>><i> > +</I>><i> > so, ogg, webm, being codec, should go there or not ? +</I>><i> > What about patents problem about something else than codec ? +</I>><i> > ( freetype, image such as gif, DRM stuff ) +</I>><i> > +</I>><i> +</I>><i> Actually this is the "maybe_legal_greyzone" repo, +</I>><i> but since flagging it as "codecs" would really make people +</I>><i> react, I named it so for now... +</I> +Sorry to be so direct, but that's doesn't answer the question :/ + +><i> > > /core/ (old main+contrib) +</I>><i> > > /backports/ (disabled by default) +</I>><i> > > /backports_testing/ (disabled by default) +</I>><i> > > /release/ +</I>><i> > > /testing/ (disabled by default) +</I> +Shall I suggest to name this one "updates_testing", for consistency ? +( consistency with backport_testing, and because this explain what goes in +more clearly. This also look simpler ). + +><i> > > /updates/ +</I>><i> > > /extra/ (unmaintained, disabled by default) +</I>><i> > +</I>><i> > If used by people, then why no one step to maintain anything ? +</I>><i> +</I>><i> Yeah, thats the problem. +</I> +If this is the problem, how does it help to have people to maintain +the application ? + +So far, the only way that really work is +"someone take care or we shoot the do^W rpm". +So maybe we could just be more active with cleaning ? + +><i> And reality shows we have a lot of packages assigned to nomaintainer@ ... +</I>><i> +</I>><i> > > /firmware/ (disabled by default) +</I>><i> > +</I>><i> > Why separate firmware from non_free ? What does it bring ? +</I>><i> > Since both of them are disabled by default, they can be simply merged. +</I>><i> > +</I>><i> +</I>><i> Well, this suggestion is partly based on the fact that we have users +</I>><i> that want a firmware free install, wich this would satisfy... +</I> +I do not think this warrant a full media, maybe just a way to filter package. + +Using a media seems overkill to me, since this bring complexity in dialog box, from +easyurpmi to rpmdrake and installer, and since it bring complexity on mirror, on BS +and on our policy. + +Maybe we could find a way to tag them "firmware", like a rpmgroup. + +The benefit is the complexity will only be on rpmdrake side, not on mirroring and BS +side. + +More ever, this would much more flexible ( ie, see the games option I propose later ). + +><i> But yes, if we ignore those suggestions, we split the firmwares in +</I>><i> GPL -> /core/ and the rest to /non-free/ +</I>><i> +</I>><i> > > /games/ (disabled by default) +</I>><i> > +</I>><i> > That's a simplification that make no sense. +</I>><i> > Not all games are big, not all big packages are games ( tetex, openoffice ). +</I>><i> +</I>><i> It's not only a size question, its also a nice option for companies +</I>><i> to not mirror games ("employees should work, not play...") +</I> +Such companies likely already have admins to prevent users from installing games. +Maybe we could add feature in rpmdrake for that ( like "do not show package +that match such conditions : group =~ games/, maintainer =~ nomaintainer@, requires =~ python ). + +The problem of private internal companies mirrors is really not our concern. +And their software policy, even if they may decide to apply it on a public mirror, +should not leak on our side. + +><i> And we have some contributors that already have stated that they +</I>><i> plan to add all possible games so it will grow. +</I>><i> and we all know games are the fastest growing /space demanding... +</I> +Well, so either that will cause a problem on our side, in which case this will +just be unhelpful on our primary mirrors, or it will only cause issues on some mirrors, +and in this case, there is lots of other thing that can take space that we do not +take in account : +- debug +- source code ( except that a GPL requirement ) +- adding another arch ( like arm/mips ) +- adding more iso ( something that is asked each time, like 64 bits one, etc ) + +So if we decide "mirrors will not handle the load, so we need to split games", then we +should also say "mirrors will not handle the load, so we need to do less iso/offer to not +mirror debug/offer to not mirror some architecture", and we end with a non consistent +network of mirror, with lots of complexity on our side to handle the possible choice +made by mirrors. I am not sure that users +will truly benefit from this. And I am sure that we will not benefit from the complexity. + +If the space is a issue ( and I think that's one of the main one ), then we should decide +based on metrics. Ie, we plan to have no more than X% growth in mirror size for 1 year. +If we hit some soft limit, then we investigate and decide ( ie, stop adding big backport, +stop adding new package, etc ). + +And decide the metrics based on mirrors input, and based on packagers input. +But so far, apart from Olivier and Wolfgang, we do not have much metrics and +requirements :/ + +><i> > > /non-free/ (disabled by default) +</I>><i> > > /debug_*/ (disabled by default) +</I>><i> > +</I>><i> > +</I>><i> > And what are the relation of requirements ? +</I>><i> > Ie, what can requires non_free, codecs, games, etc ? +</I>><i> > +</I>><i> +</I>><i> IMHO /core/ should be selfcontained. +</I>><i> We are promoting open source after all. +</I> +Yes, but what about the others ? +Ie, can a game requires a codec or not ? a package in extra ? +If we remove a package from extra, do we remove everything +that requires it ? + +><i> > And what about something that can goes in both media, ie a non_free +</I>><i> > game goes where ? A unmaintained codecs goes where ? +</I>><i> +</I>><i> Yeah, to be precise, that would need a games_non-free +</I> +another media ? Really, I think most users are already lost with the +current media selection. +For core, we have 15/20 medias ( src + debug + binary ( 1 or 2 ) * update/release/testing/backport/ +backport testing ). Each media we add at the level of core will therefore add 15 to 20 medias too. +So firmware, game, extras, codecs, non_free, that would make the total around 80 to 90 medias for a single +arch ( I assume that firmware may not have debug_* ) + +While it can be partially solved with a better interface for selecting media, +we cannot do miracles if there is too much things :/ + +So let's try to think how we can reduce the number of media. + +We have 2 kind of issue we try to solve at mirror level : +- the concern of mirror admins +- the concern of users. +with impact on BS and packagers + +Mirror admins are concerned by : +- size and growth ( see Wobo mail in the past thread ) +- content ( or at least, we think ) + +Content part is mainly legal matter, but I didn't heard any admin +telling "we can't do that", so that's my interpretation. The concern is +mainly around DCMA and EUCD, even if lesser know laws also exist around +the world ( like the Paragraph 202C of German law, who ban "hacking tools" ). +For DMCA, there is some protection for them : +<A HREF="http://www.benedict.com/Digital/Internet/DMCA/DMCA-SafeHarbor.aspx">http://www.benedict.com/Digital/Internet/DMCA/DMCA-SafeHarbor.aspx</A> . +For EUCD and the rest, I do not know. + + +Users are concerned with a wide range of issues, some contradictory : +- some want newer stuff, some don't +- some want stable stuff, some do not care as much +- some want non_free, some don't want it +- some want firmware, some don't +- etc + +Yet, the users concern mainly evolve around 2 things : +- package availiability +- package filtering, based on packages content + +The first part is already solved by the subdivision ( release, etc ). We +need to split them for build reason. So we can't really avoid adding +medias on this part. + +The second part is more tricky. And in fact, I think we can avoid creating media +for this. Ie, do not let the concern of filtering appearing on +the BS and mirrors, and push this on endusers system. +Some people do not want firmware on their system, they do not really care about +the firmware being in a separate directory on mirrors, as long as they can +disable them easily from the list of package they can install ( at +perl-urpm level, IMHO ). + +Same goes for non_free, or for nomaintained software. Or even games. + +So if we push the users issues on endusers system, we only have to manage the +mirror admins issue on mirror. + +And so here is a proposal that start by the size issue : + +- discuss with mirror admin, decide on a size that everybody would agree to mirror +for core/ for the next release, or the 2 next one. Ie, every year or every 6 months, +we do a survey of our mirrors, to see if everything goes well for them. +- discuss also of the growth of core in term of size +- decide on a limit size +- if anything goes off limit for mirror, add a overflow/ to hold the packages +that will not be mirrored by everybody. Overflow will be treated like core, in all points. +Only difference is that mirroring is optional ( but strongly encouraged ) +- put everything in core, except what goes to overflow. +- let users filter on their system, with something urpmi side ( I suggest a filtering +when we do urpmi.update, but the exact details of how to do it are not relevent now ). + +Overflow will be filled with packages that : +1) are not required by anything else ( thus games data would likely fit, +but not only ) +2) have triggered the limit of size + +After the limit of core size is raised ( ie after all mirror have agreed ),we can readd packages +from overflow to core, based on +criteria not defined yet ( first come first serve, try to make most useful first ? +or some wild guesstimate based on some mirrors stats ? ). But being in core or +overflow should not change anything for both enduser and packagers. This is +a mirror only concern, and so should be kept there only. +And this should avoid discussion about the location of packages by packagers. + +This mean that both core and overflow should be by default on users system. +( and I would not be against a better name, but I didn't found one ) + + + +In order to reduce number of media, another question is : +- should non_free have it own media ? + +Having them in core would simplify the BS, the upload and the mirroring. + +Having it separated would be better from various points of view ( political, +communication, etc ). Maybe some people will refuse to help us if we don't, +maybe there is some further restriction on some non-free software leading us +to create another media whatever we do, I do not know. +To me, as long as we can filter on user side, it would be ok. + +I cannot really tell what I prefer for that :/ + + +So the only important mirror issue left to solve is the greyzone area. +And well, that's quite complex. + +So we can either : + +1) decide to not care ( ie everything in core ) +2) decide to not offer them at all ( aka offload to PLF ) +3) decide to add a media ( aka the "codecs" media ) + +1 is the simplest. But maybe not really a good idea. + +If we care, then what indeed should be done is another media, and let admins +choose to mirrors it or not. I would even propose to revise the idea of +separation every year, because if all mirrors have the +2 medias, no need to split in reality ( but I doubt it will happen, but +at least, this would show that we try to revise our fondation on a regular +basis ). And at least, we should revise the packages present in such medias. +If there is some packages that can be moved to core, +then they should. + +We could also simplify a bit the BS by placing non-free packages there +( instead of either having a non_free media, or the non_free pacakges in core ). +It would sadden me a little to blur the line between "free with patents problems" +from "non free", but my PLF experience showed that most people do not care, and that +it requires more than a media separation. + +So, in the end, we would have : + +core/ + release + updates + updates_testing + backports + backports_testing + +"overflow"/ <- big packages, just for mirroring issues +restricted/ <- with non_free, firmware, "codecs" + +with the 5 directories under them, and with src, debug, binary. +Imho, 3 upper medias is the simplest we can have ( besides debug/src, that +I would place also on the same level than the binaries, but my +mail is already long enough :/ ) + +><i> For codecs either a extra_codecs or simply drop after a grace period. +</I>><i> but I guess codecs are important to people, so hopefully they wont +</I>><i> get orphaned... +</I> +Unfortunately, there is not always a relation between "being important +to users" and "someone want to take the burden of maintaining it" :/ +For example, something like etherpad would be nice for users, +yet no one will take time to maintain it. + +-- +Michael Scherer +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + + <LI>Next message: <A HREF="001484.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1479">[ date ]</a> + <a href="thread.html#1479">[ thread ]</a> + <a href="subject.html#1479">[ subject ]</a> + <a href="author.html#1479">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |