[Mageia-dev] Mirror layout, round two

[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..

> 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.

> > 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.

> 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