[Mageia-dev] Support policy

Sun Dec 5 12:24:50 CET 2010

On Sat, Dec 04, 2010 at 11:38:55AM +0100, Giuseppe Ghibò wrote:
+> Michael Scherer wrote:
+> >So while nothing is done, while I am not a member of the QA team nor a
+> >leader, while I just speak to voice my opinion, and while this is just a
+> >proposal based on what other have done to solve the same issue than us,
+> >this show that we can have more ressources than what Mandriva had.
+> >
+> why this kind of "competition"?
+
+It is up to you to explain why you see competition when i just
+state that we have obviously a different set of ressources.
+
+> >Ie, we need to think with a fresh mind, and I am sure that people can
+> >creatively propose solutions on the problem :
+> >
+> >"how can we have a more balanced QA and packagers team".
+> >
+> >
+> 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...
+
+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 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?
+
+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.
+  
+> 2) We might let people know that the backport version works. So more
+> communcation here.
+
+Or add the backport to updates, as this would be a bugfix.
+
+> 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...
+
+Like "running the package at least once to see if it work before uploading" ?
+This is not a new rule.
+ 
+> 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)
+
+
+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.
+
+> 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.
+
+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.
+ 
+> 5) Punish the one who uploaded the package. Blocking it for one lap.
+> Well this is a bit scaring ;-) Don't do that.
+
+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
+