[GRASS5] Using CVS to manage "experimental" vs. "stable" trees

[Carl_Worth]

I've been reading the "GRASS CVS and release strategies page"[1] as
well as following the release plans on this list. I think there are
some good systems in place, but I think we could use some improvement
as well.

I wrote up a long and rambling email, and after having done so, I
think I can summarize it to a few points:

  o The proposed use of branches to manage releases is a Good
    Thing.

  o Using a separate CVS module, (ie. grass51), for the
    experimental tree is problematic for a few reasons. It has a
    fracturing effect on the development community. Note how
    underutilized this tree is. Think ahead about the
    logistical problems involved in turning the grass51 tree
    into the "stable" tree, (getting all developers to shift
    over, renaming things on web pages, etc.)

  o The need for parallel development is not great. It really
    only exists during the transitions when one "experimental
    tree" of GRASS becomes the new "stable tree".

  o Parallel development, (when necessary), is best handled with
    branches in CVS.

Proposal: Sometime after GRASS 5.0.0 is released, and when the
development community feels the time is right, the experimental code
in the grass51 module should be placed at the head of CVS in the grass
module.

I'll include my long and rambling email below that goes into more
detail on several of these points.

I'd be very interested in hearing reactions/discussion about these issues.

-Carl

--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725

PS. Here's what I wrote earlier:

First, I like the plan currently in progress for making a stable
release. Namely, code is developed on the head of the CVS tree. When
the code reaches a point at which it is worth releasing, a release
branch is created in CVS, (I don't know what tag naming convention
will be used for the branch, something like
"RELEASE_5_0_0_branch"?).

Then, no development will occur along that release branch, but only
release critical bug fixes, (which must be simultaneously applied to
the head of the tree). After some testing/fixing cycles, the branch
will be determined releasable and will be tagged (something like
"RELEASE_5_0_0"?), and released.

At that point, if I understand things correctly, that release branch
will not have any work done on it after that. The 5.0.1 release will
not come from an extension of the 5.0.0 branch, but will instead be a
new branch off of the trunk at some later time.

Am I correct with all of this so far? Now I'm getting to the point I
want to make.

Within CVS there is currently a separate module for grass51, (which is
an experimental tree for exploring incompatible changes to GRASS in
parallel with the development efforts on the stable tree).

One problem with the grass51 tree is that it has been extremely
underused, (as mentioned on the web page above). I think this is
largely due to the fact that there are a limited number of GRASS
developers and most attention has been focused on the stable tree.

However, there have also been many features proposed on this list that
have received a reaction of "save that for grass51". I have proposed
several of these features myself, and discovered that I couldn't
directly implement them in the grass51 tree since not all of GRASS
exists there yet, (much of it is simply copied over from the stable
tree during compilation).

And, eventually, the code being developed within the grass51 tree must
become the new stable tree. So at some point, all of the developes
that are currently working on the "stable tree" must be shifted over to
what is now the "experimental tree" and the trees must be
renamed. This is a severe logistical problem, (informing developers
what to do and when, updating lots of grass/grass51 references on many
web pages, trying to make sure that developers don't get lost
wasting effort developing on an old and useless tree).

So, to address that issue, I would like to propose an addition to the
system. I propose that at some point, the "experimental tree" should
be officially designated as the primary development effort. In order
to do this, the code from the experimental tree should be merged into
the head of CVS on the stable tree. That way, developers are easily
pulled along in the new direction of GRASS, and if we're careful, web
pages can remain with the original text.

At that point, the effort on the head of CVS will be geared toward
making a new stable release, (eg. 5.2.0 will be the next one). If
there is actually interest in simultaneous mainenance of the former
stable releases, (eg. 5.0.x), then this could occur in parallel along
the last 5.0 release branch. This would be the only time development
would occur on a release branch and would only happen if the new
stable branch was taking too long to come about for somebody.

