2010/12/1 Maarten Vanraes <maarten.vanr...@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