[Mageia-dev] Support policy

Thu Dec 2 13:30:35 CET 2010

Maarten Vanraes a écrit :
+>
+> 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 ?
+Hopefully for (3)
+>>
+>> 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?
+I like your "karma" :)
+>
+>
+Basicly, I see your option (4) as an elaboration of what I would expect 
+to be the supported part of Samuel's option (3)
+Which accords nicely with my view.
+
+My idea of core packages - to be formally supported as suggested in (3) 
+- would be those typically needed in a desktop or server or development 
+system, adding LibreOffice (OpenOffice) and Firefox as useful widely 
+used applications.
+Exactly what we support initially could start smaller, but that would be 
+my goal.
+
+And what is to be specifically supported should be decided by concensus.
+Note that I would prefer that core be relatively restricted, compared 
+with "main" - and eventually, as resources increase, informal QA support 
+could be extended beyond core, for more critical bugs, for example.
+Which is probably part of my preference for using "core" (officially 
+supported) and "extra" (others) groups of repositories for the mirrors.
+
+I'd like to see our first release (in April ?) be a fully usable system, 
+and not just a precursor to a distro that might eventually arrive.
+Which means that we will need a lot of auxiliary packages, not all of 
+which would be as fully tested as core packages should be.
+In other words, option (1) would not meet this goal.
+
+It seems a good idea to have only actively supported packages on the 
+first release.
+
+regards
+
+- André
+