Finally, if such a system make sense, it would be much easier to
implment if the "experimental tree" were implemented as a branch
rather, (if necessary), rather than a separate module. This would make
the merge much easier, and would eliminate the current awkward "copy
code from some other CVS tree" implementation.

To summarize, code development would always occur on the head of CVS
in one module. Test/debug cycles for each release would occur on short
branches. Parallel development, (which is by nature splintering),
would only occur if needed and would take place on the last stable
release branch, (if someone wanted to continue to maintain a stable
release after the core team had moved on), or on an "experimental
branch", (if someone wants to get a head start on experimentation
before the core GRASS team decides to).

-Carl

[1] http://grass.itc.it/codemanagement.html

PPS. For the truly sadistic who want to read even more rambling prose
from me, here's something I wrote even earlier as I was first
collecting my thoughts on all of this:

As for grass51, I'm perpetually confused by the way this is handled in
CVS. I understand that we are making fundamental changes to things
like the vector engine as well as re-organizing all of the code
structure, (which is very much needed). But I don't see how I can make
good use of the grass51 development tree as it currently exists.

For example, let's say I want to hack away on the display driver
interface. But, it doesn't actually exist in grass51 CVS. Instead, it
is merely copied over during compilation from the main grass CVS
tree. So, there is no way in CVS to actually work on this code, (at
least, not until it all gets moved over. What's the plan for that).

And even then, after all the code is restructured into the grass51
tree, there's no easy way to communicate and coerce developers to stop
working on the old grass tree and start working on the new grass51
tree, (as opposed to simply merging a "grass51" branch back into the
head of CVS once it is determined stable enough for general
development).

Similarly, I don't get a warm fuzzy from naming a top-level CVS module
with an embedded version number, (51). It seems to me that version
numbers should be used to tag code when it gets to a particular
development state, not to name the code, (especially not "a priori" as
in this case). Cross-reference to recent post suggesting problems with
needing to increment a major the middle version number to make a new
5.1.0 release after making incompatible changes to 5.0.x).

So, in summary, why is the re-organization of the code for "grass51"
taking place inside a new CVS module with an embedded version number
rather than within a CVS branch for example? When new features are
proposed to the list, I often see responses of the form, "Save this
for Grass51" -- yet, currently, there's no way to actually work on
grass51 so the work is necessarily slowed down.

-Carl

[Bernhard_Reiter]

On Tue, Apr 23, 2002 at 03:14:28PM +0000, Carl Worth wrote:

I've been reading the "GRASS CVS and release strategies page"[1] as
well as following the release plans on this list. I think there are
some good systems in place, but I think we could use some improvement
as well.

We are welcome to suggestions.
Note that in my view we really have to start making one interation
before we can fine tune. In the last years there were several
discussions never leading to a tarball release of grass 5 called stable.
This is why ours plans got more aggresive.

GRASS is a huge project, we need to make a stable release somehow
and slowly adjust the users that we have now an open development.

Because of the conservative user base and the developers
that mostly are not software engineers, we have to take small steps.

  o Using a separate CVS module, (ie. grass51), for the
    experimental tree is problematic for a few reasons. It has a
    fracturing effect on the development community. Note how
    underutilized this tree is.

This is known, but still an improvement.
GRASS is a huge project, we have to divide it so
programmers can conquer it.

It is the result of intensive discussions on
how to progress on separate tracks. Now Radim could start on the
vector code which is great.

        Think ahead about the
    logistical problems involved in turning the grass51 tree
    into the "stable" tree, (getting all developers to shift
    over, renaming things on web pages, etc.)

It was even messier before.
It was not clear what was development code and what is stable.
With people regularily pointed to the development versions in the cvs.
Most users want a stable release.
Many people want additions in all directions.
If we let everybody do this on one tree, we never get a release.

And technically it is easy, just declare check out the
grass51 version you want and create a new stable tree, called grass52.
No need for renaming.

  o The need for parallel development is not great. It really
    only exists during the transitions when one "experimental
    tree" of GRASS becomes the new "stable tree".

