diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101209/001679.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101209/001679.html | 190 |
1 files changed, 190 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101209/001679.html b/zarb-ml/mageia-dev/20101209/001679.html new file mode 100644 index 000000000..f370fb96b --- /dev/null +++ b/zarb-ml/mageia-dev/20101209/001679.html @@ -0,0 +1,190 @@ +<!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=%3C4D00CD86.6010708%40gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + + <LINK REL="Next" HREF="001680.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=%3C4D00CD86.6010708%40gmail.com%3E" + TITLE="[Mageia-dev] Support policy">ghibomgx at gmail.com + </A><BR> + <I>Thu Dec 9 13:37:26 CET 2010</I> + <P><UL> + + <LI>Next message: <A HREF="001680.html">[Mageia-dev] Mirror layout +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1679">[ date ]</a> + <a href="thread.html#1679">[ thread ]</a> + <a href="subject.html#1679">[ subject ]</a> + <a href="author.html#1679">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Michael scherer wrote: +><i> +</I>>><i> why this kind of "competition"? +</I>>><i> +</I>><i> +</I>><i> It is up to you to explain why you see competition when i just +</I>><i> state that we have obviously a different set of ressources. +</I>><i> +</I>Let's say the first feeling I had in reading... ;-) +><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>>><i> +</I>><i> +</I>><i> Well, we at least except the maintainer to know how to run the software +</I>><i> or how to use it. If someone package a perl module, it is either for running +</I>><i> a script, or for another module ( hence in all case using it ). +</I>><i> So of course, the maintainer do not know everything, but he has at least +</I>><i> basic knowledge about the software. +</I>><i> +</I>well, sometimes a newer library or a new module is just needed to build +another one he maintains. +><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>>><i> +</I>><i> +</I>><i> That solution was already used for koffice or kdevelop, IIRC. +</I>><i> And the fact is while it should be IMHO a really last resort solution, +</I>><i> we cannot avoid keeping it in mind. +</I>><i> And the issue is not only our reputation, but also the one of kdenlive, and +</I>><i> as a distributor, we must think of our upstream as well. +</I>><i> +</I>Yep, though the reputation IMHO it's not strictly tied to newer or older +package. We might have old packages which works, as well as old packages +which don't even install anymore. We might be ultraconservative, not +changing a package even under torture if not have passed some sieve, +like some well-known distro or ultramodern. Probably there is the need +to find a balance. From my experience old packages still working are +those linked to libc only and not C++, as well as not tied to many +toolboxes as deps. I might for instance found that the old quake3 demo +binary that I packaged for MDV 7.0 maybe, is still working today with +audio and 3d GL acceleration. +><i> +</I>><i> +</I>>><i> 2) We might let people know that the backport version works. So more +</I>>><i> communcation here. +</I>>><i> +</I>><i> +</I>><i> Or add the backport to updates, as this would be a bugfix. +</I>><i> +</I>That suppose the channel above. But if one has to "play" or "fight" too +much, that won't happen IMHO. E.g. in the specific example the quick +step are: version in main doesn't work at all, version in backports do +(at most can't be worst), let's update, end of the story. But the real +rule would have been, ask for an update, and take the whole +responsibility for it, including writing the report, etc.; typical examples: + +- post to a mailing list, e.g. on maintainers mail list: "hey, package +xxx doesn't work, package xxx in backports does, let's do the upgrade"? +- QA answer: "well, is there a bug report?" +- "hmmm, not sure, will check". Sound there isn't. +- QA: "then write one". +- "hmmm, I just found some already did, I had missed before. can we have +the upgrade now"? +- QA: "well, are you sure it won't break anything already working?" +- "well, it can't, original is already broken". +- QA: "well, but please, write a detailed report for the update, but are +you really sure it won't break anything? It will be your fault" +- at this point doubt is growing... "Hmmm, I have to write a report, +hmmm, what to put on it, hmmm...certainly I can't put a generic "old xxx +package doesn't work xxx+1 does"...hmmm let's think...well, xxx+1 works +for me, having it in backports is enough for me. Let's do this long +stuff another time..." ;-) + +><i> +</I>>><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>>><i> +</I>><i> +</I>><i> +</I>><i> We need to offload everything we can on automatic scripts. This was my presentation +</I>><i> in 2004 at cooker meeting, and this is still true, IMHO. Youri, rpmlint, etc, all +</I>><i> have served to catch errors that were discovered by random user before. +</I>><i> Of course, this doesn't fix them. +</I>><i> +</I>well, sometimes new flags introduce new errors, and fix won't happens +automatically...; I remember the one about strfmt. +><i> +</I>>><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>>><i> +</I>><i> +</I>><i> Yup. And I think we can adopt this progressively. Ie, first focus on +</I>><i> writing one test file, and then use it. And start with a 2nd test file, etc. +</I>><i> Once there is enough test file, people can organize test days. +</I>><i> And we could even share those procedures with others distributions. +</I>><i> +</I>><i> +</I>Yep, I was using a sort of such kind of protocols, for instance for +mozplugger and mplayerplug-in. People might add also some further deeper +tests. + +Bye +Giuseppe. + +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + + <LI>Next message: <A HREF="001680.html">[Mageia-dev] Mirror layout +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1679">[ date ]</a> + <a href="thread.html#1679">[ thread ]</a> + <a href="subject.html#1679">[ subject ]</a> + <a href="author.html#1679">[ 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> |