[Mageia-dev] Mirror layout, round two

Tue Nov 30 23:11:25 CET 2010

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