My experience in the last years is that users are very conservative
and do want very stable code.

  o Parallel development, (when necessary), is best handled with
    branches in CVS.

I'm glad that CVS acceptance is growing with GRASS developers.
Branches are still magic for many.
Thus we will not use them in even more complicated ways.

On the other hand, directory reorganisation within a tree
with CVS is difficult, we had to use subversion or other revision
control system for this.

Proposal: Sometime after GRASS 5.0.0 is released, and when the
development community feels the time is right, the experimental code
in the grass51 module should be placed at the head of CVS in the grass
module.

Looses history and is complicated.
Will not provide enough parallel development possibilities.

PS. Here's what I wrote earlier:

At that point, if I understand things correctly, that release branch
will not have any work done on it after that. The 5.0.1 release will
not come from an extension of the 5.0.0 branch, but will instead be a
new branch off of the trunk at some later time.

Yes.

One problem with the grass51 tree is that it has been extremely
underused, (as mentioned on the web page above). I think this is
largely due to the fact that there are a limited number of GRASS
developers and most attention has been focused on the stable tree.

No.
The analysis on the release strategy pages dates back to november 2001.
After that Radmin started to use the grass51 for exactly the right purpose.
Thus usage is as planned now.

However, there have also been many features proposed on this list that
have received a reaction of "save that for grass51". I have proposed
several of these features myself, and discovered that I couldn't
directly implement them in the grass51 tree since not all of GRASS
exists there yet, (much of it is simply copied over from the stable
tree during compilation).

We hope to get developers to help us to get the stable release out.
Next big step is reorganisations and we also hope for more modularisation.
Then there will be more room for experiments.

Thus you can :
  a) make your own branch for experimentation on grass5
  if you really must. You will be fully responsible for
  releasing anything of this or folding in at some time.

  b) help to bring over modules you need to grass51
  (very appreciated)

  c) help to make the stable release that other people will
  have more time to populate grass51.
  

And, eventually, the code being developed within the grass51 tree must
become the new stable tree. So at some point, all of the developes
that are currently working on the "stable tree" must be shifted over to
what is now the "experimental tree" and the trees must be
renamed.

As pointed up above there will be no renaming.
Please note that many people rejected CVS at first,
because of the additional buraucracy as they saw it.
Now it saves time.

The next paragraphes will indoce missunderstandings about
what you reall want to archive:

This is a severe logistical problem, (informing developers
what to do and when, updating lots of grass/grass51 references on many
web pages, trying to make sure that developers don't get lost
wasting effort developing on an old and useless tree).

We need to get more formalised procedures to do this,
this is very clear from past experiences.
We cannot avoid structuring it.

To summarize, code development would always occur on the head of CVS
in one module. Test/debug cycles for each release would occur on short
branches.

Trust me on this, we are not ready for this.
Massive code reorganisation with a huge project like GRASS
better happens in a fresh cvs tree.

I'm very glad for your analysis though,
as the stream of thoughts is similiar to mine.
I hope that I've writen down many of the subconditions
that convince me that we are on a good path without
immideate need to refine it.

[Glynn_Clements]

Carl Worth wrote:

At that point, if I understand things correctly, that release branch
will not have any work done on it after that. The 5.0.1 release will
not come from an extension of the 5.0.0 branch, but will instead be a
new branch off of the trunk at some later time.

The 5.0.x releases should be made from the same branch as 5.0.0. They
should differ from 5.0.0 only in terms of bug fixes. It would be
possible to add new modules (which work with the existing libraries),
but I would suggest that developers work on the next major version
instead.

--
Glynn Clements <glynn.clements@virgin.net>

[Carl_Worth]

On Apr 23, Bernhard Reiter wrote:
> We are welcome to suggestions.
> Note that in my view we really have to start making one interation
> before we can fine tune.

Fair enough Bernhard. I'm willing to wait on this one, (my proposal
doesn't actually call for immediate change, just that down the road,
when the "experimental tree" becomes stable we actually merge it into
the head of the grass module).

So, you can take my post as food for thought and we can revisit this
again when the time is right.

-Carl

PS. I will respond in line to a few points, but we probably don't need
too much more discussion.

> GRASS is a huge project, we need to make a stable release somehow
> and slowly adjust the users that we have now an open development.

I agree here. [Along with several other things I've snipped].

> > Think ahead about the
> > logistical problems involved in turning the grass51 tree
> > into the "stable" tree, (getting all developers to shift
> > over, renaming things on web pages, etc.)
>
> It was even messier before.
> It was not clear what was development code and what is stable.
> With people regularily pointed to the development versions in the
> cvs.

I know it was messier before. When I first tried GRASS I was extremely
confused as I was using the head and it was broken in several ways
that no one on the list could explain, (since they were all off on
some branch). We're definitely in a much better situation now than
then.

> And technically it is easy, just declare check out the
> grass51 version you want and create a new stable tree, called grass52.
> No need for renaming.

Ah, but there is renaming. There are web pages now that say:

  grass50 (stable tree)
  grass51 (experimental/development tree)

All such references will have to be chased down and fixed to make the
shift.

> On the other hand, directory reorganisation within a tree
> with CVS is difficult, we had to use subversion or other revision
> control system for this.

Directory reorganization is painful, yes. But it is not really much
easier to reorganize the code and add it to a new module than to
reorganize it "in place" within one module.

For example, grass51 still doesn't have most of the code moved over. I
think this is because restructuring the organization of something as
large as the GRASS code is fundamentally hard. The extra burden of a
few "cvs remove; cvs add" commands is really in the noise compared to
the real work that needs to be done.

> > Proposal: Sometime after GRASS 5.0.0 is released, and when the
> > development community feels the time is right, the experimental code
> > in the grass51 module should be placed at the head of CVS in the grass
> > module.
>
> Looses history and is complicated.

I don't see how there is any history loss here.

> Will not provide enough parallel development possibilities.

My contention is that parallel development should happen on
branches. You've argued that in the eyes of the majority GRASS
development community, branches are still "magic". I accept that. But,
at the same time, the majority of the GRASS development community
doesn't need much parallel development. The few that are actively
doing it, (ie. Radim), could certainly handle working on a branch, no?

> We hope to get developers to help us to get the stable release out.
> Next big step is reorganisations and we also hope for more modularisation.
> Then there will be more room for experiments.
>
> Thus you can :
> a) make your own branch for experimentation on grass5
> if you really must. You will be fully responsible for
> releasing anything of this or folding in at some time.
>
> b) help to bring over modules you need to grass51
> (very appreciated)
>
> c) help to make the stable release that other people will
> have more time to populate grass51.

Thanks for the concrete suggestions.

