Re: This was posted on Digg.com -- Linux Distribution blog/article

[Jeff Licquia <jeff@licquia.org>]

On Fri, 2005-12-09 at 13:29 -0800, Bryan J. Smith wrote:
> Jeff Licquia <jeff@licquia.org> wrote:
> > I'm not convinced such departments exist in any quantity. 
> 
> Remember Munich?
> 
> The IBM-SuSE proposal won Linux over Microsoft's Windows
> proposal, but in the end, the city decided to go Debian. 

Right.  But Debian is a package-based distro, with its own QA processes
that Munich is leveraging.

> > Nor am I convinced that even a majority of the few which do
> > exist do what you describe.
> 
> I'm sure some tap IBM, Progeny or other consulting firms for
> some work.  But there are large departments that do their own
> regression testing, integration testing, deployments,
> configuration management, etc...
> 
> Heck, as a developer, I like to do prototype development on
> Gentoo first, because I'm swapping in and out all sorts of
> different versions of things.  Once I nail down a good set, I
> like to adopt the appropriate Fedora Core release that uses
> the versions, with Fedora Extras and 3rd party packages as
> needed.  Once regression and integration testing is complete,
> I find the most appropriate RHEL release and build any
> necessary packages that aren't included for it -- and that's
> what is builded as the development/run-time for the software.

Right.  But I note that you tend to abandon Gentoo fairly early in the
process.

> > Sure, all departments should have QA in some form.  But I
> > would be surprised to learn that the QA for the
> ports-distro
> > users is really all that better than the QA for the
> > package-distro users.
> 
> What is "better"?  How do you define "better"?

See the examples I gave in my other mail.  Do they test those things,
especially if those things don't directly impact their current use case?

My guess is that they don't, and that they only worry about those things
when problems actually show up.  This is a risky strategy to take unless
you can rely on someone else's testing, because fixing issues that come
up could require non-trivial changes to the base.

> If a company is not changing many of the packages included
> with the packages distro, then they can leverage all that
> mindshare and collective knowledge that goes into the
> packages distro -- especially if their needs are just what
> comes with an enterprise flavor that changes very little.
> 
> But if a company is changing many, many of the packages, and
> there is a great amount of conflicts, dependency hell and
> other, radical changes to the distro that not only impedes
> rollouts, but _negates_ the regression/integration testing
> that was done (because enough things are changed), then is it
> "better"?

Right.  My point is that no one, in fact, makes such radical changes as
to totally negate the previous testing.

> But now let's talk about niche configurations, the area where
> fewer and fewer people are using a similar configuration.  At
> some point the distro is changed enough that it's no longer a
> well trusted distro in its form.  So not only does the
> customization load incur cost, but there's reduced benefit
> because the integration has changed radically enough it has
> to be re-tested.
> 
> So sometimes it's "less work" and "better" to start with the
> custom base you need -- be it from Debian or Fedora project,
> or maybe a ports distro like Gentoo -- and then put all the
> efforts towards regression, integration and other testing, as
> well as roll-out and a custom configuration management
> approach.  Gentoo was basically designed to lessen the
> administrative headaches of this burden than Linux From
> Scratch (LFS), so people could focus more on the testing and
> management aspects (instead of just being happy they could
> get it to build and stopping there).

Oh!  If you're interpreting my criticism as aimed at Debian or Fedora,
then no, you're right there.  Both are very popular as customization
starting points, and for good reason.

I am solely focused on the ports-vs-packages thing.  If Gentoo's goal,
as you describe it, includes adoption by commercial customizers, then
they have largely failed at that goal.

> > More likely, they just have a hole in their QA, and they
> > likely suffer for it.
> 
> Again, depends on what you need to do to a stock packages
> distro to get it to do what you want.  If not much, of
> course, I agree with you!  But if it's a radical mod, then
> no, it's likely to negate all the mindshare already done,
> while impeding the customization.

What do you call a "radical mod"?  And how radical does it have to be to
negate the distro's advantages in integration testing?

> > Not that departments don't exist with the capabilities to
> > do this, or that organizations in general never test.  But
> > building and maintaining a distribution is hard work.
> 
> A distribution for _who_?

A distribution for anyone.

> I agree, maintaining your own distro for _others_ is
> difficult.  But maintaining a distro for your _own_,
> _internal_ organization is sometimes _better_ the farther
> your needs are from the general.  You understand your
> business better than others, especially the more it is not
> commonly addressed.

I must respectfully disagree here.  Maintaining a distro properly is
hard work for anyone, for any purpose.

A lot of people maintain a distro poorly.  But that's exactly my point:
very few organizations have the resources or experience to do the job
right, and nearly all of them recognize this.

> > I don't see how it's possible to justify the cost of that
> > work unless you're one of a very small number of
> > organizations whose whole business derives from that kind
> > of work.
> 
> I can.  It's not common, but it does exist.
> 
> There are just some situations where Gentoo makes far more
> sense than Debian, Fedora or RHEL.  Especially development. 
> Especially very customized web/Internet services where you're
> replacing the entire Apache stack anyway.

Replacing the entire Apache stack is trivial, as distro customization
goes.  In fact, Progeny is building a do-it-yourself toolkit for just
such a thing.  Nothing about replacement of the Apache stack has an
impact on bootup, service management, utility availability, kernel-libc
compatibility, hardware detection, driver support, library ABI
compatibility, etc.  Heck, you can even keep LSB certification across
the change.

And if you're not testing all those other things (or relying on someone
else's testing of all those other things), you're not doing a good job
of maintaining a distro.


-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.