Re: Why Unanimous Consent Doesn't Work (Was: Re: why do we need change?)

[Nicola Pero]

> Actually, this is exactly the problem.  This is how proposing something
> on the GNUstep lists works:
> 
> 1. Email the list.
> 2. Get some decent replies, including some sensible ones from core
>    developers and the like.
> 3. Crap ensues.  Cover your head, it is coming down fast now!
> 4. Anybody with any say over the original proposal stops reading because
>    the entire thread has become a flaming pile of poo. (And not that I
>    necessarily blame them)
> 5. The end.

Usually the sensible replies are the ones that matter, aren't they ? ;-)

I'd recommend evaluating the value of each email -- open discussions on
mailing lists do tend to contain crap emails.  The crap emails are often
worth very little though.

[I suppose you're thinking of the CVS vs SVN discussion, which, well, I
see what you mean ;-)].

Also, most of the times it is the lack of time that stops things from
happening. :-(


> See the problem?  Anytime something becomes controversial, there is no
> final say.  Alex is merely saying that all it would take is a leader to
> take a Linux-Torvalds-Dictator-Like-Approach and say either:
> 
>   That's a dumb idea, it isn't going to fly. <end of discussion>
> 
> or:
> 
>   Quit your whining, this has some merits, I have questions about this
>   and this.  <discussion moves towards an end>
> 

My impression is that there is definitely a final say - certainly on every
development matter that has to do with my bit (gnustep-make) at the end of
each thread I'm extremely clear in my mind on what is good and what is bad
(IMO) and what will get done and what will not get done. ;-)

I thought it was mostly clear to everyone else too ... Just in case there
are people that are unclear on what the direction of gnustep-make is ...

The current objectives of gnustep-make developments in the next months /
half a year are:

 * Simpler, easier configuration with less steps/machinery to be setup

 * Better native integration on Unix

 * Better Windows support and better native Windows integration


The strategy for achieving this is:

 * we are switching to a system where all the paths / filesystem structure
are stored in configuration files (GNUstep.conf).  The great advantages we
expect from the change are:

     - it will be possible to use GNUstep apps without sourcing GNUstep.sh
before using them

     - it will be possible to use gnustep-make without sourcing GNUstep.sh
before using it; only setting the GNUSTEP_MAKEFILES environment variable
will be required

     - FHS paths will be cleanly supported

     - it will be possible to integrate cleanly with native filesystems,
existing and future

     - there are plans to be able to ship a config file with the
application itself so that, eg, on Windows it will be possible to have a
self-contained GNUstep binary application that can be downloaded and
launched from its own directory without the need to install anything else

     - it will be easier to relocate GNUstep on disk by just changing the
config file (could be done automatically by installers)

     - it will be easier to configure the GNUstep paths to suit different
distributions / directories / tastes

     - we should still be able to support the whole (wide) range of
different options that we currently support


More in detail, the changes will include (some of those are already done
or in the making):

 * all config to be stored in GNUstep.conf in sh format

 * the full config system has to be designed and thought of and
implemented

 * the config system to be fully documented

 * GNUstep.sh / GNUstep.csh to read the config from there (GNUstep.sh will
still be available for some corner cases that most people need not bother
about but I need to)

 * The makefiles to read the config from there

 * The ./configure scripts to read the config from there

 * gnustep-base needs to read the config from there

 * The config system to be extended to support setting not only the root
paths, but all the specific application / libraries / etc paths

 * The config system to be extended with special arrangements to support
config files stored with an application binary (particularly for Windows)

 * The config system to be revised to make sure it fits auto-builders,
package generators, etc.

 * The config system to be revised and tested on various systems to make
sure it all makes sense


The other lines of development in gnustep-make are about:

 * general maintenance

 * better support for Windows, including framework support for Windows
(patches pending from Jeremy, my fault for not having found the time to
study and apply them yet) ... and potentially some sort of auto-packaging
of Windows applications if I ever get the time to study that matter
[this second is unlikely]

 * [potentially] dropping the debug vs. non-debug libraries and support a
single version of all libraries installed.  This would bring a
considerable simplification and probably save the users quite a lot of
trouble in cases of conflicting libraries.  This will be unpopular with a
few minority but after lot of thinking, it seems like the right way to go. 

 * [potentially] integrating Helge Hess's patches for pre-compiled
headers. [Subject to myself having the time to do it]


This is what will happen in this area in the next, say, 3 to 6 months.


PS: Whoever is setting up a general roadmap or whatever, feel free to copy 
my bit on gnustep-make on there.


> Maybe nothing needs to be quite this extreme, but right now GNUstep is
> not majority rule, it is minority rule.  You get a few people to raise a
> stink about anything that might benefit GNUstep and the thread gets
> ignored for eternity by anybody that matters.

Ahm - in case anyone feels they had some intelligent points about
gnustep-make that have been ignored for eternity due to flamewars on
public mailing lists, please email me privately to remind me about them.

Thanks