In my view, I don't think I can help much with the current release,
(I'd be getting up to speed on things just as it was finishing up).

So, I'll go ahead with option (b) and start bringing over modules to
grass51. I hope I can be of help.

There's no doubt that having to hand-pick through each module will
give us a good opportunity to do some careful cleanup.

I think I'll be wanting to make some posts about how to tackle certain
aspects of the reorganization, (after I digest what's already written
up).

Is this list the correct venue for such discussion? I don't want to
muddle the work on getting the release done.

Thanks again!

-Carl

--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725

[Glynn_Clements]

Bernhard Reiter wrote:

And technically it is easy, just declare check out the
grass51 version you want and create a new stable tree, called grass52.
No need for renaming.

One problem with multiple repositories is that you don't get the same
degree of information on the revision history as you do with branches.
E.g. you can do "cvs diff" between branches, but not between
repositories.

On the other hand, directory reorganisation within a tree
with CVS is difficult, we had to use subversion or other revision
control system for this.

Directory reorganisation isn't necessarily difficult; it just destroys
the revision history. "Renaming" in CVS equates to deleting the old
file and creating a new file (which just happens to be identical to
the old file)..

Unfortunately, sometimes mistakes are made, and either you correct
them, or you have to live with them for eternity. If you are going to
correct them, it's better to do it sooner rather than later.

> However, there have also been many features proposed on this list that
> have received a reaction of "save that for grass51". I have proposed
> several of these features myself, and discovered that I couldn't
> directly implement them in the grass51 tree since not all of GRASS
> exists there yet, (much of it is simply copied over from the stable
> tree during compilation).

We hope to get developers to help us to get the stable release out.

Once you "freeze" the code (i.e. restrict changes to bug fixes), the
process is driven by the rate at which bugs can be identified. At
which point, the problem isn't likely to be the overall amount of
developer time available, but being able to find a suitable developer
who understands the code in question.

--
Glynn Clements <glynn.clements@virgin.net>

[neteler]

On Tue, Apr 23, 2002 at 04:37:53PM +0000, Carl Worth wrote:

On Apr 23, Bernhard Reiter wrote:
> Thus you can :
> a) make your own branch for experimentation on grass5
> if you really must. You will be fully responsible for
> releasing anything of this or folding in at some time.
>
> b) help to bring over modules you need to grass51
> (very appreciated)
>
> c) help to make the stable release that other people will
> have more time to populate grass51.

Thanks for the concrete suggestions.

