[Mageia-dev] Support policy

Thu Dec 9 13:37:26 CET 2010

Michael scherer wrote:
+>
+>> 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.
+>   
+Let's say the first feeling I had in reading... ;-)
+> [...]
+>> 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.
+>   
+well, sometimes a newer library or a new module is just needed to build 
+another one he maintains.
+>
+>> 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.
+>   
+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.
+>   
+>   
+>> 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.
+>   
+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..." ;-)
+
+>
+>> 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.
+>   
+well, sometimes new flags introduce new errors, and fix won't happens 
+automatically...; I remember the one about strfmt.
+>   
+>> 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.
+>  
+>   
+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.
+
+