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. > 10000 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 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, but that would be failure due to > the way we built the list of supported packages, not a problem in the > process. a distinction of supportyness would be interesting; however this is a non- profit organisation, so, unless we have a list of people who will jump in for essential package takeovers, not easily done. > > another solution : "we do no promises of supporting anything". > > This is a solution. Not mine however. > > > Once we have started and done the first release of a alpha version, and > > once we have a working team to package, then we can see what we can > > support. For the moment, any discussion based on ressources is just > > premature and likely not based on real data. > > Well, my proposal (have a list of supported packages) is not that related > to ressources. If we have very few resources, let's begin by supporting > just 10 packages, then grow the list progressively. > > > So splitting medias based on security support is just that, sending the > > wrong sign to packagers. A clear sign that not maintaining package is > > ok. But we should send this kind of sign if we really value quality and > > if we want to communicate clearly to our users. > > I already abandoned the media splitting idea in favor of a list of very > well supported packages list. > > 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. > > Regards > > Samuel I would like to stop this discussion and give a point of view from myself. in the optimal world, mirror layout is best to be made for the easyness of the mirror admins. I would propose we do it like misc says, except that we find another solution to make the supportyness distinction. I know this could affect the mirror layout, but in the optimal world, it shouldn't. I think since we are a non-profit organisation (and therefor idealists), that we should look at this positively and find another solution for the distinction, if it is required. but that's another discussion, imho. Personally, i like this distinction, i would like to limit the packages for my fathers computer to the most supported ones, for my own ease. maybe a well-tested tag or whatever? let's discuss this elsewhere. we don't have time to let every discussion drag into other discussions that are a little bit related. let's try to separate things as much as possible.