[Mageia-dev] Support policy

andre999 andr55 at laposte.net
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é


More information about the Mageia-dev mailing list