Re: [Mageia-dev] Release cycle - what is actually POSSIBLE?
2010/11/26 andre999 and...@laposte.net: MIhail Papadopoulos a écrit : Why not going down the right path: A rolling release cycle would be simply great. After all, this isn't a commercial distribution, so it shouldn't be a total noob Ubuntu-style mishmash. Why ? What do you mean by rolling ? How would it improve things for the user ? How would it improve things for the developers/packages/translators who provide Mageia ? What are the costs ? What are the benefits ? And how does that compare with the alternatives ? This has already been discussed in length in one of the lists, very early, IIRC ist was early October . There were even polls in communities about. -- wobo
Re: [Mageia-dev] Release cycle - what is actually POSSIBLE?
Le 2010-11-26 03:14, Wolfgang Bornath a écrit : 2010/11/26 andre999and...@laposte.net: MIhail Papadopoulos a écrit : Why not going down the right path: A rolling release cycle would be simply great. After all, this isn't a commercial distribution, so it shouldn't be a total noob Ubuntu-style mishmash. Why ? What do you mean by rolling ? How would it improve things for the user ? How would it improve things for the developers/packages/translators who provide Mageia ? What are the costs ? What are the benefits ? And how does that compare with the alternatives ? This has already been discussed in length in one of the lists, very early, IIRC ist was early October . There were even polls in communities about. Yes it was. I think it will re-surface again due to Ubuntu's recent advertising of going to a rolling distro scheme. We may have to go through another round of these comments. Do we have an archive list of the user mailist where we can refer people to continue on that particular thread? Are the mailists archived? Marc Marketing Team Member
Re: [Mageia-dev] Release cycle - what is actually POSSIBLE?
Marc Paré m...@marcpare.com schrieb am 2010-11-26 Do we have an archive list of the user mailist where we can refer people to continue on that particular thread? Are the mailists archived? https://www.mageia.org/pipermail/mageia-dev/20101009/001055.html -- http://www.mageia.org - Mageia, the magic continues Oliver Burger Mageia webteam
Re: [Mageia-dev] Release cycle - what is actually POSSIBLE?
Le 2010-11-26 05:35, Oliver Burger a écrit : Marc Parém...@marcpare.com schrieb am 2010-11-26 Do we have an archive list of the user mailist where we can refer people to continue on that particular thread? Are the mailists archived? https://www.mageia.org/pipermail/mageia-dev/20101009/001055.html Merci Olivier Marc
[Mageia-dev] Mirror layout, round two
Hi, As we are getting closer to actually have something to mirror it's time to get this decided. And the deadline for theese discussions is December 5th, 2010 in order to get a decision on the board meeting on December 6th, 2010. Now this is a somewhat problematic topic but needs to be decided. This has already been discussed in two threads: First off we have the basic) part: Mirror tree structure by Olivier Thauvin https://www.mageia.org/pipermail/mageia-dev/20101020/001286.html And the other part (that gives some problems): Mageia repository sections, licenses, restrictions, firmware etc by Anssi Hannula. https://www.mageia.org/pipermail/mageia-dev/20101012/001084.html Now, in order to get somewhere, here is a suggestion that tries to find a middle ground or base for discussions... Now this toplevel part seems to be ok by everyone: -- Mageia/ /distrib/ /cauldron/ /stable1/ /iso/ /cauldron/ /i586/ /srpms/ /x86_64/ /stable1/ /people/ /software/ -- Then we come to the problematic part: -- /x86_64/ /media/ /codecs/ (disabled by default) /core/ (old main+contrib) /backports/ (disabled by default) /backports_testing/ (disabled by default) /release/ /testing/ (disabled by default) /updates/ /extra/ (unmaintained, disabled by default) /firmware/ (disabled by default) /games/ (disabled by default) /non-free/ (disabled by default) /debug_*/ (disabled by default) - The idea of this layout with some of the separate sections (codecs, firmware, games, non-free, debug_*) gives a mirror maintainer in a country (or company) the option to exclude the parts they legally (or by company policy) can not mirror. The core should be only maintained free/libre stuff so it's easy to build a free/libre iso extra is for those packages that no-one really maintain, but is still used by someone games are now a separate repo since it can grow fast with a lot of game data. So, Comments / Thoughts... -- Thomas
Re: [Mageia-dev] Mirror layout, round two
Renaud MICHEL skrev 26.11.2010 23:43: On vendredi 26 novembre 2010 at 21:29, Thomas Backlund wrote : Then we come to the problematic part: -- x86_64 media codecs (disabled by default) core (old main+contrib) backports (disabled by default) backports_testing (disabled by default) release testing (disabled by default) updates extra (unmaintained, disabled by default) firmware (disabled by default) games (disabled by default) non-free (disabled by default) /debug_*/ (disabled by default) - The idea of this layout with some of the separate sections (codecs, firmware, games, non-free, debug_*) gives a mirror maintainer in a country (or company) the option to exclude the parts they legally (or by company policy) can not mirror. The core should be only maintained free/libre stuff so it's easy to build a free/libre iso extra is for those packages that no-one really maintain, but is still used by someone games are now a separate repo since it can grow fast with a lot of game data. I think it is a good layout, but, are updates/backports(testing) limited to core? nope, the same layout: backports (disabled by default) backports_testing (disabled by default) release testing (disabled by default) updates should be under codecs, extra, firmware, games, non-free, debug_* in order to provide consistency betwen medias. I just left them out because they was supposed to be the same for all. As you mentioned, extra has no reason to have updates or backports, because if someone did bother to make updates, then the package doesn't belong in extra. Yeah, but for a stable release, we dont move packages... the /release/ must stay frozen. For games it would surely be appreciated to have new versions, so maybe a only a games/updates media which could also be used as a backport media (as games are not critical). To simplify for all users, the medias should be used in the same way. For non-free we would probably want also updates and backports, like in current mandriva. yep. Now for firmware and codecs I don't know, are there updates for firmwares? Not often, but sometimes there are firmwares that get bugfixes, so the same rule apply. Maybe they should be in sync with kernel updates (or external modules)? They must of course stay compatible with the kernel. As for codecs, will it contain anything that could be covered by patents, like PLF for mandriva? Does that mean we will still have a stripped down mplayer/xine in core and a full version in codecs? This is one of the tricky ones... But if it is only disabled and you only need to activate it in the control center to have full featured multimedia programs, it is no big deal, and if it makes life easier for people whose countries have restrictive law then we should go for it. That was the idea. We should probably have a clear rule to decide what cannot go in core and should in non-free (that on is pretty clear already) codecs or firmware. yep. I hope we will soon get to the point where we will actually put packages in those repositories :-) we are getting closer... -- Thomas
Re: [Mageia-dev] Mirror layout, round two
Op vrijdag 26 november 2010 22:43:31 schreef Renaud MICHEL: On vendredi 26 novembre 2010 at 21:29, Thomas Backlund wrote : Then we come to the problematic part: -- x86_64 media codecs (disabled by default) core (old main+contrib) backports (disabled by default) backports_testing (disabled by default) release testing (disabled by default) updates extra (unmaintained, disabled by default) firmware (disabled by default) games (disabled by default) non-free (disabled by default) /debug_*/ (disabled by default) - The idea of this layout with some of the separate sections (codecs, firmware, games, non-free, debug_*) gives a mirror maintainer in a country (or company) the option to exclude the parts they legally (or by company policy) can not mirror. The core should be only maintained free/libre stuff so it's easy to build a free/libre iso extra is for those packages that no-one really maintain, but is still used by someone games are now a separate repo since it can grow fast with a lot of game data. I think it is a good layout, but, are updates/backports(testing) limited to core? As you mentioned, extra has no reason to have updates or backports, because if someone did bother to make updates, then the package doesn't belong in extra. For games it would surely be appreciated to have new versions, so maybe a only a games/updates media which could also be used as a backport media (as games are not critical). For non-free we would probably want also updates and backports, like in current mandriva. Now for firmware and codecs I don't know, are there updates for firmwares? Maybe they should be in sync with kernel updates (or external modules)? As for codecs, will it contain anything that could be covered by patents, like PLF for mandriva? Does that mean we will still have a stripped down mplayer/xine in core and a full version in codecs? But if it is only disabled and you only need to activate it in the control center to have full featured multimedia programs, it is no big deal, and if it makes life easier for people whose countries have restrictive law then we should go for it. We should probably have a clear rule to decide what cannot go in core and should in non-free (that on is pretty clear already) codecs or firmware. I hope we will soon get to the point where we will actually put packages in those repositories :-) A) i see no reason for codecs and firmware to be separate. However, i do understand that some people would not want to install firmware, but i think we should do this in another way, (like installing a meta package that enforces some limits.) codecs seem odd to be separate, if they have patented problems they should go in non_free, if no problem, they can go in core. B) if they are separate, they would need updates, backports, testing, ... (i expect non_free does too?) C) if they are separate, they cannot be disabled by default, some stuff is needed for stuff to work. D) i have questions about noarch packages, will they be installed on both trees? and if we have more archs later on, more and more? this seems a waste; except if we could hardlink them somehow. if not, we should just put them somewhere separate. E) i understand games to be separate, but disabled by default?, i'm not sure i agree with that. (we need to remember our target audience; stuff needs to work out-of the box) F) what is backports_testing? why can't that just be testing?
Re: [Mageia-dev] Mirror layout, round two
Op zaterdag 27 november 2010 00:25:17 schreef Thomas Backlund: [...] A) i see no reason for codecs and firmware to be separate. However, i do understand that some people would not want to install firmware, but i think we should do this in another way, (like installing a meta package that enforces some limits.) codecs seem odd to be separate, if they have patented problems they should go in non_free, if no problem, they can go in core. That is doable. The reason for having it separate was because its the most problematic one. (codecs have more issues than firmware) What i meant here, is why is firmware separate from core? why is codecs separate from core? imo, i would put firmware and codecs in either core or non_free. B) if they are separate, they would need updates, backports, testing, ... (i expect non_free does too?) Yep. as noted in the other post, the layout under /core/ is duplicated under all other medias... yeah, I only read your other post after writing this. C) if they are separate, they cannot be disabled by default, some stuff is needed for stuff to work. So installer could ask in order to fully support your hw you need ..., do you want to enable firmware repo... and explain the reason for free/libre... that sounds like a good idea, however; do we have the time to change this in the installer? D) i have questions about noarch packages, will they be installed on both trees? and if we have more archs later on, more and more? this seems a waste; except if we could hardlink them somehow. if not, we should just put them somewhere separate. We hardlink them already. But yeah, I'd like a separate noarch too, but some people disagree, so I didnt add it to this proposal. well, especially when we get more archs, we really should separate noarchs; i'm kind of feeling strong about this. E) i understand games to be separate, but disabled by default?, i'm not sure i agree with that. (we need to remember our target audience; stuff needs to work out-of the box) I was thinking of a feature in the installer, if you select games, it would enable the repo by default, otherwise keep it disabled. same as with C) . do we have the time for this? F) what is backports_testing? why can't that just be testing? Versioning problem... on mirrors / BS we have testing - updates route, so this would be backports_testing - backports, Because if you have this: core/release v 1.2.0-1 core/testing v 1.3.0-1 (intended for backports) then you cant upload a bugfix v 1.2.0-1.1 to core/testing as there is already a bigger version in testing... aah, makes sense. PS: i like the extra btw: (which should contain all unmaintained packages that actually build)
Re: [Mageia-dev] Mirror layout, round two
On Sat, Nov 27, 2010 at 00:44, Maarten Vanraes maarten.vanr...@gmail.com wrote: Op zaterdag 27 november 2010 00:25:17 schreef Thomas Backlund: [...] A) i see no reason for codecs and firmware to be separate. However, i do understand that some people would not want to install firmware, but i think we should do this in another way, (like installing a meta package that enforces some limits.) codecs seem odd to be separate, if they have patented problems they should go in non_free, if no problem, they can go in core. That is doable. The reason for having it separate was because its the most problematic one. (codecs have more issues than firmware) What i meant here, is why is firmware separate from core? why is codecs separate from core? imo, i would put firmware and codecs in either core or non_free. I guess we should separate concerns? - non_free as in not (really) free software (source code may be available, but license, redistribution conditions, etc.) - problematic stuff as in binary closed thing (most firmware, but not only eventually) - problematic stuff as in (likely) patented (some codecs) so that we don't mix issues when one has to decide what to mirror/use or not. Romain
Re: [Mageia-dev] Mirror layout, round two
Op zaterdag 27 november 2010 00:51:59 schreef Romain d'Alverny: On Sat, Nov 27, 2010 at 00:44, Maarten Vanraes maarten.vanr...@gmail.com wrote: Op zaterdag 27 november 2010 00:25:17 schreef Thomas Backlund: [...] A) i see no reason for codecs and firmware to be separate. However, i do understand that some people would not want to install firmware, but i think we should do this in another way, (like installing a meta package that enforces some limits.) codecs seem odd to be separate, if they have patented problems they should go in non_free, if no problem, they can go in core. That is doable. The reason for having it separate was because its the most problematic one. (codecs have more issues than firmware) What i meant here, is why is firmware separate from core? why is codecs separate from core? imo, i would put firmware and codecs in either core or non_free. I guess we should separate concerns? - non_free as in not (really) free software (source code may be available, but license, redistribution conditions, etc.) - problematic stuff as in binary closed thing (most firmware, but not only eventually) - problematic stuff as in (likely) patented (some codecs) so that we don't mix issues when one has to decide what to mirror/use or not. you know what? how about having a possibly_patented and disable it by default; but have them all in there. because there are countries where most of those are allowed. (i suspect they aren't necessarily codecs) how about having a binary_only repository? (i suspect they aren't all firmwares?) or they could just be in non_free; because that's what they are...
Re: [Mageia-dev] Mirror layout, round two
On Fri, Nov 26, 2010 at 11:29 PM, Thomas Backlund t...@iki.fi wrote: The idea of this layout with some of the separate sections (codecs, firmware, games, non-free, debug_*) gives a mirror maintainer in a country (or company) the option to exclude the parts they legally (or by company policy) can not mirror. I wonder how urpmi.addmedia --distrib ftp://server/with/omitted/sections; should be interpreted then. Also mirror list should be indicating which sections are present; is it supported right now?
Re: [Mageia-dev] Mirror layout, round two
2010/11/27 Andrey Borzenkov arvidj...@gmail.com: On Fri, Nov 26, 2010 at 11:29 PM, Thomas Backlund t...@iki.fi wrote: The idea of this layout with some of the separate sections (codecs, firmware, games, non-free, debug_*) gives a mirror maintainer in a country (or company) the option to exclude the parts they legally (or by company policy) can not mirror. I wonder how urpmi.addmedia --distrib ftp://server/with/omitted/sections; should be interpreted then. Also mirror list should be indicating which sections are present; is it supported right now? And that will make the $MIRRORLIST approach problematic. Say I am living in a country which has no patent restrictions but no mirror either. Then the addmedia function will search a mirror in my neighborhood and selects the next mirror which may be such a mirror where the maintainer excluded the parts with patented software. Say I am a new user who does not know about the option to manually select a mirror and who does not know that such mirrors with missing branches do exist. I must come to the conclusion that Mageia does not distribute any patented software at all. This can only be avoided on user level by asking the user first if he wants patented software or not (including a text which explains the problem). Then if he wants to have patented software he could be connected to a mirror with the patented software flag, if not he will be connected with a mirror which does not have the patented software flag. The other option may be that we do not allow mirrors without the patented branch in the official mirrorlist. This would probably mean no official mirrors in those countries with patent problems but people there can still use other off shore mirrors. -- wobo
Re: [Mageia-dev] Mirror layout, round two
On 27 November 2010 08:27, Andrey Borzenkov arvidj...@gmail.com wrote: On Fri, Nov 26, 2010 at 11:29 PM, Thomas Backlund t...@iki.fi wrote: The idea of this layout with some of the separate sections (codecs, firmware, games, non-free, debug_*) gives a mirror maintainer in a country (or company) the option to exclude the parts they legally (or by company policy) can not mirror. I wonder how urpmi.addmedia --distrib ftp://server/with/omitted/sections; should be interpreted then. Also mirror list should be indicating which sections are present; is it supported right now? IMHO, the mirrorlist in its current status should be dropped altogether... it's only good if the user has good mirrors near where he lives, otherwise it just fails miserably. The whole point of using a mirrorlist was that urpmi will switch to another mirror if the currently used one fails / can't be reached, that switch doesn't happen, (md5sum mismatch rings a bell?). At least with the specific media mirrors the user can, more easily, guess that he can use add another mirror, with mirrorlist most new users are left clueless. -- Ahmad Samir
