Re: Decision about oot-modules for etch
Andreas Barth wrote:
> I don't see any release-team decisions required right now. :)
I beg to differ, see below.
> Basically, I tend to something like:
>
>> * Will be oot-modules in main outside of the linux-modules-extra be
>> removed by the release-team for etch?
>
> If there are fewer (source) packages to be rebuild in case of kernel abi
> changes, that's something good. If "all important" modules are there, we
> might consider to deprecate/disallow other packages to require to be
> rebuild in case of kernel changes. I don't really mind to make one
> exception for some package if there are good reasons; but if that means
> that 40 maintainers start jumping because their package should get the
> exception, that boils down to no exception. :)
That's the reason why I ask. I know about this "if 'all important'
modules are there, we might consider to deprecate/disallow other
packages" since the discussion with you on IRC end of june already.
It's way to uncertain to have still the same statement and I think, it's
late enough to nail that down, because if maintainers shall put their
packages together, they have know that now and start doing that now.
Can you make an announcement to all oot-module maintainers, telling them
that they should put their packages together into linux-modules-extra
(for main) or a similar one for contrib, and if they're not doing it,
they will end up in an unsupported (no updates for point-releases, no
updates for kernel ABI bump updates) package.
> As to allow new packages with build oot-modules: I'm not too sure if we
> should allow that, as every module makes a kernel update more
> complicated. But of course, you could try to convince us that ipw is
> important enough for that.
Let's get the generic thing above first, after that, depending on your
'decision', there is more specifically for ipw needed or not.
> Same for contrib: If there is no alternative to single packages, well,
> we need to use single packages. Also, how many packages in contrib
> generate oot-modules? If there are only 1 or 2, why bother?
I think it's less than 10.
> I don't see a reason to refuse upgrades during point release right now.
> If the oot-package with their own modules are updated, everything is
> fine. Updates during point release are more problematic with a
> conglomeration package, as all binary packages need to be rebuild,
> forcing users a (potentially) unneeded package upgrade. (Of course,
> there are the normal rules for stable updates as well.)
Ok.
--
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel.baumann@panthera-systems.net
Internet: http://people.panthera-systems.net/~daniel-baumann/
Reply to: