[Mageia-dev] How will be the realese cycle?

Ahmad Samir ahmadsamir3891 at gmail.com
Tue Oct 5 20:17:25 CEST 2010


On 5 October 2010 19:53, Tux 99 <tux99-mga at uridium.org> wrote:
> On Tue, 5 Oct 2010, Ahmad Samir wrote:
>
>> I looked at the description that Michael gave. And I think I know what
>> a rolling distro is having Cooker and all :). light/heavy makes no
>> sense here.
>
> I give up, i'm not sure if it's a communication problem or if you are
> simply pretending not to understand to wind us up.
>

Well, according to you I don't understand what you're saying, and also
Michael doesn't understand what you're saying, but maybe it's
coincidence?

I can only speak for myself though, IMHO, a rolling distro model
wouldn't work well in Mageia. It'll mean more work for packagers and
instead of packagers
concentrating/working-more/giving-more-of-their-free-time before a
release is pushed to polish their packages / fix critical bugs in
them, the workload will increase throughout the whole year, because
new versions are released all the time by upstream.

>> It's not I'll-work-my-own-way-and-do-what-I-want, any packager can do
>> so in his own repo/distro. There'll be rules which should be followed
>> even in a community-driven distro, otherwise it'll be chaos.
>
> Sure, guidelines on how to package, but not on what particular package a
> specific packager has to package otherwise it wouldn't be a fun project
> but rather unpaid drudge work.
>
>

I was mainly talking about major version upgrades in stable releases,
whether they go to backports or updates, that'll be according to the
policy the project leaders agree on. Packaging policies should always
be used, to maintain the quality of the packages in the distro.

FWIW the argument that a rolling distro will cause less mirror size is
a bit wrong, main/updates + main/backports are always much smaller
than main/release, the same goes for contrib (though contrib/release
is bigger than all other repos put together).

-- 
Ahmad Samir


More information about the Mageia-dev mailing list