In my view, I don't think I can help much with the current release,
(I'd be getting up to speed on things just as it was finishing up).

So, I'll go ahead with option (b) and start bringing over modules to
grass51. I hope I can be of help.

Carl and all,

this is in fact the idea of the new directory. The current
code directory layout is partly a mess. And, AFAIK, it is quite
a job to move directories around in CVS (not desired at all eventually).

When new code is introduced into grass51/, it must undergo numerous
checks and improvements. Even that we loose history connection to grass5/,
who is really going further back than one minor CVS version number (o.k,
maybe two or three). But in these few cases it can be also compared from
two different directories.

The current directory structure is pretty unclear to newcomers. It
is far from inviting people to start programming. That's why a new
directory structure is needed as already started in grass51/ directory.

There's no doubt that having to hand-pick through each module will
give us a good opportunity to do some careful cleanup.

Perfect.

I think I'll be wanting to make some posts about how to tackle certain
aspects of the reorganization, (after I digest what's already written
up).

Maybe you look into
/grass5/documents/new_directory_structure.txt
/grass51/doc/migration_50_51.txt

(if you like, trash all ideas inside and improve it)

Just my impression,

Markus

[Carl_Worth]

On Apr 23, Glynn Clements wrote:
> > At that point, if I understand things correctly, that release branch
> > will not have any work done on it after that. The 5.0.1 release will
> > not come from an extension of the 5.0.0 branch, but will instead be a
> > new branch off of the trunk at some later time.
>
> The 5.0.x releases should be made from the same branch as 5.0.0. They
> should differ from 5.0.0 only in terms of bug fixes. It would be
> possible to add new modules (which work with the existing libraries),
> but I would suggest that developers work on the next major version
> instead.

Glynn,

I agree that this is how things should be done.

I didn't advocate this in my original post, since I was trying to
stake out a moderate position without revamping everything about how
GRASS is being developed currently.

But, as long as you've brought it up now.

If a branch is created named RELEASE_5_0 along which we make some bug
fixes and get to a point which we tag RELEASE_5_0_0, then we can later
fix more bugs, (found by actual users not just developer testing), and
make later tags along this branch such as RELEASE_5_0_1 and
RELEASE_5_0_2.

Having a branch such as this which is restricted to strict bug-fixes
only is really the only way to guarantee extreme stability between
minor releases.

But, in this system, what then becomes of the head of CVS? Certainly,
more development would occur there, (or else, why create the branch in
the first place?), and it would reach a point at which it is ready to
be released. It would be natural, then to create a RELEASE_5_1 branch
and repeat the process.

However, this is highly confused by the fact that we already have a
module named grass51. (This is a problem in the existence of this
module, not in the scheme proposed above).

The fact is, when a developer sits down to write a piece of code, it's
impossible to predict a completion schedule, (especially the relative
schedule compared to other developers --- some of who may not yet be
on the project). Between now and the time Radim finishes the new
vector engine and it is ready to be included in the new stable release
of GRASS, how many different incompatible new features will other
developers create and want to release? Would we want to release 5.0,
5.1, and 5.2 before then? The answer is impossible to predict. Hence,
it's very dangerous to attach version numbers to things before they
are released, (release points are really the only time version numbers
make sense).

Instead of using a number like 5.1, (even an odd number), when doing
parallel development, it seems it would be better to name the
functionality being explored, (eg. database_backed_vector_engine or
whatever). And, as I put forth in my previous mail, such named
experimentation belongs in a branch rather than a separate module.

So, those are my thoughts on where we should ideally be some
day. Plans for moving from where we are today may have other more
pragmatic considerations, (though generally, when making big
improvements -- even painful ones -- sooner is generally better than
later).

Cheers,

Carl

--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725

[Bernhard_Reiter]

On Tue, Apr 23, 2002 at 05:19:07PM +0100, Glynn Clements wrote:

The 5.0.x releases should be made from the same branch as 5.0.0.

From the same tree: "grass5".
We will need several release branches for
having parallel release critical bug-fixes for going out of beta.
These branches shall collapse _fast_. (A month or two.)

They should differ from 5.0.0 only in terms of bug fixes.

Yes, bug fixes and minor enhancements or changes.
Only critical bug fixes in the release branches.

It would be possible to add new modules
(which work with the existing libraries),

-> minor enhancements

but I would suggest that developers work on the next major version instead.

That is what the grass51 tree is for.

[Bernhard_Reiter]

On Tue, Apr 23, 2002 at 04:59:54PM +0000, Carl Worth wrote:

I didn't advocate this in my original post, since I was trying to
stake out a moderate position without revamping everything about how
GRASS is being developed currently.

The fact is, when a developer sits down to write a piece of code, it's
impossible to predict a completion schedule, (especially the relative
schedule compared to other developers --- some of who may not yet be
on the project).

The answer is impossible to predict. Hence, it's very dangerous
to attach version numbers to things before they are released,

This is why we did the most pragmatic thing first which is very
important for users: (Most user do not know open development
principles yet.)

  Open two version lines.
  We need this to so that people can decide between
  these principle differences.

Instead of using a number like 5.1, (even an odd number), when doing
parallel development, it seems it would be better to name the
functionality being explored, (eg. database_backed_vector_engine or
whatever). And, as I put forth in my previous mail, such named
experimentation belongs in a branch rather than a separate module.

I agree with the idea: It is modularisation.
Usually I would agree with your proposal, too,
but I've come to know more about GRASS development.

Believe me CVS and branches are a bigger problem for GRASS developers
as you might think. I can understand this, because it is difficult
and can be cumbersome at times. It is only natural that people which
do not feel too comfortable with CVS do not proudly claim that they
haven't fully mastered it, too.

So, those are my thoughts on where we should ideally be some day.
Plans for moving from where we are today may have other more
pragmatic considerations, (though generally, when making big
improvements -- even painful ones -- sooner is generally better than
later).

Carl:
It is great that you are willing to help.
GRASS will certainly benefit.

As a project it is quite unique, we are matching a broader range
of people in a huge project. Users and developers.
We have to be careful.

[Bernhard_Reiter]

On Tue, Apr 23, 2002 at 04:37:53PM +0000, Carl Worth wrote:

So, you can take my post as food for thought and we can revisit this
again when the time is right.

Great!

PS. I will respond in line to a few points, but we probably don't need
too much more discussion.

I know it was messier before. When I first tried GRASS I was extremely
confused as I was using the head and it was broken in several ways
that no one on the list could explain, (since they were all off on
some branch).

This did not work out as planned.
As you can see developers had to adjust to CVS.
One problem was, that we never released it and people
were not sure enough about using the branch.

This is a reason why I'm pushing the release and more strict checking.

Ah, but there is renaming. There are web pages now that say:

  grass50 (stable tree)
  grass51 (experimental/development tree)

All such references will have to be chased down and fixed to make the shift.

That's peanuts.
We have to inform people about what is going on anyway.
I hope when more people help with the webpages, we get more dynamic.
(wait a second)

  THIS _is_ A CALL for HELP with DOCUMENTATION and communication.

(sorry, had to be done )

Just check a project like Abiword,
which does a lot to inform people (weekly reports, bug votes...)
It is really appreciated. We need to find people to organise this for GRASS.

(This is another reason to work with more structure,
we look cleaner.)

> On the other hand, directory reorganisation within a tree
> with CVS is difficult, we had to use subversion or other revision
> control system for this.

Directory reorganization is painful, yes. But it is not really much
easier to reorganize the code and add it to a new module than to
reorganize it "in place" within one module.

With grass51 we can be more radical.
We will cut in the repository directly or set it up freshly if needed.
There is no other way with CVS' limited abilities.
Masterplans probably do not work.

For example, grass51 still doesn't have most of the code moved over. I
think this is because restructuring the organization of something as
large as the GRASS code is fundamentally hard.

Yes, but also because developers concentrate more on getting
at least _one_ stable release out.

The extra burden of a
few "cvs remove; cvs add" commands is really in the noise compared to
the real work that needs to be done.

I agree, but now we can play.
If you are willing do to it, you can just move over stuff
without having the big consensus first.
We can only learn in the process.

We do not want to mess up the grass5 tree with this.

> Looses history and is complicated.
I don't see how there is any history loss here.

I take this back partly was a bit beside the point anyway.

But, at the same time, the majority of the GRASS development community
doesn't need much parallel development.

Right now, we do.
Did I tell you about the _very_ conservative user base.

I think I'll be wanting to make some posts about how to tackle certain
aspects of the reorganization, (after I digest what's already written
up).

Is this list the correct venue for such discussion? I don't want to
muddle the work on getting the release done.

It is the right place.
If you massively get active we can think about an additional list.
I think this can take a bit more.

[Carl_Worth]

On Apr 23, Bernhard Reiter wrote:
> Carl:
> It is great that you are willing to help.
> GRASS will certainly benefit.

Thanks. I hope so.

> As a project it is quite unique, we are matching a broader range
> of people in a huge project. Users and developers.
> We have to be careful.

I can appreciate that. I do realize that the diverse nature of GIS
applications gives GRASS a very broad audience, (with primarily
non-programmers I would imagine -- many of which probably end up
having to do some programming to get the job done).

I hope I didn't come across as blazing in here trying to upheave the
hard work that many have put into making things functional. My
congratulations to all! GRASS is a huge and complex system and it is
wonderful that it works as well as it does.

I did want to forestall some potential problems before they got worse
though.

I'm willing to follow group consensus and go along with systems that
are already in place so that we can all get some important work done.

So, with that, I'm willing to put effort into making the grass51 tree
very good. I've seen lots of redundant code in GRASS that I want to
refactor into shared modules/libraries. I've seen several problems
with artificial hard-coded limits that I would like to eliminate.

I have a lot of ideas for exploring with GRASS and I'm glad to have an
area like the grass51 module where I can explore and rip things apart
without impacting those who are trying to make a release.

But, on the flip side, if I start copying modules over into the
grass51 directory, there are two immediate concerns:

  1) Each file will thereafter be forked. If new changes are
           made within the grass module, then grass51 will be missing
           them.

  2) All history will be lost as files are copied from grass
           over to grass5.

