diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101129/001510.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101129/001510.html | 285 |
1 files changed, 285 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101129/001510.html b/zarb-ml/mageia-dev/20101129/001510.html new file mode 100644 index 000000000..d6316945b --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001510.html @@ -0,0 +1,285 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C1291046905.8266.173.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001525.html"> + <LINK REL="Next" HREF="001516.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C1291046905.8266.173.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">misc at zarb.org + </A><BR> + <I>Mon Nov 29 17:08:25 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001525.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001516.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1510">[ date ]</a> + <a href="thread.html#1510">[ thread ]</a> + <a href="subject.html#1510">[ subject ]</a> + <a href="author.html#1510">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le lundi 29 novembre 2010 à 15:24 +0100, Samuel Verschelde a écrit : +><i> Le lundi 29 novembre 2010 14:56:20, Michael Scherer a écrit : +</I>><i> > +</I>><i> > Le lundi 29 novembre 2010 à 13:14 +0100, Samuel Verschelde a écrit : +</I>><i> > > +</I>><i> > > It was said early that you just have to look at whether the package +</I>><i> > > has a maintainer or not to make a distinction, but this is not sufficient. +</I>><i> > > A maintainer can be very active in cauldron but not care about maintaining +</I>><i> > > for stable releases. A package can have no maintainer but be actively +</I>><i> > > supported in practice (by everybody in cauldron, by security team in +</I>><i> > > stable releases). +</I>><i> > > +</I>><i> > > The current main vs contrib approach in mandriva is very sensible. It has some (minor, to me) +</I>><i> > > drawbacks, but when I install packages from main I *know* there will be security updates, +</I>><i> > > bugfix updates, and a QA process that packages in contrib don't have. +</I>><i> > +</I>><i> > Since we pull lots of deps ( like perl module, python module ) to ensure +</I>><i> > that everything build fine without any formal check of packages, I can +</I>><i> > ensure you that packages in main do not have more QA process than +</I>><i> > anything. +</I>><i> +</I>><i> May be true until the final freeze. Once the freeze happens there is a formal +</I>><i> QA process for security and bugfix updates. That's what my post revolved around. +</I> +And how having 1 merged media prevent this process ? + + +><i> > Let me remind the problems that we are having with the split, as they +</I>><i> > are not so minor : +</I>><i> > - complexity on build system side to take in account this +</I>><i> > - packagers time lost to understand what going on when self +</I>><i> > containment is broken. Older ones do not have the problem ( or at +</I>><i> > least, know it ), but newer one sooner or later does. +</I>><i> +</I>><i> That's also what allows to block easily unwanted updates on main packages for stable releases. +</I> +I think you misunderstood me. +I speak of the fact that in cooker, people add BuildRequires in contribs +for a package in main and get puzzled by the error message. Granted, we +need to improve the error message, but that still make us lose time. +( and the fact that no one did improve the message is imho sign that +this is not annoying enough, to warrant a patch, yet annoying enough to +lose people ) + +><i> > - complexity on the users system as they need to have twice the number +</I>><i> > of media to cope with this. This also appear in the interface of +</I>><i> > various tools, and it is imho uneeded. Most people will say that we +</I>><i> > already have too much medias. +</I>><i> +</I>><i> Indeed, however it helps showing that there's a set of packages which is supported, +</I>><i> and another one which is only on behalf of the maintainer. In a community driven +</I>><i> distribution, this distinction may remains valid : some packages are officially +</I>><i> supported by the distribution, others may or may not be, depending on the maintainer +</I>><i> (or lack of maintainer). +</I> +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 ? + + +><i> The main complexity in current media in Mandriva comes from the updates/backports/testing/debug +</I>><i> packages which multiply the number of visible media, but this can be drastically improved on UI side. +</I> +That's exactly what i told 3 mails ago.... +I have also added that we cannot do miracles on ui if we keep pushing +for more complexity. + +><i> +</I>><i> > - time lost managing it. moving from contribs to main, and cleaning +</I>><i> > main. Main cleaning that is seldomly done because : +</I>><i> > - no one has time to do it +</I>><i> > - people fiercly defend the inclusion of their favorite software in +</I>><i> > main +</I>><i> +</I>><i> If maintaining a package in main means a real committment to support it, +</I>><i> with proper rules and management it seems doable to have it work better +</I>><i> than it used to at Mandriva. +</I> +It was already the case at Mandriva. But it didn't work. What step do +you propose to avoid the same pitfall ( ie, packages pushed in main +without checking first with support team, packages never cleaned because +that's a hard job, endless bickering on what goes in main or contribs ) + +><i> > - time lost because packagers have to wait on overloaded sysadmin to do +</I>><i> > the move +</I>><i> +</I>><i> Let's give the ability to more people to do the move ? +</I> +Then they would push what they want without consideration of support. +See the previous paragraph. + +><i> > > If we plan to have such processes, does the merge between core and extra +</I>><i> > > make is efficient ? I guess we don't plan to have all packages (even +</I>><i> > > maintained ones) equally supported with a full QA process (doesn't seem realistic) ? +</I>><i> > +</I>><i> > Again, reread the mail I sent. This is a user concern, not a mirror +</I>><i> > admin concern. As such, it should not leak on mirror organisation, +</I>><i> > neither on BS organisation. +</I>><i> > And the filtering proposal I made could perfectly fit, provided we find +</I>><i> > a way to get the "QA note" for a package. Maybe a webapp, with +</I>><i> > +</I>><i> +</I>><i> If there's a way to really flag packages as supported, so that we can +</I>><i> query the RPM database and know if a package is supported or not, and +</I>><i> do it easily (as a user), then I have nothing more against merging +</I>><i> core and extras. +</I> +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. + + + +><i> In fact, mirror structure and processes (including QA and support) are +</I>><i> related, +</I> +No. That's because you think that mirror structure is the only way we +have to act on urpmi config. And that shouldn't be, because we can't +support every possible distinction that everybody want without a +complexity explosion. See what I said in the mail. + +><i> and the decision to merge core and extras must be taken together +</I>><i> with decisions on QA and support processes, +</I> +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. + + +And if we want to wait on the QA team for defining the mirror structure, +then we will have a loop ( qa team requires a distro to start and be +launched, a distro requires a BS the bs requires mirror structure, and +so mirror can't depend on QA or we will never start ). + +><i> so that we don't end up with +</I>><i> a situation were no one knows what's supported or not because the media +</I>><i> separation disappeared. Without such processes I should remain against the merge. +</I> +That's already the case at Mandriva. See for example +<A HREF="http://lists.mandriva.com/kernel-discuss/2010-10/msg00000.php">http://lists.mandriva.com/kernel-discuss/2010-10/msg00000.php</A> + +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 : <A HREF="https://qa.mandriva.com/show_bug.cgi?id=44372">https://qa.mandriva.com/show_bug.cgi?id=44372</A> . In main, and no +one did anything. + +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. + + +And most people tend to simply not care to the difference between main +and contribs. If you decide to use puppet for technical reasons ( as we +did in sysadm team ), I doubt you will switch to another tool because it +is in contribs. People install web applications without using the distro +rpm also because they do not care enough about official support ( this +and maybe other reason ). + +And in the end, I think most people just keep contribs and main, and +forget the difference. + +Those that care more just take a support contact at Mandriva, and with +enough money, anything can be supported. And there is not really a 1 to +1 mapping between "supported" and "main". + +So the split did not help much on this regard at all. It just give a +false sense of security and more complexity on the distro side. + +><i> > > Packages in core get the "QA approved" stamp whereas packages in extra get none. +</I>><i> > +</I>><i> > The self containment requirement would make it very hard to get such QA +</I>><i> > approved stamp. +</I>><i> > +</I>><i> > We cannot have a package being tested without doing the same for its +</I>><i> > requires first. And we cannot say that we support a package without +</I>><i> > supporting the full requires. +</I>><i> > +</I>><i> > Look at openoffice at Mandriva. It does requires +</I>><i> > tomcat5-servlet-2.4-api, hsqldb on 2010.1 . They are both non trivial to +</I>><i> > test, and I am quite sure that they were not much "QA approved" besides +</I>><i> > "openoffice work for basic tasks". And in fact, when eclipse was in +</I>><i> > main, this was the same. +</I>><i> > +</I>><i> > So in order to have openoffice to have a QA approved stamp, openjdk, +</I>><i> > tomcat and hsqldb would have one. I am pretty sure they do not had +</I>><i> > extensive checks.. +</I>><i> +</I>><i> The "QA approved" stamps, in my mind, means : "there no known blocking bug or +</I>><i> security issue, and if we find some after the release, we'll fix them rapidly". +</I>><i> This is more a guarantee of support than a guarantee of quality. +</I> +Again, I am not sure that hsqldb, being unmaintained, would be +supported. + +And there is know bugs that were not fixed rapidly in main ( see the +pdftk example I gave for the most notorious one ). + +So let's be honest, let's don't start by doing promise we can't keep for +the moment. + +-- +Michael Scherer + +</PRE> + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001525.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001516.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1510">[ date ]</a> + <a href="thread.html#1510">[ thread ]</a> + <a href="subject.html#1510">[ subject ]</a> + <a href="author.html#1510">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |