[Mageia-dev] Support policy

Wed Dec 1 09:42:18 CET 2010

2010/12/1 Maarten Vanraes <maarten.vanraes at gmail.com>
+
+> 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?
+>
+
+
+Option 4 sounds good, it also shows a little bit the responsibilities of
+each team.
+I would like to add a level 3b which differs between server-only and
+desktop.
+
+
+-- 
+Mit freundlichen Grüßen
+
+Greetings
+
+Daniel Kreuter
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20101201/1604e755/attachment-0001.html>
+