diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101205/001604.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101205/001604.html | 192 |
1 files changed, 192 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101205/001604.html b/zarb-ml/mageia-dev/20101205/001604.html new file mode 100644 index 000000000..bc826e455 --- /dev/null +++ b/zarb-ml/mageia-dev/20101205/001604.html @@ -0,0 +1,192 @@ +<!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=%3C20101205112450.GA12918%40sisay.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + + <LINK REL="Next" HREF="001605.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Support policy</H1> + <B>Michael scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Support%20policy&In-Reply-To=%3C20101205112450.GA12918%40sisay.ephaone.org%3E" + TITLE="[Mageia-dev] Support policy">misc at zarb.org + </A><BR> + <I>Sun Dec 5 12:24:50 CET 2010</I> + <P><UL> + + <LI>Next message: <A HREF="001605.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1604">[ date ]</a> + <a href="thread.html#1604">[ thread ]</a> + <a href="subject.html#1604">[ subject ]</a> + <a href="author.html#1604">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Sat, Dec 04, 2010 at 11:38:55AM +0100, Giuseppe Ghibò wrote: +><i> Michael Scherer wrote: +</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> why this kind of "competition"? +</I> +It is up to you to explain why you see competition when i just +state that we have obviously a different set of ressources. + +><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> What you are saying is good, and I would like to extend what you +</I>><i> posted with what follows. IMHO we are trying to focus too much on +</I>><i> what it was wrong to forget what it was already good, like if what +</I>><i> was already good in the distro would be granted by default (e.g. +</I>><i> trying to focus too much on what is already in ANY of the 100 +</I>><i> distrowatch.com distros: all of them have the same core-packages on +</I>><i> the other hand] to forget what is was already good or better: e.g. +</I>><i> good support for extra hardware, better support for scientific +</I>><i> applications, etc.). +</I>><i> +</I>><i> We should summarize what there is from what there isn't in the +</I>><i> distro. The 2nd problems is that we seem assigning to most packagers +</I>><i> and maintainers some secret powers that they should have, like +</I>><i> knowing the package better or at the same level than upstream +</I>><i> developers. If not, then there are lack of resources...; maybe they +</I>><i> just know how to assemble and compile it...and that's all. IMHO +</I>><i> knowing the package at such high levels has become the exception, +</I>><i> not the rule. One packager/maintainer might know very very well 1 or +</I>><i> maybe 3,4 packages (e.g. colin for pulseaudio, buchan for samba, me +</I>><i> for tex and so on), but there are 10000 packages out there and there +</I>><i> aren't 5000 maintainers... +</I> +Well, we at least except the maintainer to know how to run the software +or how to use it. If someone package a perl module, it is either for running +a script, or for another module ( hence in all case using it ). +So of course, the maintainer do not know everything, but he has at least +basic knowledge about the software. + +><i> I give you an example. In MDV 2010.0 or 2010.1 the kdenlive package, +</I>><i> a video editing application, was not working at all. It crashes on +</I>><i> basic stuff as soon as you open or import a video file. In other +</I>><i> words unusable. How was possible that? Well, one might say poor QA, +</I>><i> bad packagers, bad maintainers or no maintainers at all, or no QA at +</I>><i> all. It your fault, it's their fault, it's our fault. Indeed it +</I>><i> doesn't matter. The main problem is that we rely as main source of +</I>><i> QA the bugzilla. So what is reported on bugzilla has a bug that we +</I>><i> should fix, what there isn't should work by default and has +</I>><i> automagically an higher QA score. IMHO this is a false assumption. I +</I>><i> might find it crashes and be lazy and not doing any bugzilla report, +</I>><i> or I'm not sure about what to tell exactly, because maybe I think +</I>><i> it's fault of my configuration, and so on. In the specific example +</I>><i> backports have a working kdenlive (maybe it's just luck, dunno) but +</I>><i> according to the supposed QA score the kdenlive in main should be +</I>><i> better than the one in backports. And indeed it isn't because any +</I>><i> program barely working is better than any program crashing on +</I>><i> startup. +</I>><i> To solve this there are a lot of solution, but it's not said that +</I>><i> the one or the other should influence people to use this distro and +</I>><i> not another, like we might think. E.g. +</I>><i> +</I>><i> 1) We might move kdenlive from good main to evil contrib or remove +</I>><i> kdenlive from the distro? Well, a non-existing package won't crash. +</I>><i> And so distro would result more polished, ordered (I like ordered +</I>><i> and cleaned distro with no broken deps in hdlists, really) should +</I>><i> rock. But from point of view of an end user he don't have any video +</I>><i> editing application anyway. So who cares of the others packages he +</I>><i> won't use? +</I> +That solution was already used for koffice or kdevelop, IIRC. +And the fact is while it should be IMHO a really last resort solution, +we cannot avoid keeping it in mind. +And the issue is not only our reputation, but also the one of kdenlive, and +as a distributor, we must think of our upstream as well. + +><i> 2) We might let people know that the backport version works. So more +</I>><i> communcation here. +</I> +Or add the backport to updates, as this would be a bugfix. + +><i> 3) We might add several new rules and weights on the shoulders of +</I>><i> the maintainers/packagers. A packager could fly away, so letting +</I>><i> these rules on the shoulders of the other survived packagers which +</I>><i> then will be more overloaded, and then could fly away more. Sound a +</I>><i> bit like the "highlander" packager... +</I> +Like "running the package at least once to see if it work before uploading" ? +This is not a new rule. + +><i> 4) We might help to let these rules easier, lighter and quicker to +</I>><i> be implemented (more communcation, self or packagers helping each +</I>><i> others, more automatic tools) +</I> + +We need to offload everything we can on automatic scripts. This was my presentation +in 2004 at cooker meeting, and this is still true, IMHO. Youri, rpmlint, etc, all +have served to catch errors that were discovered by random user before. +Of course, this doesn't fix them. + +><i> 5) Add a precise protocol of testing for each package. This might be +</I>><i> automatic or manual (or both). In case of manual, the testing +</I>><i> protocol steps might be performed by anyone. But shouldn't go in the +</I>><i> destructive spiral of more rules. Documentation should be crystal +</I>><i> clear, and information should be easy to catch not let users waste +</I>><i> days and days trying to find the right thing to do, in seeking good +</I>><i> documentation between tons of obsolete and bad one. Also the report +</I>><i> of the testing should be easy to post, not opening 27 sites, scroll +</I>><i> between 18000 packages, wait 10 minutes the server answers, or +</I>><i> sending 84 mails and wait answer from 54 different people...; In +</I>><i> case of kdenlive, a basic protocol test could be like this: 1) +</I>><i> install the package 2) Go on menu Project/Add clip and open the file +</I>><i> blabla.avi HERE... 3) Go on menu Monitor/Clip and click on the +</I>><i> button "play" 4) ... 5) rely also on the upstream protocol testing +</I>><i> if exists 6) report it works by a couple of clicks. This won't +</I>><i> require specific skill and even users who might not have ever used +</I>><i> this package could partecipate. +</I> +Yup. And I think we can adopt this progressively. Ie, first focus on +writing one test file, and then use it. And start with a 2nd test file, etc. +Once there is enough test file, people can organize test days. +And we could even share those procedures with others distributions. + +><i> 5) Punish the one who uploaded the package. Blocking it for one lap. +</I>><i> Well this is a bit scaring ;-) Don't do that. +</I> +Indeed, punishing people should not be used, this doesn't work. We are not child +anymore. And I think this would be humiliating ( but I understand that this +was proposed to be complete ). + +-- +Michael Scherer +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + + <LI>Next message: <A HREF="001605.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1604">[ date ]</a> + <a href="thread.html#1604">[ thread ]</a> + <a href="subject.html#1604">[ subject ]</a> + <a href="author.html#1604">[ 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> |