[Mageia-dev] Support policy

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
+
+