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é
