Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 04:42:29PM -0500, Ian Murdock wrote:
> On Thu, 2004-12-09 at 15:10 -0500, Daniel Jacobowitz wrote:
> > As one of the maintainers involved in Debian's toolchain, I think this
> > is a terrible idea. Our needs are different than other distributions,
> > we already know that from experience. The core needs are conceptually
> > the same - everyone needs working libraries and tools - but the details
> > we consider worth fixing are not.
>
> Can you provide examples? I'm not trying to be dense--I'm simply
> trying to understand what, if anything, is so irreconcilable, as
> some of you seem to be suggesting is the case here.
I'll try. My first concern is the architectures issue. Bruce made a
comment along the lines of "LCC would have to accept patches for
architectures it didn't care about, but would not be required to build
them". But it's not that simple; there are always tradeoffs. Some of
the issues are rate of change (esp. w.r.t. release schedules),
modifications to common code, and increased pressure on patch
review/approval.
Debian has a different set of use cases than most Linux distributions.
The first example that comes to mind is in-place upgrading, and some
packages have horrible hacks in them to support this. Other LCC
members might reasonably object to the baggage.
> > So during the sarge release
> > cycle, when we need to make updates to fix an RC bug in glibc that
> > doesn't affect any platform shipped by any other member of the LCC,
> > which has moved on to new development according to some other member's
> > release schedule, what would we do? We'd have to rebuild them anyway.
> > There goes our "common binaries" advantage.
> >
> > >From the web site, I see that LCC has a limited set of architectures
> > targeted anyway. Debian will continue to use common source for all
> > architectures. That will make working with the LCC difficult.
>
> First, because the four founding members are commercial entities,
> we're mainly interested in the architectures that are predominant
> in commercial environments. That's all about aligning resources
> with relative priorities and certainly isn't a statement that we
> will never support anything else. If resources and priorities
> change, the set of supported architectures could change as well.
Of course. I understand the point of supporting commercially viable
architectures; Debian is the alternate extreme.
> Second, the common core will have a release schedule corresponding to
> the release schedule of the LSB standard (roughly every 12-18 months),
> and the members' release schedules will be synchronized to match that.
Precisely. You've signed Debian up for "externally" (quotes, because
we would be participants, but there will be strong external pressures)
managed schedules for dozens of core packages. And some external
pressure on overall release schedule, because of the sharp dropoff in
staleness.
For example, suppose GNOME is part of this managed set. The other
members, primarily commercial distributions with greater control over
their schedules than Debian has, want to wait off on upgrading to GNOME
3.4 until their next release cycle. Debian is going to be releasing in
three months and two dozen active GNOME developers are heartbroken by
the idea.
It's not an idle example - that happened for this release cycle. Heroic
effort on the part of both GNOME maintainers and release managers got
it in under the wire, and it will make an IMHO big difference to the
out-of-the-box usability of sarge.
Right now, if you have a brilliant idea that you want to implement and
integrate all through Debian, there's a clear set of the relevant
maintainers to convince. Expanding that set to include lots more
people, and people with sharply different needs and pressures, is not
something I consider good for the future of Debian. The reason I am a
Debian developer is because Debian is responsive to my needs; it's
(relatively speaking) easily swayed onto a better course when one
presents itself. As long as there's someone willing to do the work,
the work can be done.
Also, the multiple-architectures issue is a big one for the imposed
schedules. Architectures that only Debian, out of all the LCC members,
cares about will be only lightly tested by the time any given LCC
release is made. I estimate a dozen or more substantial changes to any
"released" packages before Debian could use them, taking many months to
come together.
> > Using binaries from LCC would also run against the Debian principle of
> > always building Debian packages from their source before uploading
> > them. That's a big deal.
>
> I'm not sure I follow--we all have to build packages from source, and
> the LCC will be no different, so where's the problem exactly?
Autobuilders.
Security updates.
Build testing in Debian environments.
None of this is new...
> > We would never have a common kernel with these vendors anyway - they
> > don't even have a common kernel with each other. My experience tells
> > me that would be a big barrier to certification of any kind.
>
> The LCC core will include a common kernel.
This would have been a good thing to mention in the first place ;-)
That's nice news, though I wonder how feasible it will be. Especially
for a common source base.
I also don't like the all-or-nothing feel of this. Debian developers
maintaining any of the affected packages (I haven't got a good feeling
for how many that is, yet) would be forced to work with LCC to maintain
any control over their packages.
In short, I don't think the structure that you've described is a
feasable one for Debian.
--
Daniel Jacobowitz
Reply to: