[GRASS5] GRASS stable/exp branches

[Justin Hickey]

Hi Bernhard - All other developers, please look at the methodolgy
presented towards the end of this post (just search for **********) if
you want to skip the details of this discussion.

OK, I understand what you are trying to say and I think we are basically
talking about the same thing with a few minor differences. First, I'll
comment on some of your replies.

Bernhard Reiter wrote:
> 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.

Yes, this is what I was proposing. Create a stable branch and then
restrict commits to this branch to bug fixes only. In fact I would say
that only *minor* bug fixes be allowed to be committed. Permission from
Markus or a consensus from the developers should be required to allow a
*major* bug fix to be committed to the stable branch. Anything else is
committed 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.

Ahhh. OK I see this 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.
> 
> True.
> But we want no new features before the 5.0.0 release.

Yes, so we create a stable branch now (or soon). Then the new features
go into the main branch.

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

My vote is to not add any more features to 5.0 at all. Any 5.0.x release
in my opinion should only contain bug fixes which we may have missed for
5.0.0. Any new features will go into 5.1.

> We need to get 5.1 up then as fast as possible.

Agreed, but unfortunately, I don't think it will be a fast process. :-( 
Once we get the new directory structure created and the modules placed
in their new directories then development can proceed on 5.1. However,
we may also want to have the new Makefile system in place as well before
development, but it is not actually necessary.

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

We agree on this. I was under the impression that you intended for the
stable branch to continue to exist long after 5.0, 5.1, 5.2, etc. Thus,
Markus would always have two branches to maintain. Sorry for that
misunderstanding.

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

Yes, and to me, the easiest way to do that is to mark the current tree
stable and comment out those modules considered unstable from the
src/CMD/lists/GRASS file. We can decide stability on a module-by-module
basis when we create the new directory structure for 5.1.

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

Not necessarily. There are two ways to approach this. We can assume that
we do not trust any module to be stable and Markus will have to check
each one himself. Or, we can assume that most modules are stable and
find the unstable ones through bug reports during pre-testing and post
release time. This way, each module does not have to be checked and we
get 5.0 released sooner. The only downside is that we may release a few
unstable modules, but I don't think we will have anything serious fail.
Please remember that this would only be for the 5.0 release. I think
each module does need to be checked, but I would say the best time to do
that is when we are placing the modules in the new directory structure,
since we won't have the pressure to release something at that time.
Ultimately, it will be Markus who decides what he will do. :-)
 
> > 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.

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

Pre release yes, beta no. Since only bug fixes will be committed to the
stable branch, there is no need for another beta release. The socket
code is the only new feature in CVS at the moment from beta 11. I don't
think this feature requires another beta release.

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

Yes you have. Thank you!
 
> 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.)

************** All other developers can start here *******************

I'm not sure what you mean by a one release branch, so lets see if I can
summarize a methodology for 5.0. that hopefully we all can agree to.

1. Define bugs to be fixed for 5.0 and urge developers to claim them on
RT. After a short period of time, those bugs not claimed are left for
5.1. Unclaimed bugs won't be fixed and a decision made to mark them as
unstable or not.

2. Create a stable branch (maybe do this at the same time as 1?). Only
*minor* bug fixes are allowed to be committed to the stable branch along
with those identified in 1. Major bug fixes can be committed only after
developer consensus or approval from Markus. Requirement for a major bug
fix to be committed is that it fixes something crucial to the operation
of Grass. No new features are allowed to be committed to the stable
branch.

3. Once bug fixes from 1 are committed release 5.0 pre 1. Perhaps have a
time limt?

4. Fix any bugs reported from pre-testers

5. Release 5.0 pre 2. Again, a time limit?

6. Fix any further bugs reported from the pre-testers

7. Release 5.0.0 stable. (Just for consistency), a time limit?

8. Fix any bugs reported by users and release a number of 5.0.x releases
if necessary. No new features allowed in these releases.

9. At some point Markus decides there will be no more releases of 5.0.x,
the stable branch is considered dead, and changes are merged into the
main branch. Note that merges could be made throughout this process to
the main branch but merging from the main branch to the stable branch is
not allowed at any time.

10. Continue development on the main branch.

For me this seems to give a good level of control and minimizes the time
that we have two branches. The only problem that I see is how we back
out a change that should not have been made to the stable branch. Three
options I can think of are:

1. Insist that the developer who committed the code back it out using
log files to determine which files to back out.

2. Have a cron job to tag the stable tree once a day (or some other
regular time frame).

3. Insist developers tag the stable tree before they make any changes
and then tag it again after they make their changes (as you suggested
above).

I think number 1 should be used as a last resort method. It is a bit
tedious, but if you did not tag the files and you don't know all the
files you changed, then it is the only way I know of how to back out a
commit.

Number 2 I think is feasible but if there were more commits than the one
made in error, then those commits would have to be done again.

Number 3 is probably the safest way, but I don't know how we can force
developers to do this.

No matter what methodology we decide on, two things will be crucial.
First, we need good cooperation from all developers. Second, I think we
should post clearly detailed steps for how to commit a bug fix to the
stable branch. This would include clear definitions of what to tag (tag
the files you will change, the whole module, or the whole tree), when to
tag, as well as steps to take to back out a commit. This second part is
crucial since most of us are not familiar with CVS and how it works with
branching and merging. At least I know I'm not, which was part of the
confusion I had.

Anyway, I hope we can finalize these issues soon so we can start the
release cycle. Does anyone have any other comments or concerns? Please
respond even if it is to say that you agree. If you don't agree, please
explain why and suggest an alternative. We need to finalize this
methodolgy so we can start the release cycle as soon as possible. Having
your input will help finalize this by giving us an indication of how the
developers feel.

Sorry about the length (again), but I feel that development will be
stalled if we do not start the release cycle soon, and we need a clear
methodology to do that.

Thank you everyone for your time.

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