Keep broken code in releasetarball (was: [GRASS5] Branching for 5.0.0 ahead)

[Bernhard Reiter]

Several people seem to favour to keep old or broken code
in the release tar ball and disable the build for it.
Then this will be the case for the 5.0.0 release.

I do not fully buy into the arguments,
but if most people think that it is worth keeping, we keep it.

Some arguments for the sake of arguments are following: :)

On Mon, Apr 22, 2002 at 07:38:06PM +0200, Markus Neteler wrote:
> 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:

> 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

This is all a matter of organising this right.

> 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.

For me this arguments works the other ways round:
	If everybody know that more code can be obtained,
	they will go and search for it. 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 248 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20020422/9833beee/attachment.bin