Maybe the GRASS development community accepts both of these as
necessary evils and acceptable since the code needs to be changed so
much anyway?

If so, I'll forge ahead. But, I tend to be very careful before
creating forked development paths like this.

-Carl

[Bernhard_Reiter]

On Tue, Apr 23, 2002 at 06:09:18PM +0000, Carl Worth wrote:

On Apr 23, Bernhard Reiter wrote:

> As a project it is quite unique, we are matching a broader range
> of people in a huge project. Users and developers.
> We have to be careful.

I can appreciate that. I do realize that the diverse nature of GIS
applications gives GRASS a very broad audience, (with primarily
non-programmers I would imagine -- many of which probably end up
having to do some programming to get the job done).

Very true.

So, with that, I'm willing to put effort into making the grass51 tree
very good. I've seen lots of redundant code in GRASS that I want to
refactor into shared modules/libraries. I've seen several problems
with artificial hard-coded limits that I would like to eliminate.

Hurray!
This is much needed.

I have a lot of ideas for exploring with GRASS and I'm glad to have an
area like the grass51 module where I can explore and rip things apart
without impacting those who are trying to make a release.

I think you see the point.
If you are getting too experimental at some points,
we still might thing about using branches on grass51.

But, on the flip side, if I start copying modules over into the
grass51 directory, there are two immediate concerns:

  1) Each file will thereafter be forked. If new changes are
           made within the grass module, then grass51 will be missing
           them.

