diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101204/001598.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101204/001598.html | 228 |
1 files changed, 228 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101204/001598.html b/zarb-ml/mageia-dev/20101204/001598.html new file mode 100644 index 000000000..1f2c0a64a --- /dev/null +++ b/zarb-ml/mageia-dev/20101204/001598.html @@ -0,0 +1,228 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Support policy + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Support%20policy&In-Reply-To=%3C4CFA1A3F.8070800%40gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001599.html"> + <LINK REL="Next" HREF="001601.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Support policy</H1> + <B>Giuseppe Ghibò</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Support%20policy&In-Reply-To=%3C4CFA1A3F.8070800%40gmail.com%3E" + TITLE="[Mageia-dev] Support policy">ghibomgx at gmail.com + </A><BR> + <I>Sat Dec 4 11:38:55 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001599.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001601.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1598">[ date ]</a> + <a href="thread.html#1598">[ thread ]</a> + <a href="subject.html#1598">[ subject ]</a> + <a href="author.html#1598">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Michael Scherer wrote: +><i> +</I>><i> Well, from a physical point of view, everything is limited, so saying +</I>><i> "limited ressources" didn't indeed told much. +</I>><i> +</I>><i> I think that the ressources at Mandriva could be summarized as "around 1 +</I>><i> to 3 full time people ( maybe more, maybe less, and likely not full time +</I>><i> on the stable free distro )". +</I>><i> +</I>><i> Which is not balanced at all when compared to the ressources that were +</I>><i> placed in packaging. Ie, there was much more people to produce rpm than +</I>><i> people to +</I>><i> 1) take care of update ( secteam, 2 people ) +</I>><i> 2) take care of testing update ( qateam, 1-3 people ) +</I>><i> +</I>><i> Being unbalanced lead to the main/contribs split with the complexity and +</I>><i> problem that went with it. Of course, the goal is not to have less +</I>><i> packagers, but rather more Qa people, the 2 being not exclusive. +</I>><i> +</I>><i> This then bring to the simple question is "why did we have more +</I>><i> packagers than QA ?" +</I>><i> +</I>><i> My own opinion is that because packaging was opened to external +</I>><i> contribution since almost the start ( since 10 years, packagers number +</I>><i> have growth ), while QA was not, and I suppose that was due to a lack of +</I>><i> time devoted on making QA more open ( ironically likely due to a lack of +</I>><i> ressources at the first place ). +</I>><i> +</I>><i> And so, I think we are now in a totally different situation. QA will be +</I>><i> more open, because it cannot be closed. We can ( and I think we should ) +</I>><i> make the QA ressources grow with the packagers one ( among others ). +</I>><i> +</I>><i> So how can we do ? +</I>><i> +</I>><i> While this may not seems apparent at first sight, I think that Fedora is +</I>><i> actually leading in term of community QA process ( we still had the lead +</I>><i> in term of automated QA ). +</I>><i> +</I>><i> Basically, packages that are updated requires to be noted, with a system +</I>><i> of karma ( <A HREF="http://fedoraproject.org/wiki/Bodhi_Guide#Karma">http://fedoraproject.org/wiki/Bodhi_Guide#Karma</A> ). +</I>><i> Positive karma, the update is pushed, negative, it is not. +</I>><i> +</I>><i> Anybody can test anything, even if there is also a proven tester group. +</I>><i> +</I>><i> There is even the concept of critical path packages, aka very important +</I>><i> package that must be deeply tested +</I>><i> ( <A HREF="http://fedoraproject.org/wiki/Critical_Path_Packages">http://fedoraproject.org/wiki/Critical_Path_Packages</A> ). +</I>><i> +</I>><i> Of course, the system is not perfect and will not solve everything. For +</I>><i> example, last week, openldap update broke server functionality : +</I>><i> ( <A HREF="http://lists.fedoraproject.org/pipermail/devel/2010-November/146097.html">http://lists.fedoraproject.org/pipermail/devel/2010-November/146097.html</A> ) +</I>><i> +</I>><i> But still, having community enabled QA is a great way to have every grow +</I>><i> properly. +</I>><i> And in fact, that's exactly one of the feature of your project +</I>><i> mageia-app-db. So we could indeed have a better QAteam by easing the +</I>><i> work of community, using mageia-app-db. Ie, take regular user, and turn +</I>><i> them in QA team member. +</I>><i> +</I>><i> And so, doing like this would enable to give us : +</I>><i> - real involvement from some users +</I>><i> - balanced community, not overwhelmed by technical maniac packagers +</I>><i> ( like me ) +</I>><i> - having a better Qa, for a better system +</I>><i> +</I>><i> So while nothing is done, while I am not a member of the QA team nor a +</I>><i> leader, while I just speak to voice my opinion, and while this is just a +</I>><i> proposal based on what other have done to solve the same issue than us, +</I>><i> this show that we can have more ressources than what Mandriva had. +</I>><i> +</I>><i> +</I>why this kind of "competition"? +><i> Ie, we need to think with a fresh mind, and I am sure that people can +</I>><i> creatively propose solutions on the problem : +</I>><i> +</I>><i> "how can we have a more balanced QA and packagers team". +</I>><i> +</I>><i> +</I>><i> +</I>What you are saying is good, and I would like to extend what you posted +with what follows. IMHO we are trying to focus too much on what it was +wrong to forget what it was already good, like if what was already good +in the distro would be granted by default (e.g. trying to focus too much +on what is already in ANY of the 100 distrowatch.com distros: all of +them have the same core-packages on the other hand] to forget what is +was already good or better: e.g. good support for extra hardware, better +support for scientific applications, etc.). + +We should summarize what there is from what there isn't in the distro. +The 2nd problems is that we seem assigning to most packagers and +maintainers some secret powers that they should have, like knowing the +package better or at the same level than upstream developers. If not, +then there are lack of resources...; maybe they just know how to +assemble and compile it...and that's all. IMHO knowing the package at +such high levels has become the exception, not the rule. One +packager/maintainer might know very very well 1 or maybe 3,4 packages +(e.g. colin for pulseaudio, buchan for samba, me for tex and so on), but +there are 10000 packages out there and there aren't 5000 maintainers... + +I give you an example. In MDV 2010.0 or 2010.1 the kdenlive package, a +video editing application, was not working at all. It crashes on basic +stuff as soon as you open or import a video file. In other words +unusable. How was possible that? Well, one might say poor QA, bad +packagers, bad maintainers or no maintainers at all, or no QA at all. It +your fault, it's their fault, it's our fault. Indeed it doesn't matter. +The main problem is that we rely as main source of QA the bugzilla. So +what is reported on bugzilla has a bug that we should fix, what there +isn't should work by default and has automagically an higher QA score. +IMHO this is a false assumption. I might find it crashes and be lazy and +not doing any bugzilla report, or I'm not sure about what to tell +exactly, because maybe I think it's fault of my configuration, and so +on. In the specific example backports have a working kdenlive (maybe +it's just luck, dunno) but according to the supposed QA score the +kdenlive in main should be better than the one in backports. And indeed +it isn't because any program barely working is better than any program +crashing on startup. +To solve this there are a lot of solution, but it's not said that the +one or the other should influence people to use this distro and not +another, like we might think. E.g. + +1) We might move kdenlive from good main to evil contrib or remove +kdenlive from the distro? Well, a non-existing package won't crash. And +so distro would result more polished, ordered (I like ordered and +cleaned distro with no broken deps in hdlists, really) should rock. But +from point of view of an end user he don't have any video editing +application anyway. So who cares of the others packages he won't use? + +2) We might let people know that the backport version works. So more +communcation here. + +3) We might add several new rules and weights on the shoulders of the +maintainers/packagers. A packager could fly away, so letting these rules +on the shoulders of the other survived packagers which then will be more +overloaded, and then could fly away more. Sound a bit like the +"highlander" packager... + +4) We might help to let these rules easier, lighter and quicker to be +implemented (more communcation, self or packagers helping each others, +more automatic tools) + +5) Add a precise protocol of testing for each package. This might be +automatic or manual (or both). In case of manual, the testing protocol +steps might be performed by anyone. But shouldn't go in the destructive +spiral of more rules. Documentation should be crystal clear, and +information should be easy to catch not let users waste days and days +trying to find the right thing to do, in seeking good documentation +between tons of obsolete and bad one. Also the report of the testing +should be easy to post, not opening 27 sites, scroll between 18000 +packages, wait 10 minutes the server answers, or sending 84 mails and +wait answer from 54 different people...; In case of kdenlive, a basic +protocol test could be like this: 1) install the package 2) Go on menu +Project/Add clip and open the file blabla.avi HERE... 3) Go on menu +Monitor/Clip and click on the button "play" 4) ... 5) rely also on the +upstream protocol testing if exists 6) report it works by a couple of +clicks. This won't require specific skill and even users who might not +have ever used this package could partecipate. + +5) Punish the one who uploaded the package. Blocking it for one lap. +Well this is a bit scaring ;-) Don't do that. + +6) Any combination of the above. + +Second problem is that there also any referring to documentation +support, but speak only from point of view of packagers. We might have +things that are rock solid, but if nobody knows how to use them... ;-) + +Bye +Giuseppe. + +</PRE> + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001599.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001601.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1598">[ date ]</a> + <a href="thread.html#1598">[ thread ]</a> + <a href="subject.html#1598">[ subject ]</a> + <a href="author.html#1598">[ 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> |