[GRASS5] The status of 5.0

[Bernhard Reiter]

On Mon, Mar 25, 2002 at 11:36:43AM +0100, Radim Blazek wrote:
> On Friday 22 March 2002 05:12 pm, Bernhard Reiter wrote:

> > Because we have a small team, we need proper version control.

> Depends on character of contributors. If we had few, but full time
> job programers, then maybe branches would be usefull, but if we have
> contributors who can spend only little part of their time on GRASS, 
> branches are confusing and a lot of extra work. 

The less time you have to contribute, the better the structure has
to be. Branches can significantly add to this structure.

> Because of that GRASS development system must be simple and transparent 
> instead of complex and hard to understand.

Using CVs or branches is basically a matter of how the core
developers help you with documents or practical advise on how to use it.
It is not a complex thing.

On the other hand, if we allow non structured changes to 
the huge code base we have, we neve be able to follow any plans.
Unless we have full time massive efforts to join the scattered hacks again.

> But we have our experience with branches in GRASS, after one year
> of fighting with branches we have again one branch merged - 
> I dont se any advantages.

One person would have had the fact to point people in directions.
We led the release branch rot, this should not happen again.

Additionally One year is not enough to bring in good branch handling.
Developers learned a lot.

> 1. I commited new code v.out.shape (points, attributes) to MAIN
> 2. Glynn, while merging branches found that it is impossible merge
>    stable and MAIN branch (of course, versions are very different)

You mean the release branch.

> 3. Glynn, tagged my code, and replaced by version from release branch
>     (OK, because it was not tested well and cannot go to release)

This was because of the previous mistake that we led people work on
the release branch without restricting work to critical bugs
and reminding people the that release branch will be partly thrown away.
I'm very thankful that Glynn took up the torch and dug through that.

> 4. I found that my code was deleted, so I was annoyed and discouraged
>     to contribute new code, if I know that it will be deleted on first
>     occasion.

The code is still in CVS. Thus not deleted at all.
If you cannot explain Glynn why your code is an improvement it might not
be good in the GRASS5 tree. Also you learn the lesson that you have
to coordinate with other developers before commiting.

> => results:
> - Glynn and I spend extra time

It might be necessary sometimes.
We will find way to inform the other developer why we've made some
code changes. Obviously Glynn and others did not know enough about
your changes.

> - new code is not available (easily)

There are severals ways to make new code available.
Mostly CVS version should be available for people who want to test
CVS versions and are fully aware that they are pre-alpha testers
(=developers). 

> Even if we have 2 branches (MAIN and stable), 

We only want to have a release and MAIN branch.

> I cannot
> tell to user that he can use "new" v.out.shape because he has probably stable
> branch installed. If we had v.out.shape2 in one branch I can tell him that he 
> can use unstable version:
> cd src/mapdev/v.out.shape2
> gmake5
> gmakelinks5

You can. You just have to stop letting a release branch rot
and divert too much from the MAIN stable branch.
A release branch is not for development it is for removing release
critical bugs!

> Other contributors are not interested in branches question? Can you vote?

I don't think a vote will help.
We need a good concept and _stick_ to 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/20020325/0127291d/attachment.bin