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

[Tom Lord]

        > Red Hat's advertised business goals.

For example:

From: Tom Lord <lord@regexps.com>
To: rwa@alumni.princeton.edu
CC: arch-users@regexps.com
In-reply-to: <3D464D57.2030200@alumni.princeton.edu> (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))
 status)
Sender: arch-users-admin@regexps.com
X-BeenThere: arch-users@regexps.com
X-Mailman-Version: 2.0.9
Precedence: bulk
List-Help: <mailto:arch-users-request@regexps.com?subject=help>
List-Post: <mailto:arch-users@regexps.com>
List-Subscribe: <http://www.regexps.com/mailman/listinfo/arch-users>,
        <mailto:arch-users-request@regexps.com?subject=subscribe>
List-Id: a discussion list for users of arch <arch-users.regexps.com>
List-Unsubscribe: <http://www.regexps.com/mailman/listinfo/arch-users>,
        <mailto:arch-users-request@regexps.com?subject=unsubscribe>
List-Archive: <http://www.regexps.com/pipermail/arch-users/>
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 
significant 
       >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
common.

[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"]

-t
_______________________________________________
arch-users mailing list
arch-users@regexps.com
http://www.regexps.com/mailman/listinfo/arch-users