Re: [Config4gnu-developer] important negatives to adress ASAP

[<p.c...@ar...>]

Hi,

I think the feedback gave a valuable insight into how CFG in perceived. Some
things have to be dealt with coding some with information. I can't code
but I can start a wiki page on freedesktop.org end of next month. I can
adress some points, but for other things I would need some base for a
start.

A good idea I saw at the skolelinux project is to schedule a
development weekend. It showed ppl realy like to hook up and work
together even meet if possible rather than just kind of
lonely, individually.

Planning a weekend aiming for a test-suite release, some examples,
and basic notes on how to add support (meta-data) for more apps can be a
good idea. (Maybe additionally providing staticaly linked binaries for
easy testing  might be a viable workaround for the moment as long as
some depreciated dependencies can't be removed)

 
> 1) Incomplete, the framework appears to exist but without backends and
>  support for the things that need to do right, it's not very helpful.

=> Testing release with a meta-data directory standard for additions,
plus an initial quick guide how to support additional apps? (Also
continous collaboration of testers and users on improving that guide
on the wiki and documenting experiences.)


RFC on the following points. Are they just not perceived right? What is
actually already solved in CFG?

> 2) Development seems to have stopped or slowed considerably.
> 
> 3) Yet another dependency.
> 
> 4) There is more to configuring a running system than just editing config
> files. What about starting/stopping daemons? Creating and clean up of user
> accounts? querying the status of services?
> 
> 5) The real work is not parsing of writing files, it is doing all the
> little
> jobs like finding out where exactly each distro stores their network config
> for example and in what format. See point 1).
> 
> and finally:
> 
> 6) I can't imagine that hacking on a new framework/code base written in C
> and
> Perl, and then trying to get everything working across 3 different
> languages
> is going to be faster or easier than just continuing to code in Python.