[Mageia-dev] Mirror layout, round two

[andre999]

Samuel Verschelde a écrit :
>
> 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.
>>>>          
4 instead of 3 is 33% more.
That aside, you're essentially referring to package installer tools 
(rpmdrake) for the user.
If we have a separate "extra", and the user chooses to (usually) only 
install officially supported packages, the response to the user will be 
faster with the extra media, not slower.
Now I deactivate contrib most of the time for faster performance.  (It 
makes a *big* difference.)
With a relatively smaller "core" (than "main"), we will have an even 
greater performance advantage for keeping an extra set of media.
And if the user chooses to keep "extra" activated ?  Essentially no 
difference.

But you do raise an important point.  We do need to improve rpmdrake and 
associated tools.
I think that that should be a priority.
However as long as the user is permitted to choose, they will be 
presented with choices, in one form or another.  Isn't choice part of 
what Linux is supposed to be about ?
>>> 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).
>>>        
Exactly
>> 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.
>    
Totally agree.
>
> 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.
>    

I think that one advantage of using the mirror structure is that it is a 
sandbox that makes it clear to everyone (packagers, maintainers, current 
and potential users, qa, etc) what is officially supported and what is not.
It has largely worked for Mandriva.
What didn't work is
(1) the lack of a well-defined and applied criteria for what is to be 
officially supported, and
(2) the lack of a clear applied policy and strategies of how to deal 
with possible dependancies of supported packages on non-supported packages.

Without this sandbox, packagers are much less likely to do what is 
necessary to ensure that supported packages are fully supported, 
including dependancies.  Including getting the necessary support from 
others to achieve this.
Support is much more than an official maintainer.

The supposed advantages of discarding a set of repositories over having 
an obvious sandbox aren't clear.
Another mechanism allowing the end-user to select only supported 
packages will be at least as complex.
There will be no difference for mirrors.  (Same size, just a few extra 
directories.)
Packagers can't help but notice if accessing dependancies outside the 
sandbox.

Of course, if we can find another mechanism as likely to succeed ...
> ...
>    
>> 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.
Sounds like a distro killer policy.  But we're just getting started ... :(

>   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.
>    
Excellent example.
This also points to the advantage of a mirror-based categorization.  
Support should only change by release, not stop somewhere in between.  
Maybe caudron uses a list, which could change at any time (in view of 
the next release), but users would never expect support to cease 
mid-release.
>> 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.
>    
Exactly
>> 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 ?
>    
Having 2 officially supported equivalents is not necessarily a bad idea 
for important functions, as it gives more user choice - like mysql & 
postgresql, or webkit & gecko.
However we don't need 47 packages that do almost exactly the same 
thing.  At least not officially supported.  We do have to be selective.
Note that many packages, such as translation aides, alternate text 
editors, etc, won't break a user's system if they break.  So they would 
belong in "extra" in any case.
> Regards
>
> Samuel Verschelde
>    

another 2 cents :)

- André