[GRASS5] The status of 5.0

[Radim Blazek]

On Friday 22 March 2002 05:12 pm, Bernhard Reiter wrote:
> > While continuing to think about eventual advantages for *us* with
> > branching, there seems to be litte reason to continuing branching
> >
> > We have used branches for one year now, with no real advantages but
> > a lot of extra work. The reason might be that we weren't using branches
> > as intended, but we have the limiting factor of a small team.
>
> I don't agree.
> It is the opposite reasoning:
> 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. 
Because of that GRASS development system must be simple and transparent 
instead of complex and hard to understand.

> I agree that we are seeing some extra efforts while we are all
> learning this and setting it up for GRASS.
> It will pay off several times.
>
> > The previous way (4.x) of having x.y.module and x.y.module2 is
> > probably more obvious and less energy consuming.
>
> Not in my experience with other big Free Software projects.

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.

> > At time I find branches a bit waste of time - the outcome is little.
> > To create/delete release branches more frequently will even consume
> > more of our energy.
>
> We need the quality control badly.
> Without branches we will have more confusion with the same number of
> bugs, fixes, feature requests, experimental enhancements ...
> Now you are sometimes forced to get the overview and decide
> what to keep from all this mess. It might look like more work,
> but it is badly needed to prevent even more work.
>
> 	Bernhard

Simple example of our experience:
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)
3. Glynn, tagged my code, and replaced by version from release branch
    (OK, because it was not tested well and cannot go to release)
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.

=> results:
- Glynn and I spend extra time
- new code is not available (easily)

Even if we have 2 branches (MAIN and stable), 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

Instead I have to tell him: 
"You have to compile code from MAIN branch -
you know, that branch which is not tagged releasebranch_11_april_2001_5_0_0
(also called release branch). So you have to check out whole MAIN branch from
repository - it is quite easy - just read CVS manual and instructions for 
GRASS CVS. Then you must compile grass MAIN tree. Compiled tree takes only 
about 500 MB - it is not problem. Now you must close your grass session
and start grass from MAIN tree you have just compiled. You can run
v.out.shape, exit grass and start grass stable. It is quite simple."

Other contributors are not interested in branches question? Can you vote?
Branches for 5.0.x yes - no; Glynn, Eric, David, ....


Radim