[Mageia-dev] Mirror layout, round two

[Samuel Verschelde]

Le lundi 29 novembre 2010 17:08:25, Michael Scherer a écrit :
> 
> Le lundi 29 novembre 2010 à 15:24 +0100, Samuel Verschelde a écrit :
> > Le lundi 29 novembre 2010 14:56:20, Michael Scherer a écrit :
> > > - complexity on the users system as they need to have twice the number
> > >   of media to cope with this. This also appear in the interface of
> > >   various tools, and it is imho uneeded. Most people will say that we
> > >   already have too much medias.
> > 
> > Indeed, however it helps showing that there's a set of packages which is supported, 
> > and another one which is only on behalf of the maintainer. In a community driven 
> > distribution, this distinction may remains valid : some packages are officially 
> > supported by the distribution, others may or may not be, depending on the maintainer 
> > (or lack of maintainer).
> 
> If there is a maintainer and he has a account, then it is a official
> one, and so the package is officially supported. That's all. There is no
> separation of "the organisation" and "the maintainers", we are not
> Mandriva. 
> 
> So either the package is supported, and we keep, or it is not, and then
> why should we keep it ?

Because it works, at least partially. Because it has users. It may have flaws, it may not have the latest security fixes, it may just be supported but only updated once a year... That's not a reason for dropping it. That's why distiction between officially supported and not officially supported is useful. There are working packages, seldom updated, which don't deserve to be dropped, but which can't be advertised as officially supported, and that's understandable. The world is not either black or white, there are many shades of grey, and that's particularly true for packages in a linux distribution.

According to what you said, it looks like there will be only 2 kinds of packages :
- in the distribution (which would be equal to "supported")
- not in the distribution

But we all know that there will be :
- supported, both in cauldron and stable releases (updates + backports)
- supported, both in cauldron and stable releases (updates, no backports)
- supported, in cauldron only : the maintainer only cares about cauldron and hasn't enough time to fix bugs in (to his mind) old stable releases
- the same, but some people do backports from time to time
- supported in stable releases, but dropped from the cauldron because the maintainer couldn't maintain it anymore
- has no maintainer, but works, although it may have bugs and security flaws. Has users.
- many other situations
- not in the distribution

What I'm asking for is that we put dedicated work into ensuring packages flagged as supported have security and bugfix updates in stable releases.


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.

If there's no difference in term of security updates between php and a random maintained game, then I won't be very confident in the distribution's quality. 

Let's say I want to install php on the stable Mageia 2011, will it be supported for security fixes and bugfixes ? For how long ? Are security fixes applied as soon as possible ? If the only answer is "is has a maintainer, so it should be supported like all the other packages", I'll probably avoid Mageia on a server. 

So this time it's not a rhetorical question : is Mageia willing to provide official support for a subset of the available packages ? 

Flagging some packages as officially supported is a matter of putting dedicated resources and processes to ensure - as much as possible - good quality for those package. Like I said before, having a maintainer in itself is not sufficient, we also need support policies and a list of officially supported packages.


I agreed that the mirror structure is not the best way to make this distinction. An external list is good enough for that and can even bring new possibilities, as Nicolas Vigier stated in another post.


> Why in the rpm db ?
> A external file would perfectly do the trick. The same goes for
> maintainers. The only thing needed is less talk and more code

Okay, okay, not in the rpm db, nor in the mirror structure :)

> No. That's because you think that mirror structure is the only way we
> have to act on urpmi config.

This is what you think I think, and that's wrong.

> > and the decision to merge core and extras must be taken together 
> > with decisions on QA and support processes, 
> 
> Well, everything should be supported or dropped, that's all. Easy, done
> by every other distros out there except those that place a artificial
> separation. If there is a security bug opened and no one act on it after
> a time, let's drop the package. If there is a severe bug and no one act,
> the same, let's drop it.
> 
> If people want to resurrect a rpm, they can, there is a svn for that.

This is the most terrible thing I read so far. I already tried to answer it earlier in this message, however here's a last example :
- Someone checks if postgresql is supported because if not he'll use another distribution where it is
- It is (because every package is supported, or it's dropped), but the poor user doesn't know that Nanar went away doing his own fork, no one stepped in to maintain it ! 
- One year later, postgresql has still security bugs opened, no one takes care => package is dropped

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.
- (another scenario : there is a maintainer, but the package has pending issues for a long time, so we have to contact the maintainer about it, and maybe find another maintainer)

The difference is : because we said we would support it for Mageia 2011's lifetime, we do everything possible to keep this promise, and I think we can succeed provided the set of supported packages is carefully done. Things will be clearer, to my mind.


> We _already_ do not know what is supported or not at Mandriva. People
> push update to contribs ( I do push them for tor or puppet ), while some
> packages in main are not updated or buggy or simply unrebuildable ( see
> all mdk rpm still in the distro for long forgotten reasons ). See this
> old long standing pdftk bug caused by a issue in the java stack in
> main : https://qa.mandriva.com/show_bug.cgi?id=44372 . In main, and no
> one did anything. 

Having packages which ought to be supported and are not in practice doesn't mean that there must be no difference between officially supported and not officially supported.

> There is also lots of duplication :
> - apache & nginx, who was moved to main likely because oden like nginx,
> - the various ftp servers, 
> - sendmail & postfix, 
> - the 4 tls/ssl implementation, 
> - the 2 html rendering library ( webkit, gecko ) with more than 1
> browser. 

What prevents from refining the list if it's too big ? Choosing officially supported packages is a matter of setting priorities, because we have limited resources. In what way will things be better if there is no list of officially supported packages ?

Regards

Samuel Verschelde