[Mageia-dev] Support policy

Wed Dec 1 00:33:32 CET 2010

Op dinsdag 30 november 2010 13:31:08 schreef Samuel Verschelde:
+> 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 : 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. 2) focus on choice : many packages, but no support
+> policy. This would be really bad, I think we're not heading there, from
+> what I read. However, this is a danger if we start from option 1) and then
+> open wide the gates for importing packages, without setting a support
+> policy. 3) focus on both (this is my option). There would be 2 levels of
+> support : - top guaranteed support : those are the (few at start) packages
+> your can rely on almost blindly, they'll be updated in a timely manner,
+> and updates don't break things. Those are the packages the QA Team puts
+> its limited resources on (doesn't mean the QA Team provides the support
+> themselves, this is maintainer work, but they check that good support is
+> provided) : testing, helping the maintainers to watch for security
+> problems... The maintainers are responsible for their package, but the QA
+> Team double-checks updates for stable releases. - supported packages
+> (every other package) : those are maintained packages, however the QA Team
+> doesn't have to check them. It's up to the maintainer to check the package
+> and updates quality. - unsupported packages are dropped.
+> 
+> Are we heading for 1), 2), 3), or any other option ?
+> 
+> Of course, with unlimited resources, options 1 and 3 would be equivalent,
+> everything would have the "top guaranteed support" :)
+> 
+> Best regards
+> 
+> Samuel Verschelde
+> Packager/QA Team/User
+
+
+having read misc's lenghty and almost political proposal, i suggest a 4th 
+option (even though i'm not part of QAteam either):
+
+4) dynamically distributed focus:
+- level 1: BuildSystem-required packages (all packages used for buildnodes)
+- level 2: everything that is minimally required to boot and do stuff
+- level 3: popular server packages
+- level 4: release focus (everything that's defaultly installed by a release)
+- level 4b: stage images
+- level 5: the rest
+
+depending on resources and certain timings; focus should be spread according 
+to desires at that time.
+
+eg:
+- i imagine that level 1 could be discussed between sysadm and qateam during 
+BS-updates
+- i imagine that level 2 would be the primary focus
+- i imagine that level 4 could be more important during release times
+- i imagine that level 5 would probably not be focussed by QA unless unlimited 
+resources
+- i imagine that level 3 would probably be good if resources would be growing, 
+and possibly level 4 if there's enough resources.
+
+
+- i agree that testing should be open to anyone
+- i agree that karma could not be a bad idea, but suggest that QAteam give 
+more karma (perhaps even on the karmic state of that person)
+- i also would suggest that at the time of alpha release, we should do a 
+contest on testing and bugfinding; so that we could gather enough testers; and 
+possibly even extra packagers or qateam people.
+
+WDYT?
+