[Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

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.