diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101130/001563.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101130/001563.html | 233 |
1 files changed, 233 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101130/001563.html b/zarb-ml/mageia-dev/20101130/001563.html new file mode 100644 index 000000000..2024f3621 --- /dev/null +++ b/zarb-ml/mageia-dev/20101130/001563.html @@ -0,0 +1,233 @@ +<!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=%3C201011302311.25889.maarten.vanraes%40gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001555.html"> + <LINK REL="Next" HREF="001534.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Maarten Vanraes</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011302311.25889.maarten.vanraes%40gmail.com%3E" + TITLE="[Mageia-dev] Mirror layout, round two">maarten.vanraes at gmail.com + </A><BR> + <I>Tue Nov 30 23:11:25 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001555.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001534.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1563">[ date ]</a> + <a href="thread.html#1563">[ thread ]</a> + <a href="subject.html#1563">[ subject ]</a> + <a href="author.html#1563">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Op dinsdag 30 november 2010 13:29:28 schreef Samuel Verschelde: +><i> > > In Mandriva, you can find many examples of packages in main which are +</I>><i> > > not supported in reality, +</I>><i> > > +</I>><i> > > or even maybe simply don't work. You can find also many packages in +</I>><i> > > contrib which are +</I>><i> > > +</I>><i> > > perfectly supported, in cooker as in stable releases. You gave me +</I>><i> > > examples. However I see very rarely security or bugfix updates for +</I>><i> > > packages in contrib for stable releases (or sometimes they go to +</I>><i> > > backports), whereas there are many security fixes and bugfixes for +</I>><i> > > packages in main thanks to Mandriva's security team. There really is a +</I>><i> > > difference between supported packages and other, although it's far +</I>><i> > > from perfect. +</I>><i> > +</I>><i> > The difference is mainly that Mandriva has a team of 2 people full time +</I>><i> > doing the bugfixes and security updates. We do not have them. +</I>><i> > +</I>><i> > So that's not because there is contribs that main got more bugfixes and +</I>><i> > updates. That's because people are paid to do the work. +</I>><i> > +</I>><i> > And so there is no correlation between "there is updates in main" and +</I>><i> > "there is a split". +</I>><i> +</I>><i> Yes there is a correlation : there is a team of people working to provide +</I>><i> quick support for a set of packages. Without a list of supported packages, +</I>><i> they couldn't focus their work. However please remember that I agreed that +</I>><i> the split mirror-side is not the only way to achieve such focus. +</I>><i> +</I>><i> Our main disagreement here is you prefer that we have the same level of +</I>><i> support for any package in the distribution (which probably means very few +</I>><i> packages in the distribution then) while I'd like many packages in the +</I>><i> distribution, a subset of which is officially supported. At least, it +</I>><i> worked well enough so that we could send more than 450 servers with +</I>><i> Mandriva in French hospitals and use Mandriva at work on workstation. +</I>><i> +</I>><i> Why do I prefer a large package list to a list restricted to +</I>><i> platinum-supported packages : I can build a system where the critical +</I>><i> parts are supported, and if I need to add some less supported stuff, I +</I>><i> still can. We should compare the ratio between packages in main and +</I>><i> packages in contrib which are actually installed on people's systems. On +</I>><i> our servers, that would be around 98% coming from main, and less than 2% +</I>><i> coming from contrib. On my workstation, it would be probably 75% vs 25%. +</I>><i> Main provides stability and security (regardless of some badly supported +</I>><i> packages). Contrib provides choice.. +</I> +I do see a point here. + +><i> > Seeing that everything is equally supported is a sign of a lack of +</I>><i> > quality ? +</I>><i> +</I>><i> It depends on the amount of available packages and available resources. +</I>><i> 10000 packages *equally supported* with 30 packages, yep, that would be a +</I>><i> sign of a lack of quality. If there are only 1000 packages, of course, +</I>><i> this is different. I still prefer the 1000 supported packages + 9000 +</I>><i> use-at-your-own-risk packages. +</I> +It is true that it could be viewed as such by people. + +><i> > > Now if there were a list of supported packages, either it would not be +</I>><i> > > officially supported and the user would know he could use it but maybe +</I>><i> > > won't have security and bugfix updates, or it is officially supported. +</I>><i> > > Now take the example above : +</I>><i> > > - Someone checks if postgresql is supported because if not he'll use +</I>><i> > > another distribution where it is - It is ! +</I>><i> > > - However the maintainer went away doing his own fork, so he dropped +</I>><i> > > maintainership. - Someone in QA Team rings a bell : "this supported +</I>><i> > > package isn't supported anymore, but we promised we would support it +</I>><i> > > for Mageia 2011 for 2 years from now ! We have to do something !" +</I>><i> > > - The package team leader, or someone else, relays the warning and +</I>><i> > > finds someone else to maintain the package, at least for Mageia 2011, +</I>><i> > > for security and bugfix updates. +</I>><i> > +</I>><i> > Please, I would appreciate that you do not arrange facts just to support +</I>><i> > your point, or I will seriously have to reconsider answering in the +</I>><i> > futur. +</I>><i> > +</I>><i> > In the first case : +</I>><i> > package is not supported, no one step to maintain, we drop -> that's +</I>><i> > bad. +</I>><i> > +</I>><i> > second case : +</I>><i> > package is not supported, someone step, we don't drop -> that's good +</I>><i> > +</I>><i> > Why do you make the assumption that someone will step to maintain in 2nd +</I>><i> > case and not in the first one ? +</I>><i> > +</I>><i> > Just saying "it should be supported because it is on some official list" +</I>><i> > is not really something that worked that well at Mandriva for the +</I>><i> > community. +</I>><i> +</I>><i> The way you make a caricature of my arguments is rude here. +</I>><i> +</I>><i> What I'm saying is totally different : +</I>><i> +</I>><i> In the first case : +</I>><i> - no one steps in to maintain it. We drop it. +</I>><i> +</I>><i> In the second case : +</I>><i> - no one steps in to maintain it. Because we promised to support it, and +</I>><i> because there are people who care about that (the QA Team Leader for +</I>><i> example), we would *try very hard* to find a solution. this is a problem, +</I>><i> we identify the problem, we try to solve it. Maybe we fail, but at least +</I>><i> we try hard, because the package is on the "supported" list. In my example +</I>><i> I supposed we find a solution, because I suppose that we find it. If I +</I>><i> were that kind of "person who cares", I'm sure I would find someone. Of +</I>><i> course, if we flag too much packages as supported, then it may become +</I>><i> actually impossible to support them all, but that would be failure due to +</I>><i> the way we built the list of supported packages, not a problem in the +</I>><i> process. +</I> +a distinction of supportyness would be interesting; however this is a non- +profit organisation, so, unless we have a list of people who will jump in for +essential package takeovers, not easily done. + +><i> > another solution : "we do no promises of supporting anything". +</I>><i> +</I>><i> This is a solution. Not mine however. +</I>><i> +</I>><i> > Once we have started and done the first release of a alpha version, and +</I>><i> > once we have a working team to package, then we can see what we can +</I>><i> > support. For the moment, any discussion based on ressources is just +</I>><i> > premature and likely not based on real data. +</I>><i> +</I>><i> Well, my proposal (have a list of supported packages) is not that related +</I>><i> to ressources. If we have very few resources, let's begin by supporting +</I>><i> just 10 packages, then grow the list progressively. +</I>><i> +</I>><i> > So splitting medias based on security support is just that, sending the +</I>><i> > wrong sign to packagers. A clear sign that not maintaining package is +</I>><i> > ok. But we should send this kind of sign if we really value quality and +</I>><i> > if we want to communicate clearly to our users. +</I>><i> +</I>><i> I already abandoned the media splitting idea in favor of a list of very +</I>><i> well supported packages list. +</I>><i> +</I>><i> Let me present the idea differently. There are 2 levels of support : +</I>><i> +</I>><i> - top guaranteed support (a subset of packages) : those are packages your +</I>><i> can rely on blindly, they'll be updated in a timely manner. Those are the +</I>><i> packages the QA Team puts its limited resources on (doesn't mean the QA +</I>><i> Team provides support, but they check that good support is provided). The +</I>><i> maintainer is responsible for the package, but the QA Team is vigilant +</I>><i> about them. - supported packages (every other package) : those are +</I>><i> maintained packages, however the QA Team doesn't have to check them. It's +</I>><i> up to the maintainer. - unsupported packages are dropped. +</I>><i> +</I>><i> So everything is supported, but there a special level of support for some +</I>><i> critical components. +</I>><i> +</I>><i> Regards +</I>><i> +</I>><i> Samuel +</I> + +I would like to stop this discussion and give a point of view from myself. + +in the optimal world, mirror layout is best to be made for the easyness of the +mirror admins. + +I would propose we do it like misc says, except that we find another solution +to make the supportyness distinction. + +I know this could affect the mirror layout, but in the optimal world, it +shouldn't. I think since we are a non-profit organisation (and therefor +idealists), that we should look at this positively and find another solution +for the distinction, if it is required. + +but that's another discussion, imho. + +Personally, i like this distinction, i would like to limit the packages for my +fathers computer to the most supported ones, for my own ease. + +maybe a well-tested tag or whatever? let's discuss this elsewhere. + + +we don't have time to let every discussion drag into other discussions that +are a little bit related. let's try to separate things as much as possible. +</PRE> + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001555.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001534.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1563">[ date ]</a> + <a href="thread.html#1563">[ thread ]</a> + <a href="subject.html#1563">[ subject ]</a> + <a href="author.html#1563">[ 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> |