[Mageia-dev] Support policy

Michael Scherer misc at zarb.org
Tue Nov 30 18:09:38 CET 2010


Le mardi 30 novembre 2010 à 16:36 +0100, Samuel Verschelde a écrit :
> Le mardi 30 novembre 2010 16:13:25, Michael Scherer a écrit :
> > 
> > Le mardi 30 novembre 2010 à 13:31 +0100, Samuel Verschelde a écrit :
> > > Hi, 
> > > 
> > > I would like to discuss the support policy for Mageia.
> > > 
> > > It would be interesting to know (or decide) where Mageia is heading, given our limited resources :
> > 
> > can you first explain what are our ressources so you can explain how
> > limited you think they are ?
> > 
> 
> Well, I can't because as you already told me we don't know what our resources will be. 
> What I can guess is that they are limited because I know no free software project 
> where there's too much resources.

Well, from a physical point of view, everything is limited, so saying
"limited ressources" didn't indeed told much. 

I think that the ressources at Mandriva could be summarized as "around 1
to 3 full time people ( maybe more, maybe less, and likely not full time
on the stable free distro )".

Which is not balanced at all when compared to the ressources that were
placed in packaging. Ie, there was much more people to produce rpm than
people to 
1) take care of update ( secteam, 2 people )
2) take care of testing update ( qateam, 1-3 people )

Being unbalanced lead to the main/contribs split with the complexity and
problem that went with it. Of course, the goal is not to have less
packagers, but rather more Qa people, the 2 being not exclusive. 

This then bring to the simple question is "why did we have more
packagers than QA ?"

My own opinion is that because packaging was opened to external
contribution since almost the start ( since 10 years, packagers number
have growth ), while QA was not, and I suppose that was due to a lack of
time devoted on making QA more open ( ironically likely due to a lack of
ressources at the first place ).

And so, I think we are now in a totally different situation. QA will be
more open, because it cannot be closed. We can ( and I think we should )
make the QA ressources grow with the packagers one ( among others ).

So how can we do ? 

While this may not seems apparent at first sight, I think that Fedora is
actually leading in term of community QA process ( we still had the lead
in term of automated QA ).
 
Basically, packages that are updated requires to be noted, with a system
of karma ( http://fedoraproject.org/wiki/Bodhi_Guide#Karma ). 
Positive karma, the update is pushed, negative, it is not. 

Anybody can test anything, even if there is also a proven tester group.

There is even the concept of critical path packages, aka very important
package that must be deeply tested
( http://fedoraproject.org/wiki/Critical_Path_Packages ).

Of course, the system is not perfect and will not solve everything. For
example, last week, openldap update broke server functionality :
( http://lists.fedoraproject.org/pipermail/devel/2010-November/146097.html )

But still, having community enabled QA is a great way to have every grow
properly.
And in fact, that's exactly one of the feature of your project
mageia-app-db. So we could indeed have a better QAteam by easing the
work of community, using mageia-app-db. Ie, take regular user, and turn
them in QA team member.

And so, doing like this would enable to give us :
- real involvement from some users
- balanced community, not overwhelmed by technical maniac packagers
( like me )
- having a better Qa, for a better system

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. 

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".


-- 
Michael Scherer



More information about the Mageia-dev mailing list