[GRASS5] GRASS stable/exp branches

[Bernhard Reiter]

Hi Justin,

On Thu, Feb 22, 2001 at 07:50:03PM +0700, Justin Hickey wrote:
> Bernhard Reiter wrote:

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

If you have three files you have to change for a bug-fix. 
And they are in different parts of the source tree.
You use tags to denote this fix and it can be merged with one
command into a different cvs branch.

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

Well if you know that you are only going to fix a bug, IMO you
should be able to do the bug-fixing in the stable branch directly
and merge the fix back to the exp branch.

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

You tag the version before fixing the bug and and after fixing it.
Then you can just merge the differences into stable.

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

Well there will be some porting, but you cannot help that in all
solutions.

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

True.
But we want no new features before the 5.0.0 release.
And if we get this out of the door, we have to reorganise again and
have to decide on each feature indiviually for 5.0.1 and so on.
We need to get 5.1 up then as fast as possible.

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

The control what goes into the stable branch is better for Markus.
So we get more stability and disciplin to finally get 5.0.0 out.
On the other hand we do not stop developers from addin features for
5.0.x, because the 5.1 is not reorganised and up already.

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

Well this is the hard part, but we are getting better on this.
Markus just need to apply his heuristics on that a module is stable.

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

We need more formal testing, that is clear.
And we are not going to do it for the 5.0.0 release.
We just have to release what we (Markus) considers stable right now.

> Furthermore, is
> Markus willing to tag 300+ modules individually?

He will have to go through all the modules ones and build a tree for
the first tagging. But yes, he has to check on each modules once.
There is no way around it. Most modules will be easiy to categories
and then not much else changes so there is not much tagging work to do.

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

Well, this is, what is called stable.
And software can be stable, though it will never be bug-free of course.

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

There are modules that we know which are not stable, we shall leave
them out of a stable source release right away. We can have a second
tarball with unstable modules, if we need to release them as
tarball.

Actually the initial tagging is like tagging a branch.
But we need a lot (non-branching) tags anyway, so merging can be done.


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

I am all talking about the 5.0.0 stable release and not about much more.
We will still need pre and beta releases for this, yes.

> As I told Markus, please let me know if I have misunderstood your
> method.

Sorry for answering so late, but I hope I could shed some light on
the issues.

I really advise Markus to go ahead with the one release branch.
(We should call it release branch, because it is on the 5.0.x cvs
tree and the tree is the stable tree. In the beginning of the mail
we called the release branch the stable branch and the other exp.)

	Bernhard

-- 
Professional Service around Free Software                (intevation.net)  
The FreeGIS Project                                         (freegis.org)
Association for a Free Informational Infrastructure            (ffii.org)
FSF Europe                                            	  (fsfeurope.org)
-------------- 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/20010227/837108cf/attachment.bin