diff options
Diffstat (limited to 'zarb-ml/mageia-dev/attachments/20101201/1604e755/attachment.html')
| -rw-r--r-- | zarb-ml/mageia-dev/attachments/20101201/1604e755/attachment.html | 75 |
1 files changed, 75 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/attachments/20101201/1604e755/attachment.html b/zarb-ml/mageia-dev/attachments/20101201/1604e755/attachment.html new file mode 100644 index 000000000..ac501300a --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101201/1604e755/attachment.html @@ -0,0 +1,75 @@ +<br><br><div class="gmail_quote">2010/12/1 Maarten Vanraes <span dir="ltr"><<a href="mailto:maarten.vanraes@gmail.com">maarten.vanraes@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +Op dinsdag 30 november 2010 13:31:08 schreef Samuel Verschelde:<br> +> Hi,<br> +><br> +> I would like to discuss the support policy for Mageia.<br> +><br> +> It would be interesting to know (or decide) where Mageia is heading, given<br> +> our limited resources : 1) focus on stability and security : few very well<br> +> equally supported packages. Apparently, this is where we're going for now.<br> +> May be wise as a start, but I hope this is not our final destination,<br> +> because it means either very limited choice, or progressive diminution of<br> +> quality of support if the number of packages increases faster than the<br> +> dedicated resources. 2) focus on choice : many packages, but no support<br> +> policy. This would be really bad, I think we're not heading there, from<br> +> what I read. However, this is a danger if we start from option 1) and then<br> +> open wide the gates for importing packages, without setting a support<br> +> policy. 3) focus on both (this is my option). There would be 2 levels of<br> +> support : - top guaranteed support : those are the (few at start) packages<br> +> your can rely on almost blindly, they'll be updated in a timely manner,<br> +> and updates don't break things. Those are the packages the QA Team puts<br> +> its limited resources on (doesn't mean the QA Team provides the support<br> +> themselves, this is maintainer work, but they check that good support is<br> +> provided) : testing, helping the maintainers to watch for security<br> +> problems... The maintainers are responsible for their package, but the QA<br> +> Team double-checks updates for stable releases. - supported packages<br> +> (every other package) : those are maintained packages, however the QA Team<br> +> doesn't have to check them. It's up to the maintainer to check the package<br> +> and updates quality. - unsupported packages are dropped.<br> +><br> +> Are we heading for 1), 2), 3), or any other option ?<br> +><br> +> Of course, with unlimited resources, options 1 and 3 would be equivalent,<br> +> everything would have the "top guaranteed support" :)<br> +><br> +> Best regards<br> +><br> +> Samuel Verschelde<br> +> Packager/QA Team/User<br> +<br> +<br> +having read misc's lenghty and almost political proposal, i suggest a 4th<br> +option (even though i'm not part of QAteam either):<br> +<br> +4) dynamically distributed focus:<br> +- level 1: BuildSystem-required packages (all packages used for buildnodes)<br> +- level 2: everything that is minimally required to boot and do stuff<br> +- level 3: popular server packages<br> +- level 4: release focus (everything that's defaultly installed by a release)<br> +- level 4b: stage images<br> +- level 5: the rest<br> +<br> +depending on resources and certain timings; focus should be spread according<br> +to desires at that time.<br> +<br> +eg:<br> +- i imagine that level 1 could be discussed between sysadm and qateam during<br> +BS-updates<br> +- i imagine that level 2 would be the primary focus<br> +- i imagine that level 4 could be more important during release times<br> +- i imagine that level 5 would probably not be focussed by QA unless unlimited<br> +resources<br> +- i imagine that level 3 would probably be good if resources would be growing,<br> +and possibly level 4 if there's enough resources.<br> +<br> +<br> +- i agree that testing should be open to anyone<br> +- i agree that karma could not be a bad idea, but suggest that QAteam give<br> +more karma (perhaps even on the karmic state of that person)<br> +- i also would suggest that at the time of alpha release, we should do a<br> +contest on testing and bugfinding; so that we could gather enough testers; and<br> +possibly even extra packagers or qateam people.<br> +<br> +WDYT?<br> +</blockquote></div><br><br clear="all">Option 4 sounds good, it also shows a little bit the responsibilities of each team.<br>I would like to add a level 3b which differs between server-only and desktop.<br><br><br>-- <br> +Mit freundlichen Grüßen<br><br>Greetings<br><br>Daniel Kreuter<br><br><br><br> |