On Tue, Apr 23, 2002 at 09:34:24PM +0100, Glynn Clements wrote:
Bernhard Reiter wrote:
> Glynn, is it possible for you to create a release branch in the next days?
> You seem to have a good overview about what you can call compileable.
>
>
> Calling it something like
> releasebranch_24_April_2002_5_0_0
> seems to be consistant with what we've used before.
Sure.
Thanks.
Just say when.
Let's give Michel and Radim a chance to answer.
You can start preparations as long as you take in account
that they might have changes that have to go in later.
On Tue, Apr 23, 2002 at 10:28:08PM +0200, Bernhard Reiter wrote:
[...]
Glynn, is it possible for you to create a release branch in the next days?
You seem to have a good overview about what you can call compileable.
Code being compileable should not be the decision (then we get a lot
of rubbish inside). Please let's orientate on the last release branch
which was not that bad (in terms of the modules included).
Markus
On Apr 23, Bernhard Reiter wrote:
> Calling it something like
> releasebranch_24_April_2002_5_0_0
> seems to be consistant with what we've used before.
This is consistent, but is it necessarily useful? Specifically, does
the presence of the date serve any useful purpose? The presence of the
date in the tag makes it very hard to predict/remember the name of the
tag.
Without the date, it would be quite easy to remember how to checkout
the branch for a given release branch, for example:
cvs -r releasebranch_5_0_0
One might even go so far as to strip it down to branch_5_0_0, (which
would still preserve room in the tag namespace for a later
release_5_0_0 tag along that branch).
-Carl (who seems to stick his nose into everything CVS today) 
--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725
On Tue, Apr 23, 2002 at 09:20:57PM +0000, Carl Worth wrote:
On Apr 23, Bernhard Reiter wrote:
> Calling it something like
> releasebranch_24_April_2002_5_0_0
> seems to be consistant with what we've used before.
This is consistent, but is it necessarily useful? Specifically, does
the presence of the date serve any useful purpose? The presence of the
date in the tag makes it very hard to predict/remember the name of the
tag.
Without the date, it would be quite easy to remember how to checkout
the branch for a given release branch, for example:
cvs -r releasebranch_5_0_0
We already had this as non-branch tag.
Its was already (ab)used.... 
On Tue, Apr 23, 2002 at 11:07:18PM +0200, Markus Neteler wrote:
On Tue, Apr 23, 2002 at 10:28:08PM +0200, Bernhard Reiter wrote:
[...]
>
> Glynn, is it possible for you to create a release branch in the next days?
> You seem to have a good overview about what you can call compileable.
Code being compileable should not be the decision (then we get a lot
of rubbish inside). Please let's orientate on the last release branch
which was not that bad (in terms of the modules included).
Yes this is the right approach.
My remark contained a bit of irony.
On Tue, Apr 23, 2002 at 11:00:23PM +0200, Bernhard Reiter wrote:
On Tue, Apr 23, 2002 at 09:34:24PM +0100, Glynn Clements wrote:
> Bernhard Reiter wrote:
> > Glynn, is it possible for you to create a release branch in the next days?
> > You seem to have a good overview about what you can call compileable.
> Sure.
> Just say when.
Let's give Michel and Radim a chance to answer.
Michel checked in stuff today.
So we are just waiting for Radim.
When he says he's done with d.zoom, you can go ahead.
Bernhard
Glynn,
please go ahead and create the release branch as soon
as you find time.
Everybody else: Please stop committing stuff on "grass" until Glynn is finished.
On Thu, Apr 25, 2002 at 12:02:51AM +0200, Bernhard Reiter wrote:
So we are just waiting for Radim.
When he says he's done with d.zoom, you can go ahead.
Radim did not answer email in the last two days.
Markus also did not answer today.
So we have to assume it will be fine and go ahead.
Bernhard Reiter wrote:
please go ahead and create the release branch as soon
as you find time.
Done: releasebranch_26_april_2002_5_0_0
--
Glynn Clements <glynn.clements@virgin.net>
On Fri, Apr 26, 2002 at 06:49:21PM +0100, Glynn Clements wrote:
Bernhard Reiter wrote:
> please go ahead and create the release branch as soon
> as you find time.
Done: releasebranch_26_april_2002_5_0_0
Thanks.
Okay. Please everybody please test the release branch as
we want to create 5.0.0pre4 tarball out of it.
Remember: Only critical bug fixing on the branch!
If you fix a bug on the branch,
you also are responsible to commit the same fix to the HEAD.
On Sat, Apr 27, 2002 at 12:45:24PM +0200, Bernhard Reiter wrote:
Okay. Please everybody please test the release branch as
we want to create 5.0.0pre4 tarball out of it.
Just removed the src.nonGPL from the release branch.
If we don't know if the software is compatible with the GNU GPL,
there is no point in releasing it.
Note: The software is still archived in HEAD.
Is there more that we should remove from this release branch,
because we do not want it the source tarball anyway?
Bernhard Reiter wrote:
> Okay. Please everybody please test the release branch as
> we want to create 5.0.0pre4 tarball out of it.
Just removed the src.nonGPL from the release branch.
If we don't know if the software is compatible with the GNU GPL,
there is no point in releasing it.
Note: The software is still archived in HEAD.
Is there any point in keeping it around? Will this code ever be used?
The COPYRIGHT file for the "optri" library clearly says
"non-commercial purposes".
--
Glynn Clements <glynn.clements@virgin.net>
On Sat, Apr 27, 2002 at 04:43:03PM +0100, Glynn Clements wrote:
Bernhard Reiter wrote:
> Just removed the src.nonGPL from the release branch.
> If we don't know if the software is compatible with the GNU GPL,
> there is no point in releasing it.
> Note: The software is still archived in HEAD.
Is there any point in keeping it around? Will this code ever be used?
The COPYRIGHT file for the "optri" library clearly says
"non-commercial purposes".
A good question.
In general it is better to keep some stuff before it is lost.
So we will keep it in the archives somewhere.
On the other hand I do not think it will make it into grass51.
We also might think about removing it from the current HEAD branch.
Additionally there might be some code in there that is only
partially non-free or depending on non-free code.
On Fri, Apr 26, 2002 at 06:49:21PM +0100, Glynn Clements wrote:
Bernhard Reiter wrote:
> please go ahead and create the release branch as soon
> as you find time.
Done: releasebranch_26_april_2002_5_0_0
Glynn, Bernhard,
just curious, did you somewhat consider the former release branch for
the selection of modules?
Eg. the G3D tools are inside which does not make much
sense except for s.vol.rst. Other modules I didn't
verify yet.
Then:
- how to handle NEWS.html? It will fork, right?
- how to handle the html/ files - we should delete all modules
descriptions not available in the release branch (also update
the related overview pages)
- more?
Am I right that a merge back won't happen this time? Otherwise
we would loose again new contributions to the development tree (HEAD).
Markus
On Mon, Apr 29, 2002 at 01:41:25PM +0200, Markus Neteler wrote:
On Fri, Apr 26, 2002 at 06:49:21PM +0100, Glynn Clements wrote:
just curious, did you somewhat consider the former release branch for
the selection of modules?
Eg. the G3D tools are inside which does not make much
sense except for s.vol.rst. Other modules I didn't
verify yet.
We still have to do this before we make the tarball.
You are the coordinator, we need your assistance with this.
Then:
- how to handle NEWS.html? It will fork, right?
Yes.
As I see it, this is the wanted behaviour, right?
- how to handle the html/ files - we should delete all modules
descriptions not available in the release branch (also update
the related overview pages)
I agree.
Though we can also agree to not put them in the tarball,
whatever creates less overhead work.
Am I right that a merge back won't happen this time?
This is the plan.
Otherwise we would loose again new contributions
to the development tree (HEAD).
We are not planing this, but if we did, this would be
a question of how to organise the merge.
Usually you do not loose anything with CVS.
On Mon, Apr 29, 2002 at 03:38:32PM +0200, Bernhard Reiter wrote:
On Mon, Apr 29, 2002 at 01:41:25PM +0200, Markus Neteler wrote:
> On Fri, Apr 26, 2002 at 06:49:21PM +0100, Glynn Clements wrote:
> just curious, did you somewhat consider the former release branch for
> the selection of modules?
>
> Eg. the G3D tools are inside which does not make much
> sense except for s.vol.rst. Other modules I didn't
> verify yet.
We still have to do this before we make the tarball.
You are the coordinator, we need your assistance with this. 
Ok - I'll delete modules if I come across.
> Then:
> - how to handle NEWS.html? It will fork, right?
Yes.
As I see it, this is the wanted behaviour, right?
Also ok.
> - how to handle the html/ files - we should delete all modules
> descriptions not available in the release branch (also update
> the related overview pages)
I agree.
Though we can also agree to not put them in the tarball,
whatever creates less overhead work.
The best would be to connect that to
src/CMD/lists/GRASS
So far I have no idea how to do that. Also the pages
html/*.html
should be generated automatically, based on what is found
in
html/html/
(which should be based for thr release branch on src/CMD/lists/GRASS).
Markus
On Mon, Apr 29, 2002 at 03:47:32PM +0200, Markus Neteler wrote:
Ok - I'll delete modules if I come across.
Fine.
> I agree.
> Though we can also agree to not put them in the tarball,
> whatever creates less overhead work.
The best would be to connect that to
src/CMD/lists/GRASS
So far I have no idea how to do that. Also the pages
html/*.html
should be generated automatically, based on what is found
in
html/html/
(which should be based for thr release branch on src/CMD/lists/GRASS).
It should bepossible to find a mechanism here,
which should make it easier for you and everybody to create
releasable tarballs from the CVS.
On Mon, Apr 29, 2002 at 03:53:06PM +0200, Bernhard Reiter wrote:
On Mon, Apr 29, 2002 at 03:47:32PM +0200, Markus Neteler wrote:
[html pages]
> The best would be to connect that to
> src/CMD/lists/GRASS
> So far I have no idea how to do that. Also the pages
> html/*.html
> should be generated automatically, based on what is found
> in
> html/html/
> (which should be based for thr release branch on src/CMD/lists/GRASS).
It should bepossible to find a mechanism here,
which should make it easier for you and everybody to create
releasable tarballs from the CVS.
Mhhh, I feel that we are talking about different things.
Creating releasable tarballs from the CVS is more or less
trivial when the release tag is applied.
Above I was refering to the HTML overview pages which require
more manual editing than necessary (I consider this a job to
be done by a clever script, it's always the same).
Markus
Markus Neteler wrote:
> > please go ahead and create the release branch as soon
> > as you find time.
>
> Done: releasebranch_26_april_2002_5_0_0
Glynn, Bernhard,
just curious, did you somewhat consider the former release branch for
the selection of modules?
Eg. the G3D tools are inside which does not make much
sense except for s.vol.rst. Other modules I didn't
verify yet.
I thought that we had agreed to include all of the code in the source
tarballs, but only enable working modules in src/CMD/lists/GRASS.
Then:
- how to handle NEWS.html? It will fork, right?
Yes.
- how to handle the html/ files - we should delete all modules
descriptions not available in the release branch (also update
the related overview pages)
AFAICT, this would have to be done manually.
The only real solution is to move the HTML files to the module
directories (which is where they *should* be, along with the
tcltkgrass "module" file, g.help file, etc). That way, the HTML and
manual pages would only be installed if the module itself is
installed.
- more?
Am I right that a merge back won't happen this time? Otherwise
we would loose again new contributions to the development tree (HEAD).
What purpose does the head serve now? Shouldn't ongoing development be
moving to 5.1?
--
Glynn Clements <glynn.clements@virgin.net>
Glynn Clements wrote:
> Eg. the G3D tools are inside which does not make much
> sense except for s.vol.rst. Other modules I didn't
> verify yet.
I thought that we had agreed to include all of the code in the source
tarballs, but only enable working modules in src/CMD/lists/GRASS.
please keep the G3D tools, they are needed for s.vol.rst even if
it is only outputing 2D file - the precipitation with topographic influence
works
in general but needs to be tested by wider users community. I think that we
should have in GRASS some capabilities which are not widely available
elsewhere, and s.vol.rst provides a little bit of that.
Helena
On Mon, Apr 29, 2002 at 04:48:39PM +0200, Markus Neteler wrote:
Above I was refering to the HTML overview pages which require
more manual editing than necessary (I consider this a job to
be done by a clever script, it's always the same).
Can you be more elaborate on what needs to be done.
Is this documented somewhere?