True. We have to track what is going on in the grass5 tree a bit.
Most content like changes will be easy to pull over.

  2) All history will be lost as files are copied from grass
           over to grass5.

If you not the revision, it still can be tracked.
But not as easily with automatic tools as before.

Maybe the GRASS development community accepts both of these as
necessary evils and acceptable since the code needs to be changed so
much anyway?

I see no other alternative.

If so, I'll forge ahead.

Please carefully do.

But, I tend to be very careful before
creating forked development paths like this.

Another danger is that too many experiments will change the
character of GRASS too much. Some consensus on the list seems to be
that GRASS should mostly keep its character and some best practice.

For example, we think the programming language for the core is C so far.

[Frank_Warmerdam]

Bernhard Reiter wrote:

2) All history will be lost as files are copied from grass
          over to grass5.

If you not the revision, it still can be tracked.
But not as easily with automatic tools as before.

Bernhard,

If the majority of moving stuff to the 5.1 tree is done in one big batch,
can't someone at Intevation just do the copying by copying over the ,v files
from the old tree to the appropriate location in the new tree thereby
preserving all the history?

It would be a pity to lose all the history, especially since we don't keep
log entries in the code.

Best regards,

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

[Glynn_Clements]

Carl Worth wrote:

I have a lot of ideas for exploring with GRASS and I'm glad to have an
area like the grass51 module where I can explore and rip things apart
without impacting those who are trying to make a release.

A couple of notes:

1. You aren't the only one with plans to rip things apart.

2. One of GRASS' fundamental problems has been a tendency to code
stuff without adequately considering overall design issues first.

Please keep the other developers in the loop.

--
Glynn Clements <glynn.clements@virgin.net>

[Bernhard_Reiter]

On Tue, Apr 23, 2002 at 02:23:17PM -0400, Frank Warmerdam wrote:

Bernhard Reiter wrote:
>> 2) All history will be lost as files are copied from grass
>> over to grass5.
>
>
>If you not the revision, it still can be tracked.
>But not as easily with automatic tools as before.

If the majority of moving stuff to the 5.1 tree is done in one big batch,

It probably isn't.

can't someone at Intevation just do the copying by copying over the ,v files
from the old tree to the appropriate location in the new tree thereby
preserving all the history?

We possibly could if we really need it. I advise against it, though.
Not all files will just be copied, but have parts reassembled.

It would be a pity to lose all the history, especially since we don't keep
log entries in the code.

We will not loose the history.
When importing a file you should note where it was taken from
in the grass5 tree.

It is my experience that after a major revision
detailed information about each revision is wanted in rare cases.
It will be feasble to ask the grass5 tree about it then.