Jaroslav Reznik wrote:
Hi.
I became new maintainer for s-c-netboot and I
have found this interesting mailing list. It
seems we are doing same thing but in different
way. S-c-netboot is quite old now and needs
some serious work and the question is develop
it alone or use some parts of your work. And
seems same for Stateless Fedora project. The
best way I think is to use what is already done,
work together, s-c-netboot can act as (G)UI for
Stateless Fedora/RHEL project.
With beginning of system configuration management
project (PolicyKit etc.) we can have independent
backend for users to access stateless configuration
etc.
I've already read old thread "s-c-netboot vs..."
but it's quite old now...
So what do you think? ;-)
---
Jaroslav Reznik <[EMAIL PROTECTED]>
Software Engineer - Base OS Core Services Brno
Red Hat, Inc.
+420 532 294 275
_______________________________________________
Stateless-list mailing list
[email protected]
http://www.redhat.com/mailman/listinfo/stateless-list
In all fairness, system-config-netboot has largely become irrelevant.
While I have questions as to how active this list/effort actually is,
any new efforts around stateless, if any, /should/ be rallying around
one provisioning tool, not two or three. Applications like genome,
ovirt, and spacewalk have all picked up cobbler as that future
direction. Stateless was also using cobbler. To be investing in
system-config-netboot seems to be a step in the opposite direction -- it
lacks many of the features added to cobbler, it lacks the error
handling, and it is still using GTK instead of a webapp for it's
interface. In adding all this, you move towards cloning cobbler, when
you could instead contribute to that codebase.
Let's instead talk about what you need in cobbler that isn't there, and
contribute to one common codebase. I think that's a better route.
--Michael
_______________________________________________
Stateless-list mailing list
[email protected]
http://www.redhat.com/mailman/listinfo/stateless-list
