Re: Announcing new Distribution
(completely biased *own* opinion as an aptosid-teammember,
so my own "fellows" might disagree at some point with me;
I will not comment on siduction, but I assume they have similar
or at least plan to have similar workflow and/or problems)
On Sat, Sep 17, 2011 at 23:20, Paul Wise <pabs@debian.org> wrote:
> I'd like to encourage you to propose sponsored NMUs (non-maintainer
> uploads) for fixes where they are needed for your users and follow
> normal Debian procedure (sponsored uploads) for packages not yet in
> Debian.
For hot fixes, this is complicated. Either these fixes are in the pipeline
for debian already and just missed the last dinstall run/mirror sync, they
are not really bugs in the package but cause problems in unstable
(e.g. remember udev's conf-file transition to *.conf ending. This emitted
millions of warnings at boot up causing a delayed boot or even not booting
of some systems properly due to some race conditions of other initscripts)
or they are critical for us but "only" minor for debian as e.g. #633880.
The fourth category in fix.main are some packages we have some sort of
direct involvement in the packaging in debian proper and give it an early
testing spin if needed/possible/wished before it is sponsored.
Just to proof my point at present 3 packages are in fix.main:
mdadm as cat3 and iw and wpasupplicant as cat4
For "own" packages we either (co-)maintain them already in debian/upstream or
we are upstream for them in case of artwork, specialized installer or some
scripts which are enough for us in their current form, but not for debian:
ceni (your network manager) for example is mostly mentioned in this context:
It doesn't support ipv6 currently, so with an upload we would actively work
against a longstanding debian release goal… Sounds like a great idea.
The same is true for openfwwf firmware - I have a special interest in it as my
laptop has a b43 card, but I can fully understand that Stefan stepped back
from the ITP. I personally wouldn't have the balls to maintain a firmware
package in debian which seems to be death upstream and isn't recommend by
b43 kernelmodul maintainers as I can't support it…
Other packages have similar backstories, so while the easy theory says
"that should all be in debian" the practices isn't all that easy.
But I am sure other derivatives have the same "Given unlimited manpower,
we could…" problems.
> Could you also say something about the aptosid/siduction Linux kernel
> images, how are they different to the ones produced by the Debian
> Linux kernel team?
Stefan follows kernel upstream damn close which means that usual on
release day we have the new kernel release properly together with the first
bunch of stable-query patches. The packaging itself is based on the debian
kernel. The only real difference is the focus on "recent" desktop/laptop
machines and therefore an optimized kernel-config for this target-audience.
As you can already see in the mentioned mdadm bug above, kernel wise
we are usually ahead of anybody else, so that users which heavily depend
on non-free blobs for e.g. their graphic card aren't always that pleased.
Not that we would actively work against these blobs, but it's fair to say that
there is no time invested to make them work and upcoming changes aren't
held back just because they break them (as e.g. big-kernel-lock-removal
or '3.0' as versionnumber…) -- properly mostly caused by the fact that
we either doesn't own most of this hardware or are satisfied by free drivers
(and/or are testing stuff for upstream and ourself; as livecd is free-only).
This is obviously a constant "hot topic", but also different topic…
All in all, and at this point our fork (that sounds so strange…) might
disagree, I think while the cooperation isn't that visible because we
don't tag everything to mark that we were here or there, we do a good job
in general.
We could always be better of course, but I personally don't think that adding
"this patch is provided to you by a member of the aptosid-team" is really a
step in the right direction. At least I never thought that my work on APT
would be work I do while I wear my aptosid hat. And I am pretty sure the rest
of the team agrees at least on that point with me in regards of their own
"sideprojects" and bugreports.
In fact, in a release model like aptosid in which you use basically debian
unstable with the addition of a very small overlay provided by aptosid you
are basically "forced" to work directly with upstream (be it debian or
"up-upsteam") if you don't want to work more than you need to as you have
to support the overlay alone while everything outside the overlay is already
supported "for free" by upstream…
So, not wearing the hat is good and an implicit goal (at least for me).
Beside, and that is something Ferdinand already mentioned, and while it
slowly changes, it's quiet a difference if I say I use 'debian unstable' or
'aptosid' even through technical the difference isn't so big; but I guess
every derivative has this problem in some way and I get the same look at
times then I talk to ubuntu/arch/gentoo/… people and say I would use debian.
So it must be some sort of "you are not in my team, so you must be the enemy"
thinking - and this frontdesk is a good way to work on that,
because (as I am an asterix fan) "We are one people" :)
Best regards
David Kalnischkies
P.S.: Again, my personal opinion, no press team involved to write that;
Sorry for the long mail without a tl;dr version and note that I am
subscribed to d-deriv so no cc for me please.
Reply to: