diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101130/001532.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101130/001532.html | 306 |
1 files changed, 306 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101130/001532.html b/zarb-ml/mageia-dev/20101130/001532.html new file mode 100644 index 000000000..abb225261 --- /dev/null +++ b/zarb-ml/mageia-dev/20101130/001532.html @@ -0,0 +1,306 @@ +<!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=%3C1291085436.8266.368.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="001539.html"> + <LINK REL="Next" HREF="001548.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=%3C1291085436.8266.368.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">misc at zarb.org + </A><BR> + <I>Tue Nov 30 03:50:36 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001539.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001548.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1532">[ date ]</a> + <a href="thread.html#1532">[ thread ]</a> + <a href="subject.html#1532">[ subject ]</a> + <a href="author.html#1532">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le lundi 29 novembre 2010 à 18:29 +0100, Samuel Verschelde a écrit : +><i> Le lundi 29 novembre 2010 17:08:25, Michael Scherer a écrit : +</I>><i> > +</I>><i> > So either the package is supported, and we keep, or it is not, and then +</I>><i> > why should we keep it ? +</I>><i> +</I>><i> Because it works, at least partially. +</I> +Having it work 'partially" is not sufficient. There is lots of things +that would work "partially", but if we want to have people to feel +confident in the distribution, we shouldn't have "partially working +packages", some with "security flaw" and hope that users will understand +the difference. Some of them will not, and shouldn't have to. + +Partially working packages take time from packagers, space on mirrors, +space in hdlist size on everybody. They give bad reputation to our work. + +><i> Because it has users. +</I> +If no one care to even try to update it ( not even a prospective +packager ), then it is likely not much popular. I cannot really think +that a package can have lots of users, and yet none of them being +technical enough to step and become a packager, or to convince someone +from taking it. +That would just be statistically improbable. + +><i> It may have flaws, +</I>><i> it may not have the latest security fixes, it may just be supported but only updated +</I>><i> once a year... That's not a reason for dropping it. +</I> +Being insecure is a reason to drop it. If no one is willing to take time +to simply dig and apply security patchs, and later fix then we should +not let people install it. + +><i> That's why distiction between +</I>><i> officially supported and not officially supported is useful. There are working +</I>><i> packages, seldom updated, which don't deserve to be dropped, but which can't be +</I>><i> advertised as officially supported, and that's understandable. The world is not +</I>><i> either black or white, there are many shades of grey, and that's particularly +</I>><i> true for packages in a linux distribution. +</I>><i> +</I>><i> According to what you said, it looks like there will be only 2 kinds of packages : +</I>><i> - in the distribution (which would be equal to "supported") +</I>><i> - not in the distribution +</I> +You said that you want to have confidence in the distro capacity to +maintain rpms. So there shouldn't be something saying "here is packages +that we cannot support because there isn't enough people to do it". + +If we let people install insecure/buggy packages with just a click, they +will sooner or later. We will just increase the number of those that +complain about unmaintained packages and start to have a reputation of +not having security fixes on everything. + +><i> In Mandriva, you can find many examples of packages in main which are not supported in reality, +</I>><i> or even maybe simply don't work. You can find also many packages in contrib which are +</I>><i> perfectly supported, in cooker as in stable releases. You gave me examples. However I +</I>><i> see very rarely security or bugfix updates for packages in contrib for stable releases +</I>><i> (or sometimes they go to backports), whereas there are many security fixes and bugfixes +</I>><i> for packages in main thanks to Mandriva's security team. There really is a difference +</I>><i> between supported packages and other, although it's far from perfect. +</I> +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". + +><i> If there's no difference in term of security updates between php and a random maintained +</I>><i> game, then I won't be very confident in the distribution's quality. +</I> +In fact, I fail to see or understand what you mean, even after trying +very hard. + +Seeing that everything is equally supported is a sign of a lack of +quality ? + +In this case, you would likely have problem with gentoo, debian or +fedora security policy :/ + +><i> Let's say I want to install php on the stable Mageia 2011, will it be supported for +</I>><i> security fixes and bugfixes ? For how long ? Are security fixes applied as soon as possible ? +</I>><i> [ snip ] +</I> +If you really want to discuss of support policy, then a new thread +should be started. Or this thread will be more messy. The goal is to +speak about mirror layout, as written in the subject. + +><i> > > and the decision to merge core and extras must be taken together +</I>><i> > > with decisions on QA and support processes, +</I>><i> > +</I>><i> > Well, everything should be supported or dropped, that's all. Easy, done +</I>><i> > by every other distros out there except those that place a artificial +</I>><i> > separation. If there is a security bug opened and no one act on it after +</I>><i> > a time, let's drop the package. If there is a severe bug and no one act, +</I>><i> > the same, let's drop it. +</I>><i> > +</I>><i> > If people want to resurrect a rpm, they can, there is a svn for that. +</I>><i> +</I>><i> This is the most terrible thing I read so far. +</I>><i> I already tried to answer it earlier in this message, +</I>><i> however here's a last example : +</I>><i> - Someone checks if postgresql is supported because if not he'll use another distribution +</I>><i> where it is +</I>><i> - It is (because every package is supported, or it's dropped), but the poor user doesn't +</I>><i> know that Nanar went away doing his own fork, no one stepped in to maintain it ! +</I>><i> +</I>><i> - One year later, postgresql has still security bugs opened, no one takes care => package is dropped +</I> +So you prefer : +package has security problem, we do not drop it, despite no one stepping +to take care, still offer it and users get rooted ? + +><i> Now if there were a list of supported packages, either it would not be officially supported and +</I>><i> the user would know he could use it but maybe won't have security and bugfix updates, +</I>><i> or it is officially supported. Now take the example above : +</I>><i> - Someone checks if postgresql is supported because if not he'll use another distribution where it is +</I>><i> - It is ! +</I>><i> - However the maintainer went away doing his own fork, so he dropped maintainership. +</I>><i> - Someone in QA Team rings a bell : "this supported package isn't supported anymore, +</I>><i> but we promised we would support it for Mageia 2011 for 2 years from now ! We have +</I>><i> to do something !" +</I>><i> - The package team leader, or someone else, relays the warning and finds someone +</I>><i> else to maintain the package, at least for Mageia 2011, for security and bugfix +</I>><i> updates. +</I> +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. + +See for example the java issue ( no one in the community stepped to +maintain it ), kde 3 ( no one stepped to maintain it despite users +asking for it ). Or the unmaintained packages in main. + +The only reason why there was not more is because they could pay people +to do the work, something we can't and do not plan to do in the +association. + +So I do not see why you think that having a list will magically make +people maintain software while there is easy to find examples of the +contrary. And why would packagers maintain anything ( and therefor do +more work ) if they can simply not care and move it to extra ? + +><i> - (another scenario : there is a maintainer, but the package has pending issues +</I>><i> for a long time, so we have to contact the maintainer about it, and maybe find another maintainer) +</I> +another solution : "we do no promises of supporting anything". + +So far, there is no BS, no packagers team and so no security team, +nothing. Basically, we have no ressources, just promises of ressources. +The experience showed us that there is a vast difference between people +who start to do some work and people who have put their name on the +wiki. We cannot guess anything for the moment. + +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. + +><i> > We _already_ do not know what is supported or not at Mandriva. People +</I>><i> > push update to contribs ( I do push them for tor or puppet ), while some +</I>><i> > packages in main are not updated or buggy or simply unrebuildable ( see +</I>><i> > all mdk rpm still in the distro for long forgotten reasons ). See this +</I>><i> > old long standing pdftk bug caused by a issue in the java stack in +</I>><i> > 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 +</I>><i> > one did anything. +</I>><i> +</I>><i> Having packages which ought to be supported and are not in practice doesn't +</I>><i> mean that there must be no difference between officially supported and not +</I>><i> officially supported. +</I> +The same organisation of packages will likely lead to the same problem +( ie, a mess with the problem that I already highlighted ). Most +experienced packagers ( jq, boklm, tmb, among those that expressed, but +also others I have discussed with like nanar, etc ) seems to not want to +repeat again the same mistakes. + +Technically, anybody can follow security lists as they are open, see +securityfocus, or lwn to find what was updated in other distros and os. +Any packager can prepare a security update, there is nothing magic and +there is even documentation on Mandriva wiki. + +Yet almost no one did, and that's mainly because people think "I do not +need to do it, someone will do it for me" and "that's too complex". And +we need to avoid keeping this mentality, because this clearly do not +scale. This work because there is paid people for that. + +If we do say that's ok to not take care of security of a maintained +package by uploading to a unsupported media ( and later move it for +various reasons that we will not be able to avoid ), packagers will +simply tend to not take care of security because that's exactly what we +tel them. And that's exactly what happened at Mandriva. + +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> > There is also lots of duplication : +</I>><i> > - apache & nginx, who was moved to main likely because oden like nginx, +</I>><i> > - the various ftp servers, +</I>><i> > - sendmail & postfix, +</I>><i> > - the 4 tls/ssl implementation, +</I>><i> > - the 2 html rendering library ( webkit, gecko ) with more than 1 +</I>><i> > browser. +</I>><i> +</I>><i> What prevents from refining the list if it's too big ? +</I> +Just try, you will see by yourself. +But mainly : +- technical reasons ( different API doing different things ), +- maintainers individual preferences, +- different set of features and no clear vision of what is needed, +- forgotten requirements ( LSB, etc ), +- difficulty of digging the src.rpm requirements graph ( even if smart +or sophie could help on this regard ), + +And in the case of commercial sponsor like Mandriva or Canonical: +- untold requirements ( ie client requirements that cannot be expressed, +or marketing decisions, sometimes overlap with forgotten ones ) + +Nothing impossible. Just nothing that no one done, and that few +attempted. I tried just once. +-- +Michael Scherer + +</PRE> + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001539.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001548.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1532">[ date ]</a> + <a href="thread.html#1532">[ thread ]</a> + <a href="subject.html#1532">[ subject ]</a> + <a href="author.html#1532">[ 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> |