Re: speculations to characterize issues for Debian Enterprise
CJ Fearnley <cjf@CJFearnley.com> writes:
> 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.
Agreed on both of these, with the additional note that in some cases
Debian doesn't have support for a whole class of packages (such as, right
now, Java webapps) and so more fundamental work needs to be done in Debian
to sort out how such things should be packaged.
I'm personally going to be working on the Java webapp problem over the
next six months or so, hopefully.
> 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.
One place that we can potentially help provide guidance other than just
fixing bugs is to recommend particular implementations, when there are
several that do the same thing, which are well-done for Debian and which
work well for enterprises. But when there's only one major implementation
of something, we indeed just have to do the work to try to get the bugs
fixed.
This is where some form of collective action by identifying enterprise
bugs that people can try to work on may help.
> * If site specific configuration management can't solve the issue,
> it is a bug!
It might be useful to write up guidelines for how to design packages and
software so that they work well in enterprise environments. Things like
the rule that any configuration file should support including a directory
of config file fragments.
> * 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).
Ah, yes, I see you had the same idea as I did above. :)
> 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!
This is another place where best practices documentation might be useful
in areas like how to manage Debian configuration files, how to build local
packages, and so forth.
One of the big takeaways I got from DebConf is that we need lots more
documentation in this area. A lot of the facilities are there, but people
don't know about them or how to use them coherently.
I'm not going to have time to help with things like Blends, at least in
the near future, but I'm going to try to pursue getting more of our
documentation publicly available and will be working on packaging Java
applications.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: