Re: [Mageia-dev] Mirror layout, round two
I think this whole question is not done with an easy answer. It can also not be ssen in a black/white mode. I see the clear insight of Michael's suggestion which is a black/white point of view. Not maintained? Kick it out (well, not out but into the ante-room). But I also see the reality from the user's POV. As for technical skilled or experienced users (including server admins) the main question is that those packages which are available should work and be maintained. Period. But there is also the vast group of the unwashed masses including those we want to attract to Mageia. Many of those do look at the sheer number of packages (like, I'd rather switch to Foo Linux which offers 2 million packages while Mageia only offers 5,000). Yes, I know, it's rather dumb and those users are the first to complain about some missing icon. But they are a large part of the users out there. So we have to find a middle way between the pure and the ugly. How to find that, I don't know, this is far beyond my knowledge. I only wanted to comment on the philosophical side of the problem. For me as a mostly non-technical guy the best solution would be the flag solution. Forget the main/contrib split and just flag unmaintained rpms so that the user sees it in the GUI. How to accomplish that on the CLI with urpmi I don't know. Then people who are security- aware like server admins can easily avoid unmaintained packages or open a request in Bugzilla which **may** inspire somebody to pick up the poor unmaintained package. One comment on the mirror maintainer part of the story: I was mentioned by Michael several times as an example of a certain kind of mirror maintainers. Yes, ressources are tight but not that tight. As I understood the official mirror as suggested by Olivier was about to fill up to 700 GB during the next 3 years - given that we will have 2 releases per year. Most of the official mirrors of Mandriva do not provide 6 releases, moreso when the life cycle of a release is less than 2 years. So, a realistic size woul be more like 450-500 GB at the most which is easily done with today's hardware. This is not a problem. Time is not a problem either for such people like me. The only problem I still see from the mirror maintainer's side is the way to deal with tainted packages wrt the mirrorlist (as already mentioned). -- wobo
Re: [Mageia-dev] Mirror layout, round two
On 30 November 2010 07:29, andre999 and...@laposte.net wrote: Michael Scherer a écrit : Le lundi 29 novembre 2010 à 20:54 -0500, andre999 a écrit : Yann Ciret a écrit : I dislike the main/contrib separation in some case. The first example is with Mozilla Thunderbird packages. Some extension packages are in contrib. So each time thunderbird received security update, the update cannot be installed because of non automatically rebuild of his contrib package. And each time I see a bug report of user asking a manual rebuilt. With only one core media, this situation will disapear (I hope). Unlikely. This problem is not at all related to separate repositories. It is. It is exactly related to the fact that thunderbird is supported, and that extension are not despites depending on it. In this case it is evident that you don't understand how extensions work with mozilla products. Thunderbird will function correctly with no extensions installed. So why should any extension block the update of Thunderbird ? So the user can simply uninstall that extension and update to new thunderbird? the user can do this only if he doesn't need that extension, only if it doesn't offer features he wants to use. That's an invalid argument, if he doesn't need that extension why does he have it on his system?? The rationale is/was that mozilla code breaks/broke ABI, so it was agreed that extensions are rebuilt for both firefox and thunderbird respective new versions. We will look into that with upstream, so that if a rebuild isn't needed, then all the better for us (packagers). But until that happens, they will be rebuilt. A 1-2 day delay isn't too much for users. The more pressing issue is, what does this have to do with the topic at hand Mirrors layout, round two ?? this discussion is deviating too much, to the extent it's becoming bloated... Additionally, modules installed will continue to work as long as the major version doesn't change. (Actually slightly more complicated.) In some cases one won't be able to newly install a module because a config file inside the module - equivalent to the spec file in rpm packages - hasn't been updated for compatible versions. (In fact, the versions were probably improperly specified.) But installed modules will continue to function. It is possible that the packager did not realise this - or for whatever reason did not properly set up a spec file - but this issue has nothing at all to do with separate sets of repositories. Speaking abstractly without examples in this case is just that, speaking. Give us an example of such a case (if any) in a spec file so that it can be fixed. That precisely because we tell security and bugfixes occurs only on main that contribs got broken, since the security team do not care to not break contribs packages. The crux of this problem is that core (in the general sense) packages are dependant on packages that are not recognized as core. That again has nothing to do with repositories as such. I agree with Michael here, doing sec fixes isn't hard (once one gets used to it), just time consuming, and it should be done for all packages in the official repos; it's true that GPL gives no guarantees what so ever, just it's a moral obligation for people involved in the FOSS world to support users as best they can. Users do not differentiate between main/contrib, there's a package they install it, I don't think they look from which repo it comes from. Rather that one package was updated, and an optional installed module was not. The fact that the module is optional is the key point. The installer should be flexible enough to give a warning in this case, and ask if you wish to continue the installation. So basically, you want a --nodeps ? If there is a requires, there is usually a good reason. Engineering is not randomly adding line to a file until it work. How about better configured spec files ? A better definition (in general) of core packages ? A focus on ensuring that core packages are maintained ? Basically my idea behind a core sandbox. But if you have a better idea ... Again, give us an example of a spec file that needs better configuration, otherwise you're theorising. Just remember, eliminating a supported core breaks the sandbox. So removing repositories does have secondary effects. And they should be seriously considered and discussed by those proposing to remove the repositories. As well, in the case of Thunderbird, it is almost certain that the installed module was in fact compatible with newer version of Thunderbird. (A security problem may directly impact Thunderbird or the module, but highly unlikely both packages.) Rpm tags should have been set so that Thunderbird would recognize that the module was appropriate in the newer version. No. If there is stricter dependency, it is precisely because there is no guarantee of any kind of ABI between thunderbird
Re: [Mageia-dev] Mirror layout, round two
So, after reading all different opinions here and discussing with founders, here is the idea: We start of with 3 medias: core, nonfree, tainted and 3 debug medias: debug_core, debug_nonfree, debug_tainted. In order to avoid confusion, we wont use the name restricted as it was used in MDV commercial products. Now all of theese medias will have their 5 submedias: release, updates, updates_testing, backports, backports_testing. That brings us to 30 medias in total :) The details of the media layout suggestion is also at the end of this mail, and at: http://mageia.org/wiki/doku.php?id=mirrors_policy Now... We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Then we to go on with and start importing X, the different DE's and every other package needed to build a full distro. By doing it this way, we get a clean start, every package rebuilt, and no old/unmaintained stuff in the beginning. Then as more maintainers join, I guess more packages will be imported from cooker and other sources. And packages can always be requested. As for those that want the core/extra split: We already tried it with main/contrib split. And I know mdv is now trying to refine what belongs in main or not, but thats for mdv to work through the problem as it wont be an easy task. For us I think the best way for now is to start with this suggested layout, and see if it works well for us. Remember, as Michael pointed out, this is a community supported distro, and only time will tell how well the community actually will support their distro. Point is, if we later decide this is not working well, we can always review the decisions and if decided do the split. Can we reach an agreement that this is the way to start the distro? and for refernece: The suggested layout for is: * core - enabled by default - mirrors must mirror this media to be listed as a mirror - only free/libre stuff as described by FSF / OSI - must be selfcontained * nonfree - disabled by default, installer will ask to enable it if it detects hw that need driver/fw from here - mirrors must mirror this media to be listed as a mirror - contains apps/drivers/firmware that are free to redistribute but we dont have redistributable source for - for example: ati/nvidia drivers/firmware, Oracle Java, Adobe stuff we might get redistribution permission for * tainted - disabled by default - mirrors are free to not mirror this media ( ? ) - stuff we think we can redistribute, but that may have some patent issues or other legal restrictions - what belongs / is allowed here must still be discussed * debug_core - disabled by default - debug rpms for core * debug_nonfree - disabled by default - debug rpms for nonfree * debug_tainted - disabled by default - debug rpms for tainted Every media contains the same layout: * backports - disabled by default * backports_testing - disabled by default * release - disabled by default on nonfree, installer will ask to enable it if it detects hw that need driver/fw from here - disabled by default on tainted, debug_core, debug_nonfree, debug_tainted * updates - disabled by default on nonfree, installer will ask to enable it if it detects hw that need driver/fw from here - disabled by default on tainted, debug_core, debug_nonfree, debug_tainted * updates_testing - disabled by default -- Thomas
Re: [Mageia-dev] Mirror layout, round two
On 10/11/30 12:37 +0200, Thomas Backlund wrote: We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Then we to go on with and start importing X, the different DE's and every other package needed to build a full distro. By doing it this way, we get a clean start, every package rebuilt, and no old/unmaintained stuff in the beginning. Then as more maintainers join, I guess more packages will be imported from cooker and other sources. And packages can always be requested. sounds sensible to me. questions: - how will the import be done? - is it up for the maintainer to request it? or only for non-base system packages? - or does the maintainer has a magic command to do? - will submitting a package for rebuild bork the list of maintainer (mdv uses the maintainer = 1st to submit scheme) - do we have an estimated planning with the different steps? jérôme -- jque...@gmail.com
Re: [Mageia-dev] Mirror layout, round two
Le mardi 30 novembre 2010 07:37:42, Thomas Backlund a écrit : So, after reading all different opinions here and discussing with founders, here is the idea: We start of with 3 medias: core, nonfree, tainted and 3 debug medias: debug_core, debug_nonfree, debug_tainted. In order to avoid confusion, we wont use the name restricted as it was used in MDV commercial products. [...] We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Are you (not specifically you thomas :p) going to check again the basesystem dependencies/requirements, if i remember correctly the basesystem in mandriva is not anymore a « real » basesystem ? Then we to go on with and start importing X, the different DE's and every other package needed to build a full distro. Should not each package imported directly by the maintener here (for the DE), so he's going to import (hopefully ?) only the real requirements so we'll be able to drop « more » unused packages maybe? [...] Can we reach an agreement that this is the way to start the distro? Sure (even if i'm not followed for the 2 points before :p ) Regards, -- Balcaen John IRC: mikala on freenode.org XMPP: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Mirror layout, round two
On Tue, 30 Nov 2010, Thomas Backlund wrote: So, after reading all different opinions here and discussing with founders, here is the idea: We start of with 3 medias: core, nonfree, tainted and 3 debug medias: debug_core, debug_nonfree, debug_tainted. In order to avoid confusion, we wont use the name restricted as it was used in MDV commercial products. Now all of theese medias will have their 5 submedias: release, updates, updates_testing, backports, backports_testing. That brings us to 30 medias in total :) The details of the media layout suggestion is also at the end of this mail, and at: http://mageia.org/wiki/doku.php?id=mirrors_policy [...] Can we reach an agreement that this is the way to start the distro? I agree with this proposal.
Re: [Mageia-dev] Mirror layout, round two
Le mardi 30 novembre 2010 11:37:42, Thomas Backlund a écrit : So, after reading all different opinions here and discussing with founders, here is the idea: We start of with 3 medias: core, nonfree, tainted and 3 debug medias: debug_core, debug_nonfree, debug_tainted. In order to avoid confusion, we wont use the name restricted as it was used in MDV commercial products. Now all of theese medias will have their 5 submedias: release, updates, updates_testing, backports, backports_testing. That brings us to 30 medias in total :) The details of the media layout suggestion is also at the end of this mail, and at: http://mageia.org/wiki/doku.php?id=mirrors_policy Now... We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Then we to go on with and start importing X, the different DE's and every other package needed to build a full distro. By doing it this way, we get a clean start, every package rebuilt, and no old/unmaintained stuff in the beginning. Then as more maintainers join, I guess more packages will be imported from cooker and other sources. And packages can always be requested. As for those that want the core/extra split: We already tried it with main/contrib split. And I know mdv is now trying to refine what belongs in main or not, but thats for mdv to work through the problem as it wont be an easy task. For us I think the best way for now is to start with this suggested layout, and see if it works well for us. Remember, as Michael pointed out, this is a community supported distro, and only time will tell how well the community actually will support their distro. Point is, if we later decide this is not working well, we can always review the decisions and if decided do the split. Can we reach an agreement that this is the way to start the distro? OK for me provided support policy matters are not discarded forever but only delayed to allow things to start. It would be great to start QA Team's organization as soon as possible. I don't think we need to wait for the BS and the packages to begin thinking about those matters. Regards Samuel
Re: [Mageia-dev] Mirror layout, round two
2010/11/30 Thomas Backlund t...@iki.fi: So, after reading all different opinions here and discussing with founders, here is the idea: For us I think the best way for now is to start with this suggested layout, and see if it works well for us. Remember, as Michael pointed out, this is a community supported distro, and only time will tell how well the community actually will support their distro. Point is, if we later decide this is not working well, we can always review the decisions and if decided do the split. Can we reach an agreement that this is the way to start the distro? Looks ok for me and the easiest layout we may achieve. Still we will need to finalize policies about repositories content. -- Anne http://www.mageia.org
Re: [Mageia-dev] Mirror layout, round two
In Mandriva, you can find many examples of packages in main which are not supported in reality, or even maybe simply don't work. You can find also many packages in contrib which are perfectly supported, in cooker as in stable releases. You gave me examples. However I see very rarely security or bugfix updates for packages in contrib for stable releases (or sometimes they go to backports), whereas there are many security fixes and bugfixes for packages in main thanks to Mandriva's security team. There really is a difference between supported packages and other, although it's far from perfect. The difference is mainly that Mandriva has a team of 2 people full time doing the bugfixes and security updates. We do not have them. So that's not because there is contribs that main got more bugfixes and updates. That's because people are paid to do the work. And so there is no correlation between there is updates in main and there is a split. Yes there is a correlation : there is a team of people working to provide quick support for a set of packages. Without a list of supported packages, they couldn't focus their work. However please remember that I agreed that the split mirror-side is not the only way to achieve such focus. Our main disagreement here is you prefer that we have the same level of support for any package in the distribution (which probably means very few packages in the distribution then) while I'd like many packages in the distribution, a subset of which is officially supported. At least, it worked well enough so that we could send more than 450 servers with Mandriva in French hospitals and use Mandriva at work on workstation. Why do I prefer a large package list to a list restricted to platinum-supported packages : I can build a system where the critical parts are supported, and if I need to add some less supported stuff, I still can. We should compare the ratio between packages in main and packages in contrib which are actually installed on people's systems. On our servers, that would be around 98% coming from main, and less than 2% coming from contrib. On my workstation, it would be probably 75% vs 25%. Main provides stability and security (regardless of some badly supported packages). Contrib provides choice.. Seeing that everything is equally supported is a sign of a lack of quality ? It depends on the amount of available packages and available resources. 1 packages *equally supported* with 30 packages, yep, that would be a sign of a lack of quality. If there are only 1000 packages, of course, this is different. I still prefer the 1000 supported packages + 9000 use-at-your-own-risk packages. Now if there were a list of supported packages, either it would not be officially supported and the user would know he could use it but maybe won't have security and bugfix updates, or it is officially supported. Now take the example above : - Someone checks if postgresql is supported because if not he'll use another distribution where it is - It is ! - However the maintainer went away doing his own fork, so he dropped maintainership. - Someone in QA Team rings a bell : this supported package isn't supported anymore, but we promised we would support it for Mageia 2011 for 2 years from now ! We have to do something ! - The package team leader, or someone else, relays the warning and finds someone else to maintain the package, at least for Mageia 2011, for security and bugfix updates. Please, I would appreciate that you do not arrange facts just to support your point, or I will seriously have to reconsider answering in the futur. In the first case : package is not supported, no one step to maintain, we drop - that's bad. second case : package is not supported, someone step, we don't drop - that's good Why do you make the assumption that someone will step to maintain in 2nd case and not in the first one ? Just saying it should be supported because it is on some official list is not really something that worked that well at Mandriva for the community. The way you make a caricature of my arguments is rude here. What I'm saying is totally different : In the first case : - no one steps in to maintain it. We drop it. In the second case : - no one steps in to maintain it. Because we promised to support it, and because there are people who care about that (the QA Team Leader for example), we would *try very hard* to find a solution. this is a problem, we identify the problem, we try to solve it. Maybe we fail, but at least we try hard, because the package is on the supported list. In my example I supposed we find a solution, because I suppose that we find it. If I were that kind of person who cares, I'm sure I would find someone. Of course, if we flag too much packages as supported, then it may become actually impossible to support them all,
[Mageia-dev] Support policy
Hi, I would like to discuss the support policy for Mageia. It would be interesting to know (or decide) where Mageia is heading, given our limited resources : 1) focus on stability and security : few very well equally supported packages. Apparently, this is where we're going for now. May be wise as a start, but I hope this is not our final destination, because it means either very limited choice, or progressive diminution of quality of support if the number of packages increases faster than the dedicated resources. 2) focus on choice : many packages, but no support policy. This would be really bad, I think we're not heading there, from what I read. However, this is a danger if we start from option 1) and then open wide the gates for importing packages, without setting a support policy. 3) focus on both (this is my option). There would be 2 levels of support : - top guaranteed support : those are the (few at start) packages your can rely on almost blindly, they'll be updated in a timely manner, and updates don't break things. Those are the packages the QA Team puts its limited resources on (doesn't mean the QA Team provides the support themselves, this is maintainer work, but they check that good support is provided) : testing, helping the maintainers to watch for security problems... The maintainers are responsible for their package, but the QA Team double-checks updates for stable releases. - supported packages (every other package) : those are maintained packages, however the QA Team doesn't have to check them. It's up to the maintainer to check the package and updates quality. - unsupported packages are dropped. Are we heading for 1), 2), 3), or any other option ? Of course, with unlimited resources, options 1 and 3 would be equivalent, everything would have the top guaranteed support :) Best regards Samuel Verschelde Packager/QA Team/User
Re: [Mageia-dev] Mirror layout, round two
Jerome Quelin skrev 30.11.2010 12:48: On 10/11/30 12:37 +0200, Thomas Backlund wrote: We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Then we to go on with and start importing X, the different DE's and every other package needed to build a full distro. By doing it this way, we get a clean start, every package rebuilt, and no old/unmaintained stuff in the beginning. Then as more maintainers join, I guess more packages will be imported from cooker and other sources. And packages can always be requested. sounds sensible to me. questions: - how will the import be done? It will be done by reviewing every srpm, drop anything mdv owned/trademarked, and then committed to svn. This is to get a clean svn to start from. - is it up for the maintainer to request it? or only for non-base system packages? - or does the maintainer has a magic command to do? maintainers will be able to import stuff into svn themselves. More to follow soon regarding packagers / cleanup work. We will notify users when we open up the svn so people can start reviewing/cleaning packages and commit it to svn Then a new notification will be sent when we consider BS fully open. - will submitting a package for rebuild bork the list of maintainer (mdv uses the maintainer = 1st to submit scheme) I guess that will be so atleast for now. This will be refined for packaging teams/maintainer groups... - do we have an estimated planning with the different steps? Not yet, there are still some fixes needed to be done on youri to get it fully working. -- Thomas
Re: [Mageia-dev] Mirror layout, round two
Balcaen John skrev 30.11.2010 12:50: Le mardi 30 novembre 2010 07:37:42, Thomas Backlund a écrit : So, after reading all different opinions here and discussing with founders, here is the idea: We start of with 3 medias: core, nonfree, tainted and 3 debug medias: debug_core, debug_nonfree, debug_tainted. In order to avoid confusion, we wont use the name restricted as it was used in MDV commercial products. [...] We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Are you (not specifically you thomas :p) going to check again the basesystem dependencies/requirements, if i remember correctly the basesystem in mandriva is not anymore a « real » basesystem ? Well, technically it's basesystem-minimal that should be just that: minimal. but it will be reviewed as everythng else. Then we to go on with and start importing X, the different DE's and every other package needed to build a full distro. Should not each package imported directly by the maintener here (for the DE), so he's going to import (hopefully ?) only the real requirements so we'll be able to drop « more » unused packages maybe? [...] Can we reach an agreement that this is the way to start the distro? Sure (even if i'm not followed for the 2 points before :p ) -- Thomas
Re: [Mageia-dev] Mirror layout, round two
Samuel Verschelde skrev 30.11.2010 13:04: Le mardi 30 novembre 2010 11:37:42, Thomas Backlund a écrit : So, after reading all different opinions here and discussing with founders, here is the idea: We start of with 3 medias: core, nonfree, tainted and 3 debug medias: debug_core, debug_nonfree, debug_tainted. In order to avoid confusion, we wont use the name restricted as it was used in MDV commercial products. Now all of theese medias will have their 5 submedias: release, updates, updates_testing, backports, backports_testing. That brings us to 30 medias in total :) The details of the media layout suggestion is also at the end of this mail, and at: http://mageia.org/wiki/doku.php?id=mirrors_policy Now... We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Then we to go on with and start importing X, the different DE's and every other package needed to build a full distro. By doing it this way, we get a clean start, every package rebuilt, and no old/unmaintained stuff in the beginning. Then as more maintainers join, I guess more packages will be imported from cooker and other sources. And packages can always be requested. As for those that want the core/extra split: We already tried it with main/contrib split. And I know mdv is now trying to refine what belongs in main or not, but thats for mdv to work through the problem as it wont be an easy task. For us I think the best way for now is to start with this suggested layout, and see if it works well for us. Remember, as Michael pointed out, this is a community supported distro, and only time will tell how well the community actually will support their distro. Point is, if we later decide this is not working well, we can always review the decisions and if decided do the split. Can we reach an agreement that this is the way to start the distro? OK for me provided support policy matters are not discarded forever but only delayed to allow things to start. It wont be discarded. We need to list package priority, wich ones must go through QA, and wich ones that are subject to maintainer qa testing It would be great to start QA Team's organization as soon as possible. I don't think we need to wait for the BS and the packages to begin thinking about those matters. Yes, its time to start defining policies around all this and team creation. -- Thomas
Re: [Mageia-dev] Mirror layout, round two
Anne nicolas skrev 30.11.2010 13:15: 2010/11/30 Thomas Backlundt...@iki.fi: So, after reading all different opinions here and discussing with founders, here is the idea: For us I think the best way for now is to start with this suggested layout, and see if it works well for us. Remember, as Michael pointed out, this is a community supported distro, and only time will tell how well the community actually will support their distro. Point is, if we later decide this is not working well, we can always review the decisions and if decided do the split. Can we reach an agreement that this is the way to start the distro? Looks ok for me and the easiest layout we may achieve. Still we will need to finalize policies about repositories content. True. A post on that will follow later today/tomorrow. -- Thomas
Re: [Mageia-dev] Mirror layout, round two
Michael Scherer skrev 30.11.2010 14:23: Le mardi 30 novembre 2010 à 07:50 -0300, Balcaen John a écrit : Le mardi 30 novembre 2010 07:37:42, Thomas Backlund a écrit : So, after reading all different opinions here and discussing with founders, here is the idea: We start of with 3 medias: core, nonfree, tainted and 3 debug medias: debug_core, debug_nonfree, debug_tainted. In order to avoid confusion, we wont use the name restricted as it was used in MDV commercial products. [...] We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Are you (not specifically you thomas :p) going to check again the basesystem dependencies/requirements, if i remember correctly the basesystem in mandriva is not anymore a « real » basesystem ? The explicit goal is to be able to boot, and start bash. Not bash and be able to do anything useful with it :) ( ok, maybe a script with /dev/tcp to say hello on irc ). So if basesystem as a rpm is not enough, we will import what is needed to complete it. or basesystem-minimal :) -- Thomas
Re: [Mageia-dev] Mirror layout, round two
On Tue, Nov 30, 2010 at 13:29, Samuel Verschelde sto...@laposte.net wrote: What I'm saying is totally different : In the first case : - no one steps in to maintain it. We drop it. In the second case : - no one steps in to maintain it. Because we promised to support it, and because there are people who care about that (the QA Team Leader for example), we would *try very hard* to find a solution. this is a problem, we identify the problem, we try to solve it. Maybe we fail, but at least we try hard, because the package is on the supported list. Ok, it's a degree of support management: - first case, dropping is automatic, - second case, we turn the red light on and try to organise around this to find a best effort solution. But, in the second case, relying exclusively on the community, for the support promise to work, you have to show that you have either some separate incentive, either a large enough community to grow the chances for this to happen. another solution : we do no promises of supporting anything. This is a solution. Not mine however. Not promising of something to happen is not a promise of this thing not to happen. Such a promise of support is much more sustainable if you have a clear, identifiable incentive or reason or experience (for the people you promise to) to keep it. There are differences between: * guaranteed, * trying very hard, * best effort, * good will, * nothing pretended support promises. Let me present the idea differently. There are 2 levels of support : - top guaranteed support (a subset of packages) : those are packages your can rely on blindly, they'll be updated in a timely manner. Those are the packages the QA Team puts its limited resources on (doesn't mean the QA Team provides support, but they check that good support is provided). The maintainer is responsible for the package, but the QA Team is vigilant about them. - supported packages (every other package) : those are maintained packages, however the QA Team doesn't have to check them. It's up to the maintainer. - unsupported packages are dropped. So everything is supported, but there a special level of support for some critical components. Just saying, but as packages support is to be distributed, we may as well have commercial companies step around and manage this kind of support: * within/through Mageia through their employees (so, it matches our policies, that's the idea), * because it matches their activity/interest (they build the software, they consult/sell/build around it). To help thinking about that (in the future, because now we have nothing to track/compare) we need to collect and report relevant data about packages management experience (supported, not supported, number of updates, maintainers, time to push an update, etc.) against a first policy. So we can measure what happens and what can be reasonably changed/expected in the future. Romain
Re: [Mageia-dev] Mirror layout, round two
2010/11/30 Thomas Backlund t...@iki.fi * core - enabled by default - mirrors must mirror this media to be listed as a mirror - only free/libre stuff as described by FSF / OSI - must be selfcontained * nonfree - disabled by default, installer will ask to enable it if it detects hw that need driver/fw from here - mirrors must mirror this media to be listed as a mirror - contains apps/drivers/firmware that are free to redistribute but we dont have redistributable source for - for example: ati/nvidia drivers/firmware, Oracle Java, Adobe stuff we might get redistribution permission for * tainted - disabled by default - mirrors are free to not mirror this media ( ? ) - stuff we think we can redistribute, but that may have some patent issues or other legal restrictions - what belongs / is allowed here must still be discussed * debug_core - disabled by default - debug rpms for core * debug_nonfree - disabled by default - debug rpms for nonfree * debug_tainted - disabled by default - debug rpms for tainted Every media contains the same layout: * backports - disabled by default * backports_testing - disabled by default * release - disabled by default on nonfree, installer will ask to enable it if it detects hw that need driver/fw from here - disabled by default on tainted, debug_core, debug_nonfree, debug_tainted * updates - disabled by default on nonfree, installer will ask to enable it if it detects hw that need driver/fw from here - disabled by default on tainted, debug_core, debug_nonfree, debug_tainted * updates_testing - disabled by default The Scheme sounds good. One only suggestion from my side, i would enable the updates once the repositories are enabled. For Example if I enable the non-free Repos i would like also to get the Updates for them. or maybe only security fixes and enable the other updates manually would be ok. -- Mit freundlichen Grüßen Greetings Daniel Kreuter
Re: [Mageia-dev] Support policy
Le mardi 30 novembre 2010 16:13:25, Michael Scherer a écrit : Le mardi 30 novembre 2010 à 13:31 +0100, Samuel Verschelde a écrit : Hi, I would like to discuss the support policy for Mageia. It would be interesting to know (or decide) where Mageia is heading, given our limited resources : can you first explain what are our ressources so you can explain how limited you think they are ? Well, I can't because as you already told me we don't know what our resources will be. What I can guess is that they are limited because I know no free software project where there's too much resources. Samuel
Re: [Mageia-dev] Support policy
Le mardi 30 novembre 2010 à 16:36 +0100, Samuel Verschelde a écrit : Le mardi 30 novembre 2010 16:13:25, Michael Scherer a écrit : Le mardi 30 novembre 2010 à 13:31 +0100, Samuel Verschelde a écrit : Hi, I would like to discuss the support policy for Mageia. It would be interesting to know (or decide) where Mageia is heading, given our limited resources : can you first explain what are our ressources so you can explain how limited you think they are ? Well, I can't because as you already told me we don't know what our resources will be. What I can guess is that they are limited because I know no free software project where there's too much resources. Well, from a physical point of view, everything is limited, so saying limited ressources didn't indeed told much. I think that the ressources at Mandriva could be summarized as around 1 to 3 full time people ( maybe more, maybe less, and likely not full time on the stable free distro ). Which is not balanced at all when compared to the ressources that were placed in packaging. Ie, there was much more people to produce rpm than people to 1) take care of update ( secteam, 2 people ) 2) take care of testing update ( qateam, 1-3 people ) Being unbalanced lead to the main/contribs split with the complexity and problem that went with it. Of course, the goal is not to have less packagers, but rather more Qa people, the 2 being not exclusive. This then bring to the simple question is why did we have more packagers than QA ? My own opinion is that because packaging was opened to external contribution since almost the start ( since 10 years, packagers number have growth ), while QA was not, and I suppose that was due to a lack of time devoted on making QA more open ( ironically likely due to a lack of ressources at the first place ). And so, I think we are now in a totally different situation. QA will be more open, because it cannot be closed. We can ( and I think we should ) make the QA ressources grow with the packagers one ( among others ). So how can we do ? While this may not seems apparent at first sight, I think that Fedora is actually leading in term of community QA process ( we still had the lead in term of automated QA ). Basically, packages that are updated requires to be noted, with a system of karma ( http://fedoraproject.org/wiki/Bodhi_Guide#Karma ). Positive karma, the update is pushed, negative, it is not. Anybody can test anything, even if there is also a proven tester group. There is even the concept of critical path packages, aka very important package that must be deeply tested ( http://fedoraproject.org/wiki/Critical_Path_Packages ). Of course, the system is not perfect and will not solve everything. For example, last week, openldap update broke server functionality : ( http://lists.fedoraproject.org/pipermail/devel/2010-November/146097.html ) But still, having community enabled QA is a great way to have every grow properly. And in fact, that's exactly one of the feature of your project mageia-app-db. So we could indeed have a better QAteam by easing the work of community, using mageia-app-db. Ie, take regular user, and turn them in QA team member. And so, doing like this would enable to give us : - real involvement from some users - balanced community, not overwhelmed by technical maniac packagers ( like me ) - having a better Qa, for a better system So while nothing is done, while I am not a member of the QA team nor a leader, while I just speak to voice my opinion, and while this is just a proposal based on what other have done to solve the same issue than us, this show that we can have more ressources than what Mandriva had. Ie, we need to think with a fresh mind, and I am sure that people can creatively propose solutions on the problem : how can we have a more balanced QA and packagers team. -- Michael Scherer
Re: [Mageia-dev] Mirror layout, round two
Le 30/11/2010 11:37, Thomas Backlund a écrit : Can we reach an agreement that this is the way to start the distro? I agree with this proposal. Regards Yann
Re: [Mageia-dev] Mirror layout, round two
On mardi 30 novembre 2010 at 11:37, Thomas Backlund wrote : Can we reach an agreement that this is the way to start the distro? I agree. -- Renaud Michel
Re: [Mageia-dev] Mirror layout, round two
Op dinsdag 30 november 2010 13:29:28 schreef Samuel Verschelde: In Mandriva, you can find many examples of packages in main which are not supported in reality, or even maybe simply don't work. You can find also many packages in contrib which are perfectly supported, in cooker as in stable releases. You gave me examples. However I see very rarely security or bugfix updates for packages in contrib for stable releases (or sometimes they go to backports), whereas there are many security fixes and bugfixes for packages in main thanks to Mandriva's security team. There really is a difference between supported packages and other, although it's far from perfect. The difference is mainly that Mandriva has a team of 2 people full time doing the bugfixes and security updates. We do not have them. So that's not because there is contribs that main got more bugfixes and updates. That's because people are paid to do the work. And so there is no correlation between there is updates in main and there is a split. Yes there is a correlation : there is a team of people working to provide quick support for a set of packages. Without a list of supported packages, they couldn't focus their work. However please remember that I agreed that the split mirror-side is not the only way to achieve such focus. Our main disagreement here is you prefer that we have the same level of support for any package in the distribution (which probably means very few packages in the distribution then) while I'd like many packages in the distribution, a subset of which is officially supported. At least, it worked well enough so that we could send more than 450 servers with Mandriva in French hospitals and use Mandriva at work on workstation. Why do I prefer a large package list to a list restricted to platinum-supported packages : I can build a system where the critical parts are supported, and if I need to add some less supported stuff, I still can. We should compare the ratio between packages in main and packages in contrib which are actually installed on people's systems. On our servers, that would be around 98% coming from main, and less than 2% coming from contrib. On my workstation, it would be probably 75% vs 25%. Main provides stability and security (regardless of some badly supported packages). Contrib provides choice.. I do see a point here. Seeing that everything is equally supported is a sign of a lack of quality ? It depends on the amount of available packages and available resources. 1 packages *equally supported* with 30 packages, yep, that would be a sign of a lack of quality. If there are only 1000 packages, of course, this is different. I still prefer the 1000 supported packages + 9000 use-at-your-own-risk packages. It is true that it could be viewed as such by people. Now if there were a list of supported packages, either it would not be officially supported and the user would know he could use it but maybe won't have security and bugfix updates, or it is officially supported. Now take the example above : - Someone checks if postgresql is supported because if not he'll use another distribution where it is - It is ! - However the maintainer went away doing his own fork, so he dropped maintainership. - Someone in QA Team rings a bell : this supported package isn't supported anymore, but we promised we would support it for Mageia 2011 for 2 years from now ! We have to do something ! - The package team leader, or someone else, relays the warning and finds someone else to maintain the package, at least for Mageia 2011, for security and bugfix updates. Please, I would appreciate that you do not arrange facts just to support your point, or I will seriously have to reconsider answering in the futur. In the first case : package is not supported, no one step to maintain, we drop - that's bad. second case : package is not supported, someone step, we don't drop - that's good Why do you make the assumption that someone will step to maintain in 2nd case and not in the first one ? Just saying it should be supported because it is on some official list is not really something that worked that well at Mandriva for the community. The way you make a caricature of my arguments is rude here. What I'm saying is totally different : In the first case : - no one steps in to maintain it. We drop it. In the second case : - no one steps in to maintain it. Because we promised to support it, and because there are people who care about that (the QA Team Leader for example), we would *try very hard* to find a solution. this is a problem, we identify the problem, we try to solve it. Maybe we fail, but at least we try hard, because the package is on the supported list. In my example I supposed we find a solution, because I suppose that we find it. If I were that
Re: [Mageia-dev] Mirror layout, round two
On Tue, 30 Nov 2010 12:37:42 +0200, Thomas Backlund t...@iki.fi wrote: Can we reach an agreement that this is the way to start the distro? I also agree with this structure. -- Sam Bailey Cyprix Enterprises Web: cyprix.com.au Em: cyp...@cyprix.com.au Mb: 0425 796 308
Re: [Mageia-dev] Mirror layout, round two
Op dinsdag 30 november 2010 12:04:49 schreef Samuel Verschelde: Le mardi 30 novembre 2010 11:37:42, Thomas Backlund a écrit : So, after reading all different opinions here and discussing with founders, here is the idea: We start of with 3 medias: core, nonfree, tainted and 3 debug medias: debug_core, debug_nonfree, debug_tainted. In order to avoid confusion, we wont use the name restricted as it was used in MDV commercial products. Now all of theese medias will have their 5 submedias: release, updates, updates_testing, backports, backports_testing. That brings us to 30 medias in total :) The details of the media layout suggestion is also at the end of this mail, and at: http://mageia.org/wiki/doku.php?id=mirrors_policy Now... We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Then we to go on with and start importing X, the different DE's and every other package needed to build a full distro. By doing it this way, we get a clean start, every package rebuilt, and no old/unmaintained stuff in the beginning. Then as more maintainers join, I guess more packages will be imported from cooker and other sources. And packages can always be requested. As for those that want the core/extra split: We already tried it with main/contrib split. And I know mdv is now trying to refine what belongs in main or not, but thats for mdv to work through the problem as it wont be an easy task. For us I think the best way for now is to start with this suggested layout, and see if it works well for us. Remember, as Michael pointed out, this is a community supported distro, and only time will tell how well the community actually will support their distro. Point is, if we later decide this is not working well, we can always review the decisions and if decided do the split. Can we reach an agreement that this is the way to start the distro? OK for me provided support policy matters are not discarded forever but only delayed to allow things to start. It would be great to start QA Team's organization as soon as possible. I don't think we need to wait for the BS and the packages to begin thinking about those matters. Regards Samuel i agree
Re: [Mageia-dev] Support policy
Op dinsdag 30 november 2010 13:31:08 schreef Samuel Verschelde: Hi, I would like to discuss the support policy for Mageia. It would be interesting to know (or decide) where Mageia is heading, given our limited resources : 1) focus on stability and security : few very well equally supported packages. Apparently, this is where we're going for now. May be wise as a start, but I hope this is not our final destination, because it means either very limited choice, or progressive diminution of quality of support if the number of packages increases faster than the dedicated resources. 2) focus on choice : many packages, but no support policy. This would be really bad, I think we're not heading there, from what I read. However, this is a danger if we start from option 1) and then open wide the gates for importing packages, without setting a support policy. 3) focus on both (this is my option). There would be 2 levels of support : - top guaranteed support : those are the (few at start) packages your can rely on almost blindly, they'll be updated in a timely manner, and updates don't break things. Those are the packages the QA Team puts its limited resources on (doesn't mean the QA Team provides the support themselves, this is maintainer work, but they check that good support is provided) : testing, helping the maintainers to watch for security problems... The maintainers are responsible for their package, but the QA Team double-checks updates for stable releases. - supported packages (every other package) : those are maintained packages, however the QA Team doesn't have to check them. It's up to the maintainer to check the package and updates quality. - unsupported packages are dropped. Are we heading for 1), 2), 3), or any other option ? Of course, with unlimited resources, options 1 and 3 would be equivalent, everything would have the top guaranteed support :) Best regards Samuel Verschelde Packager/QA Team/User having read misc's lenghty and almost political proposal, i suggest a 4th option (even though i'm not part of QAteam either): 4) dynamically distributed focus: - level 1: BuildSystem-required packages (all packages used for buildnodes) - level 2: everything that is minimally required to boot and do stuff - level 3: popular server packages - level 4: release focus (everything that's defaultly installed by a release) - level 4b: stage images - level 5: the rest depending on resources and certain timings; focus should be spread according to desires at that time. eg: - i imagine that level 1 could be discussed between sysadm and qateam during BS-updates - i imagine that level 2 would be the primary focus - i imagine that level 4 could be more important during release times - i imagine that level 5 would probably not be focussed by QA unless unlimited resources - i imagine that level 3 would probably be good if resources would be growing, and possibly level 4 if there's enough resources. - i agree that testing should be open to anyone - i agree that karma could not be a bad idea, but suggest that QAteam give more karma (perhaps even on the karmic state of that person) - i also would suggest that at the time of alpha release, we should do a contest on testing and bugfinding; so that we could gather enough testers; and possibly even extra packagers or qateam people. WDYT?
