> Hmm... sounds sensible. Unless somebody comes up with something better
> I'll start it in a week or so.
> My idea is to copy the full cvs tree of gimp to (lets call it gimpforge)
> and give any intersted plug-in author write access.
> Updates from the gimp-cvs-tree/{libgimp,app,tools...} to gimpforge should
> be automatic and regular, while updates in the other direction should be
> enabled for specific files (plug-ins/common/snoise.c) or subdirectories
> (e.g. plug-ins/perl).
> That will effectively implement some kind of access-model, and it will
> (hopefully) make it possible to *select* a fileset for distribution.

This all sounds nice, but I hope you are aware that once gimp-1.2 is out 
there will unlikely be another stable release (despite bug-fix releases 
of course) before gimp-2.0 and the plug-in interface for 2.0 will certainly
be incompatible with what he have now. 

I don't want to say that plugin development should stall until the
new interface has settled, but it would probably be a good idea to take 
this into account from the beginning and split the tree from ground up. 
This means having two branches (stable and devel) on the plugin CVS. That 
way we could throw all plug-ins out when work on 2.0 starts and include 
them later out of the 2.0 compatible plug-in branch. However I haven't 
thought much about this yet, is it a good idea ...?

I also want to point out that IMHO setting up a CVS server will not be 
enough. Ideally, this project should completely replace the registry. 
A web interface to the repository together with tips for installation 
will be essential. Plug-ins should be released on a regulary basis, 
since working with stuff out of CVS is not what our users want to do 
and it always buries the risk of checking stuff out that just doesn't 
work at the moment.

...just my 2 cents...

Salut, Sven

Reply via email to