[GRASS5] GRASS stable/exp branches

[Justin Hickey]

Hi Markus

Markus Neteler wrote:
> I like this model:
> 
>   +-----+    +-----+    +-----+    +-----+    +-----+
>   ! 1.0 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !   <- The main exp trunk
>   +-----+    +-----+    +-----+    +-----+    +-----+
>                   !            \                 \
>                   !              \                \
>                   !               _\| bugfix       _\| bugfix
>                   !   +---------+    +---------+     +---------+
>  Stable branch -> +---! 1.2.2.1 !----! 1.2.2.2 !-----! 1.2.2.3 !
>                       +---------+    +---------+     +---------+
> 
> We work on expimental, in case a bug is found in stable, we apply it 
> to exp and merge into stable branch.
> 
> As I am no software engineer, does this make sense?

Not quite to me, sorry. This setup is not much different than what we
have now - adding features and bug fixes to the branch we want people to
download. For example, say I fix a bug, but it requires changes to files
spread out all over the source code (I change the parameters of a
function call in the gis library). I will not want to merge each file
individually, so I do a general merge of the whole grass tree. That
means all bug fixes AND features merge with the stable, which is what we
have now. I also see this as more work for you unless you get volunteers
to help monitor the branches. Another point is when do we merge in the
features?

> There might be the idea to start a new stable from every time when we
> want to release a new stable version (so every stable branch is dead
> after publishing the individual stable version). This would make life
> easier in terms of less bugfix merging required, BUT: Every new stable
> branch needs that every module is tagged "stable" (or not). Means to
> visit 400 modules all few month, even if you know they are stable.
> Therefore I feel to have a continuous stable branch is better.

What does this really mean? I thought that to create a branch you simply
do a cvs tag -b command at the grass root and you let CVS take care of
the rest. I don't think we should individually decide if each module is
stable or not and add them one at a time. What I thought was feasible
was at some point when we want to create a release we create the branch
on the whole tree at one time, at which point only bug fixes can be
committed to the stable branch. Then we define which bugs will be fixed
for this release, and once they are fixed we start our pre-release
testing. If somebody commits a feature just before the branch is made
and it has a bug, we are very likely to find it while we fix the bugs in
our list. As for merging, we can either wait until we publish the
release and then merge all bugfixes back to the exp branch, or we merge
them back periodically during the bug fixing stage.

With this option, additional workload for monitoring both branches is
minimized since the two branches exist for only a short amount of time,
and it is easier to keep features out of the stable branch. Now we
create a branch, make it stable by not adding any features and this is
the code we want people to download.

I don't know if I understood you correctly, but this method seems safer
with less managment overhead to me than always maintaining a stable
branch.

Just my 2 cents worth

-- 
Sincerely,

Jazzman (a.k.a. Justin Hickey)  e-mail: jhickey at hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
==================================================================
People who think they know everything are very irritating to those
of us who do.  ---Anonymous

Jazz and Trek Rule!!!
==================================================================

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'