Fedora Core 5 Test 3 Slip

[Jeffrey C. Ollie]

On Tue, 2006-02-07 at 08:52 -0500, Dan Williams wrote:
> On Mon, 2006-02-06 at 16:05 -0500, Mike A. Harris wrote:
> > usage internally by individuals, and our next generation buildsystem
> > is aparently based on mock/plague.  What more exactly are you looking
> 
> Technically just mock.  There are some specific architectural
> differences, not to mention different target audiences, for the nextgen
> internal stuff versus plague.

>   For example, plague is meant to be
> distributed so that the builders and server don't have to be run by the
> same organization.  This means that RPMs and SRPMs are transferred with
> HTTP, because you can't rely on fast local shared storage.

Hmmm, perhaps that's the way that plague works now.  If the
buildsystem-ng server and the builder communicated using URLs, rather
than directly passing RPMs and SRPMs around, you could use "file://"
URLs to refer to centralized storage or "http://" URLs to refer to
remote servers.  A little bit of smarts would then allow the builders
and servers to avoid downloading via HTTP if they didn't have to.  That
would let buildsystem-ng handle both cases.

> The user model is also quite
> simplistic, while in an enterprise you'd usually hook this stuff up to a
> directory or other authentication means.

I'd agree that the *authorization* model of plague is simplistic, but
the use of X.509 certificates for *authentication* I would think is
quite good.

> Plague isn't meant as an enterprise build system, though it could be
> expanded to fill that role.  If it did, it would end up like Bugzilla;
> way to complicated to install over a weekend, and completely in need of
> a babysitter 6 out of 7 nights a week.

To me, systems like that usually indicate a failure in the planning and
design stage.

Now, I'm not saying that Red Hat should take the plague code as the base
for the new build system.  We should take the lessons learned from
plague and beehive and build a new, better build system that will serve
both the needs of Red Hat/Fedora Core and Fedora Extras (although not
necessarily on the same hardware).

Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060207/d0683bac/attachment.sig>