[Mageia-dev] Support policy

[Giuseppe Ghibò]

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.