CJ Fearnley wrote: <snip>
So far, in summary, I see four classes of enterprise issues:
1. Getting new upstreams into Debian.
* Just (time consuming) work.
2. Packaging tools that are not in Debian (including locally developed
tools which implys becoming an upstream).
* Just (time consuming) work.
3. Bugs. Design flaws upstream. Patches. Sensitivity to versions, etc.
* The only solution that I can imagine for finding and fixing bugs
is just doing the work. With design flaws, it can get really hard.
* If site specific configuration management can't solve the issue,
it is a bug!
* I think much of the work needed is in bug triage and fixing design
issues upstream so the software can "just work" in more use cases.
Fortunately, there are now usually at least two FOSS upstreams
that can do any given thing. So if one upstream doesn't "get it",
we can work with another before we'd need to fork a new codebase
(which is what our local package archives really are).
I think getting more debian-enterprise people involved in these bugs may help. Would it make sense to tag such bugs with some kind of debian-enterprise tag?
4. Configuration management.
* I mean at the Debian packaging level primarily. But unless puppet
solves the problem for everyone (and I'm not yet convinced), there
is broader design work needed too.
* Another hard problem. More than "just work", as it requires
creative new ideas too!
Russ description of this server class packages made me immediately wonder why he wasn't using puppet for that. Perhaps that is what Standford were doing before they started using puppet, and have continued their practice.
Can you mention why you don't think puppet is the right solution? Clearly the defaults on any package will not suit every enterprise, and some customisation is required. Puppet can do that just as well as a vi session, or a local configuration package.
Thoughts?
-- +-Geoff Crompton +--Debian System Administrator +---Trinity College