[GRASS5] GRASS stable/exp branches

[Justin Hickey]

Hi Bernhard, and Markus

Bernhard Reiter wrote:
> > > 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.
> 
> It is not necessary.
> You just tag your version and only merge the changes for your fix,
> even when it is spread out.

First, I may not understand what you mean so please correct me if I'm
wrong.

Note that this example occurs between two releases (for example a few
months after 5.0 stable is released), I am not talking about commiting
such a large bug fix to the stable branch at release time. Remember that
the method suggested is to commit changes to the exp branch and then
merge bug fixes to the stable branch. That is, to my understanding,
commits cannot be made to the stable branch, only merges. So the version
on my machine is the exp version that contains several new features that
were committed before I found the bug. If I tag my version, I tag the
new features as well. How do I tag a version before the features were
added? As I understand it, I would have to check out the version of the
last complete merge, make my changes to the files, and then merge them.
However, what if my bug fix is also required in files that were added
with a new feature that I am not allowed to merge into the stable
branch? I have to go back and make those changes as well, requiring two
searches, one for files of the last complete merge, and one for files
added in new features. This seems to be a waste of time to me.

It will also be a major pain for Markus since he would have to make sure
that the only merges to the stable branch are authorized. The only way I
see this happening is if he is the only one allowed to merge into the
stable tree. In which case we again have the same thing we do now. Both
features and bug fixes go into the exp branch and Markus is responsible
for saying when it's safe to merge. I see no difference in Markus saying
when we release a new version like he does now. 

The only way for a stable branch to be effective is to allow commits of
bug fixes directly to the stable branch. And again when do we decide to
merge in the new features to the stable branch? Each merge from the exp
to stable branch will present a risk of severe problems. There is
minimal risk of severe problems if you are merging bug fixes into the
exp branch.

> > Yes, that sounds reasonable. I definitly want to lower the extra 
> > work, that's why we use CVS. ok: my proposal deleted :-)
> 
> No, Markus, your proposal was a lot better.

I'm sorry, but I do not see how his work load will not increase with
always having two branches. Please explain how managing two branches is
less work than managing one branch.

> > > > 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.
> 
> This is basically true.
> 
> > > I don't think we should individually decide if each module is
> > > stable or not and add them one at a time.
> 
> Well we have to start to tag modules which we know are stable.
> So there has to be one starting point for the stable branch.
> And Markus has to decide which modules get in there.
> Later we can add more when we know they are ready to be included.
> To rephrase it again: Yes we have to decide which module is stable
> and which not.

I agree that this would be ideal, however, I think this is impractical.
To be decalred stable each module would need to be tested on several
platforms. What happens if we only verify stability for say half of the
modules and no one volunteers to test the other half? Remember that we
have problems finding developers to fix bugs, so I can't see alot of
people volunteering to do all this testing. In fact even if we agree to
add the modules this way and get volunteers to do the testing, how long
will this take? We keep saying that we need to release 5.0 but it seems
to me this would push the release day back by months. Furthermore, is
Markus willing to tag 300+ modules individually?

Remember that there is no such thing as bug free software, thus we will
never be "stable". The goal is to produce software that will work for
most people. Thus, it seems much more practical to me to tag a complete
branch all at once, fix as many known bugs as we can in a short amount
of time, and start pretesting. Modules that do not get fixed are simply
commented out of the src/CMD/lists/GRASS file.

I'm sorry, but I think adding modules individually would take a lot of
time and add a lot of work for Markus.

> > The only question is: how to get instable code out of the stable 
> > release?
> > For example: The entire G3D section should not yet go into stable.
> > Then there are several modules to be commented. Probably we should
> > keep them in src-ball,
> 
> No. I advise against Justin's idea. :)

As I said above, we comment them out of the GRASS list file, just as G3D
is now. If people want to try and compile it separately, then fine, they
can be warned that it is not stable.
 
> > > 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.
> 
> > Ok, we have a sort of periodical stable branch then.
> 
> We need one continous stable branch until 5.0.0 is released.
> After that we have to rethink a couple of things. I also do not
> think that we need the same setup for the 5.1 _tree_.

Wait a minute, I'm talking about a methodology for all releases, not
just 5.0. Correct me if I'm wrong, but I was under the impression that
the next release was going to be 5.0 stable. Markus has stated that the
socket code is the last feature, thus I see no reason for any more
betas. Is this not the case?

> > However, this needs commit discipline: Only bugfixes are allowed
> > untilthe periodic stable branch is merged back after publishing the
> > stable release. Did I get it?
> 
> True, and the other way gives you more control and is therefor saver.

I'm sorry but I don't understand how merging into the stable tree can be
safer. The possibility always exists that several experimental features
can be merged into the stable branch at a single time in your method. In
my method the worst thing that can happen is a single experimental
feature can be comitted to the stable branch at a single time. To me,
fixing a single commit of a feature is more desirable than fixing
several commits of several features that could have occurred over
months.

> > > 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.
> 
> I don't think so, we have the same problem as before, the control
> over what bugfix gets in is not fine grained enough.

But the control over which features get merged into the stable branch
is? To me a bug fix usually has less risk than a feature, thus it is
more likely that bug fixes are easier to manage than features. Plus in
my method the two branches only exist for the release period, minimizing
the amount of time and effort needed to manage these merges. After the
release, we are back to a single branch.
 
As I told Markus, please let me know if I have misunderstood your
method.

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