[GRASS5] Branching for 5.0.0 ahead

[Markus Neteler]

On Mon, Apr 22, 2002 at 02:53:08PM +0200, Bernhard Reiter wrote:
> On Mon, Apr 22, 2002 at 01:41:33PM +0100, Glynn Clements wrote:
> > Bernhard Reiter wrote:
> > 
> > > You both have to make sure that the release branch only contains
> > > useful code we want to release and that you know is stable.
> > 
> > I suggest that:
> > 
> > 1. Code which is permanently dead (e.g. because it has been
> > superseded) should be removed from the trunk first.
> 
> Please go ahead.
> 
> > 2. Code which is currently broken, but which might reasonably be
> > resurrected in the future, should be disabled (in
> > src/CMD/lists/GRASS), but included in the source tarballs.
> 
> We will not fix bugs on it, thus I'm not sure if it should 
> belong in the release branch. I'm pretty sure that it should not
> go into the tarballs.
> 
> We can have another tar ball, like grass5.0.0-brokencode.tar.gz.
> Even better would be a tarball of this from the dev cvs.

I strongly recommend to keep even (currently) broken code in the
source tarball for some reasons:

 - too much work to maintain another tarball
 - keep barriers low to access source code
 - keep code in one place, makes borrowing from other code more easy
   as if the code is spreaded elsewhere

We have the src/CMD/lists/GRASS list which is working fine for
decades. I do not suggest to keep it forever, but for 5.0. And
from that list it is easy to retrieve the code which is considered
to be functional.

> > The reasoning behind 2 is that a user who wants the program, and who
> > has downloaded source code rather than binaries, might be inclined to
> > have a go at getting the program working. 
> 
> > Having to retrieve the code
> > from CVS might prove too much of an obstacle (particularly for users
> > who can't use CVS due to a firewall).
> 
> In reality I do not believe that someone who will try to make a
> broken source code run will find this a major obstable.
> Additional tarballs would archieve both:
> A cleaner separation and easy access to the source code of buggy modules.

I am not sure we the additional workload is more that what could be gained
from a separation. An example:
Some time ago I created a src.todo, also there is a notyetuploaded/ in
grass51/. These directories are as dead a possible (although interesting code is
there). They are just out of view. That's why we should not change the
method now just for cosmetics reasons.

Markus