[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [arch-users] Re: very old thread and the problems

From: Tom Lord
Subject: Re: [arch-users] Re: very old thread and the problems
Date: Fri, 9 Aug 2002 19:46:46 -0700 (PDT)

        > Red Hat's advertised business goals.

For example:

From: Tom Lord <>
In-reply-to: <> (message from Robert W
        Anderson on Tue, 30 Jul 2002 01:24:55 -0700)
Subject: what arch can do for enterprise IT (was Re: [arch-users] Re: 
[arch-dev] advice sought (really: fundraiser))
X-Mailman-Version: 2.0.9
Precedence: bulk
List-Help: <>
List-Post: <>
List-Subscribe: <>,
List-Id: a discussion list for users of arch <>
List-Unsubscribe: <>,
List-Archive: <>
Date: Tue, 30 Jul 2002 09:07:31 -0700 (PDT)
X-UIDL: +;N"!/ZA!!c]7"!YBS!!

       >>If Joe Schmoe wants his own fork of Linux, who are you to say that it
       >>isn't worth the trouble?

       >I'm not - but now we're back to my original observation that 
       >branches don't merge in the real world.  

[Incidentally, I think you're thinking mostly about "project forks"
 which aren't the same thing as "SCM branches", although people use
 branches as a way to implement forks sometimes.]

I think it makes sense to reach a situation where enterprise IT no
longer "buys sourceware" -- "sourceware" being some set of binary
products and related services that *in theory* have all the source
available somewhere, if you ask nicely, within 3 years, and don't mind
reading a lot of "INSTALL" files to get everything compiled.

Instead: enterprise IT should be buying source-based distributions and
ready-made, perhaps customized source->local-deployment release
engineering pipelines.  They should always be ready to
recompile/retest/redploy all of the code in their local installation
-- essentially with the push of a button.  There are many reasons why
this is arguably a better approach than what we see today: but aren't
they obvious to most engineering-types without a tedious diatribte?

In such a circumstance, with more IT departments all set up as nicely
configured "edge nodes" of the open source world, I think peer-2-peer
and intra-alliance patch-swapping/merging are likely to be more

[arch isn't *only* for enterprise IT;  orthogonal to the above, it
 does a lot for regular-old-developers, too -- this was simply
 one illustration of why "distributed branches != forks" and
 "merging is useful"]

arch-users mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]