[GRASS5] Branching for 5.0.0 ahead

[Helena]

Bernhard

on the item 2 I really agree with Glynn - For example, there were few times
when we
wanted to look at the 3D stuff and could not find the code  - by the time I
got it separately
from Markus I did not have time to look at it anymore. Many people just would
not go through
the hassle of dowloading extra software to fix the code. Essentially when
somebody
is looking at some functionality, finds it in manuals or knows about it , but
it is not compiled but the code is there
it may take just few hours or days to fix it. It is the time needed to figure
out where that code
is located that is the biggest obstacle.

Helena


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.
>
> > 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.
>
>         Bernhard
>
>   ------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature