[Mageia-dev] Mirror layout, round two

[Samuel Verschelde]

Le lundi 29 novembre 2010 14:56:20, Michael Scherer a écrit :
> 
> Le lundi 29 novembre 2010 à 13:14 +0100, Samuel Verschelde a écrit :
> >
> > It was said early that you just have to look at whether the package 
> > has a maintainer or not to make a distinction, but this is not sufficient. 
> > A maintainer can be very active in cauldron but not care about maintaining 
> > for stable releases. A package can have no maintainer but be actively 
> > supported in practice (by everybody in cauldron, by security team in 
> > stable releases).
> >
> > The current main vs contrib approach in mandriva is very sensible. It has some (minor, to me) 
> > drawbacks, but when I install packages from main I *know* there will be security updates, 
> > bugfix updates, and a QA process that packages in contrib don't have. 
> 
> Since we pull lots of deps ( like perl module, python module ) to ensure
> that everything build fine without any formal check of packages, I can
> ensure you that packages in main do not have more QA process than
> anything. 

May be true until the final freeze. Once the freeze happens there is a formal QA process for security and bugfix updates. That's what my post revolved around.

> Let me remind the problems that we are having with the split, as they
> are not so minor :
> - complexity on build system side to take in account this
>   - packagers time lost to understand what going on when self
>     containment is broken. Older ones do not have the problem ( or at
>     least, know it ), but newer one sooner or later does.

That's also what allows to block easily unwanted updates on main packages for stable releases. 

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

The main complexity in current media in Mandriva comes from the updates/backports/testing/debug packages which multiply the number of visible media, but this can be drastically improved on UI side.


> - time lost managing it. moving from contribs to main, and cleaning
>   main. Main cleaning that is seldomly done because :
>    - no one has time to do it
>    - people fiercly defend the inclusion of their favorite software in
>        main 

If maintaining a package in main means a real committment to support it, with proper rules and management it seems doable to have it work better than it used to at Mandriva.

> - time lost because packagers have to wait on overloaded sysadmin to do 
>   the move

Let's give the ability to more people to do the move ?

> - complexity over time of support because package move from main to
>    contribs and viceversa. Especially when there is some backports from
>    a software in main that would requires a software in contribs, etc.

Indeed, this is a pain :)

> > Do we plan to have no QA process at all in Mageia ? 
> 
> You should not use this kind of formulation, this is FUD.

It was a rhetorical question, as you can guess from what followed just after that. At least it was intended as such. I remove it if it was too FUDist :)
As a side note, I should have said "stable release support" rather that QA.

> > If we plan to have such processes, does the merge between core and extra 
> > make is efficient ? I guess we don't plan to have all packages (even 
> > maintained ones) equally supported with a full QA process (doesn't seem realistic) ?
> 
> Again, reread the mail I sent. This is a user concern, not a mirror
> admin concern. As such, it should not leak on mirror organisation,
> neither on BS organisation. 
> And the filtering proposal I made could perfectly fit, provided we find
> a way to get the "QA note" for a package. Maybe a webapp, with 
> 

If there's a way to really flag packages as supported, so that we can query the RPM database and know if a package is supported or not, and do it easily (as a user), then I have nothing more against merging core and extras.

In fact, mirror structure and processes (including QA and support) are related, and the decision to merge core and extras must be taken together with decisions on QA and support processes, so that we don't end up with a situation were no one knows what's supported or not because the media separation disappeared. Without such processes I should remain against the merge.


> > Packages in core get the "QA approved" stamp whereas packages in extra get none.
> 
> The self containment requirement would make it very hard to get such QA
> approved stamp. 
> 
> We cannot have a package being tested without doing the same for its
> requires first. And we cannot say that we support a package without
> supporting the full requires. 
> 
> Look at openoffice at Mandriva. It does requires
> tomcat5-servlet-2.4-api, hsqldb on 2010.1 . They are both non trivial to
> test, and I am quite sure that they were not much "QA approved" besides
> "openoffice work for basic tasks". And in fact, when eclipse was in
> main, this was the same.
> 
> So in order to have openoffice to have a QA approved stamp, openjdk,
> tomcat and hsqldb would have one. I am pretty sure they do not had
> extensive checks..

The "QA approved" stamps, in my mind, means : "there no known blocking bug or security issue, and if we find some after the release, we'll fix them rapidly". This is more a guarantee of support than a guarantee of quality.

Regards

Samuel Verschelde