[Mageia-dev] Support policy

Tue Nov 30 16:13:25 CET 2010

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 ?
+
+> 1) focus on stability and security : few very well equally supported packages. Apparently, this is 
+> where we're going for now.  May be wise as a start, but I hope this is not our final destination, 
+> because it means either very limited choice, or progressive diminution of quality of support if the 
+> number of packages increases faster than the dedicated resources.
+
+If we let people upload lots of packages without taking care of them,
+yes, this will result in a decrease of quality. 
+
+And if we do not increase ressources, this is what will happen. But I
+said in lots of mail that increasing ressources must be our priority.
+
+And so basically, the question can be summarized as "do people prefer
+packages that work or lots of packages" ?
+
+Quality or quantity ?
+Yes, it is a black and white choice, but whatever the way you present,
+you will ultimately have to do this choice at some moment. 
+
+Choosing one doesn't mean that we should not have the other, obviously,
+but when there is a choice to make, you can't avoid it.
+
+So let's compare what would they bring :
+
+Quality focus would bring :
+- more confidence for admins to use the distribution
+- more confidence for people that rely on it for various reasons
+- less unhappy users on forums ( or at least, not unhappy because the
+distribution is doing something bad )
+
+Quantity focus would bring :
+- arguments to convince people to use the distro "we have lots of rpm,
+come here" ( as expressed in the previous thread )
+- likely more users ( because this would fullfill more needs )
+
+In my opinion, focusing on quality will likely attract more technical
+contributors. People that value something that work, that are willing to
+devote time in bug reports, sending patchs because they know we also
+focus on quality. People that are skilled enough to become packagers, QA
+team member, or to give useful advice on forums, etc.
+
+And I think bringing contributors to fuel the development of the
+distribution should be our first concern. First concern because that's
+what allow to offer a good system for users, because that's what make it
+sustainable in the long run, because the work of everybody will be
+easier with a good system backed up by a solid technical community.
+
+Of course, that doesn't mean that we should not strive to have lots of
+packages, and to try to provides choice to everybody. Just that this
+need to be done in scalable and sustainable fashion. This usually mean
+1) later and 2) slowly.
+
+Quality and quantity are not incompatible in the end. 
+
+But we can't start to aim both quality and quantity at the same time.
+Deciding to import all package or to review them is for example a case
+where you can't focus on both at the same time.
+
+And so I think that to have quantity in the end, we must first choose
+quality for the start to make the distribution grow on solid foundations
+( and whith growth bring quantity ).
+
+Starting with quantity over quality doesn't increase quality at all in
+the long run. This will bring more unhappy people ( see the various
+complaint on Mandriva forums about "there is too many low quality
+packages"), will instill a mindset that would be less than ideal for
+contribution ("bug reporting is useless, people do not answer" ), and
+therefore may not allow us to get enough ressources to grow and survive.
+
+So to me, the goal should be first to aim for quality, and then add more
+packages, as I said, in a sustainable way ( ie no mass import without
+being first sure that we can manage them, no rotting rpms because people
+no longer care ).
+
+Which mean option 1.
+
+Yes, option 1 will likely frustrate people, because their favorite
+packages might not be there. 
+
+But we must realize that when we started this fork, we started a long
+journey. And that things will be different at least for the start, and
+that even when the first stable will be released, we will not have
+finish our work, just really started it.
+
+-- 
+Michael Scherer
+
+