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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
