[GRASS-dev] too many branches

GRASS GIS GRASS GIS developer
1

Hi all,

even the GRASS website [0] gets confused about all those branches.
GRASS 6.4.3, the next stable release, is currently hidden under GRASS
6.4.2, current stable. Therefore there should be 4, not 3 sections:
6.4.2, 6.4.3, 6.5, 7.0. This is however IMHO too much, confusing for
users and a maintenance burden for developers. The purpose of the
existence of 6.5 is not clear to me, particularly since it is pretty
much identical to 6.4.3. Using 6.5 as testbed for backporting does not
make sense to me, I would prefer to use the current releasebranch as
testbed for backporting (higher quality, hopefully, and faster bug
fixing). IMHO, it would make maintenance much easier if one of 6.4 and
6.5 would go rather sooner than later.

Markus M

[0] http://grass.osgeo.org/download/software.php

2

Markus Metz wrote:

IMHO, it would make maintenance much easier if one of 6.4 and
6.5 would go rather sooner than later.

I absolutely and quite strongly disagree. It is invaluable to have
a staging area to test backports before putting them into the
stable branch, and trunk has diverged too far from 6.4 to allow
that to take the role.

We have experimental/trunk, limited testing for the stable branch,
and the final branch. Lately we've been pretty good about not
developing new code in devbr65, meaning clearer ideas about what
should be really backported into the 6.4 stable branch since
there is less noise.

We must -at all times- be ready to tag a new release from the
6.4 stable branch on very short notice. Partly in case a severe
data bug is found, but more critically if a license problem
turns up. If you get rid of your staging area it's impossible
to guarantee that the release branch will be at release quality
while bug fixes are being worked out and tested.

It also gives a chance for things which don't quite rise to the
level of "critical bugfix" to be left unshared. It's a *good*
thing that we can look through trac and pick and choose what
to actually put into 6.4.3.

if it helps:
To keep the merging burden low, I use a couple of tiny scripts
to make the merge command a trivial one liner. with the ending
of new development in 6.5svn this becomes even simpler.

svn65merge: run from trunk/ or relbr64/ dirs with rev # as
$ svn65merge 12345

#!/bin/sh
if [ $# -eq 1 ] ; then
  svn merge -c $1 https://svn.osgeo.org/grass/grass/branches/develbranch_6
else
  echo "usage: cd grass7; svn65merge rev_number"
fi

#####

svn64merge: same, for pulling from relbr64 into devbr6:

#!/bin/sh
if [ $# -eq 1 ] ; then
  svn merge -c $1 https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4
else
  echo "usage: cd grass65; svn64merge rev_number"
fi

#####

and finally svn7merge: for pulling from trunk into devbr6:

#!/bin/sh
if [ $# -eq 1 ] ; then
  svn merge -c $1 https://svn.osgeo.org/grass/grass/trunk
else
  echo "usage: cd grass65; svn7merge rev_number"
fi

#####

best,
Hamish

(sorry I haven't been able to help much with the latest push,
I'm juggling 4 other deadlines right now; I'll jump in as soon
as I can)

3

On Wed, Aug 22, 2012 at 12:39 PM, Hamish <hamish_b@yahoo.com> wrote:

Markus Metz wrote:

IMHO, it would make maintenance much easier if one of 6.4 and
6.5 would go rather sooner than later.

I absolutely and quite strongly disagree. It is invaluable to have
a staging area to test backports

Here I have severe doubts that this happens. Can you demonstrate
that things are significantly tested? I don't see this.

Here your promised backports, all TODO:
https://trac.osgeo.org/grass/ticket/192
http://trac.osgeo.org/grass/ticket/1690
http://trac.osgeo.org/grass/ticket/91
http://trac.osgeo.org/grass/ticket/1513
http://trac.osgeo.org/grass/ticket/1315
http://trac.osgeo.org/grass/ticket/1312
http://trac.osgeo.org/grass/ticket/1142
https://trac.osgeo.org/grass/ticket/335

If these backports never happen (I cannot take care of all of them)
then 6.5 is superfluous.

Furthermore:
http://trac.osgeo.org/grass/ticket/173
http://trac.osgeo.org/grass/ticket/175
https://trac.osgeo.org/grass/ticket/778

MarkusN

4

Hi,

2012/8/22 Hamish <hamish_b@yahoo.com>:

Markus Metz wrote:

IMHO, it would make maintenance much easier if one of 6.4 and
6.5 would go rather sooner than later.

I absolutely and quite strongly disagree. It is invaluable to have
a staging area to test backports before putting them into the
stable branch, and trunk has diverged too far from 6.4 to allow
that to take the role.

well, the real point is that we should focus our energy on GRASS 7
development, and not playing with GRASS 6 as we do now. Is there any
comparison of devbr6 a relbr64? I am pretty sure that many changes,
fixes which has been committed to devbr6 were not applied later in
relbr64. It's too time/energy consuming for so small dev team to
maintain so many branches.

It's really time to focus on grass7 (if we really want to release this
version in reasonable time, less then one year or so). I fully agree
with MarkusM, it's time to kill devbr6.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

5

Markus M wrote:

IMHO, it would make maintenance much easier if one of 6.4
and 6.5 would go rather sooner than later.

Hamish:

> I absolutely and quite strongly disagree. It is invaluable
> to have a staging area to test backports

Markus N:

Here I have severe doubts that this happens. Can you
demonstrate that things are significantly tested?

Sure, just in the fact that they've been in 6.5svn for that
long without further problems. If it was going to break something
on Windows or Macs which I haven't tested on, there's a rather
good chance that we'd hear about it. For my part, I *only*
backport stuff to 6.4.x which I am 100% satisfied with and
confident in. If I am in anyway unsure of a change, especially
if it is just to fix a small or abstract bug, I much prefer
to have it mature in 6.5svn for a while until it has achieved
some history of not destroying people's data. If there is a
nasty bug I usually would not wait.

Here your promised backports, all TODO:

if you're grumpy with me for not backporting stuff, be grumpy
with me for being distracted; it's not the branch's fault. :slight_smile:

https://trac.osgeo.org/grass/ticket/192
http://trac.osgeo.org/grass/ticket/1690
http://trac.osgeo.org/grass/ticket/91
http://trac.osgeo.org/grass/ticket/1513
http://trac.osgeo.org/grass/ticket/1315
http://trac.osgeo.org/grass/ticket/1312
http://trac.osgeo.org/grass/ticket/1142
https://trac.osgeo.org/grass/ticket/335

I'll have a look at these as soon as I am able.

If these backports never happen (I cannot take care of all
of them)

I don't ask you to take care of them, in fact I'm sure you have
better things to do and I would not ask you to, but if there is
any ticket that I should be taking care of and seem to have
forgotten, feel free to re-assign it to me in trac (or not, and
wait for my next trawl through the trac & RT lists, they do
happen).

If a known bug fix doesn't get into the next release, yes,
that's not nice for the end users, it's good we have trac to
keep us organized in that regard. If a half-baked fix gets into
6.4, then that's worse IMO as it threatens our super-stable
reputation and goals.

Furthermore:
http://trac.osgeo.org/grass/ticket/173
http://trac.osgeo.org/grass/ticket/175
https://trac.osgeo.org/grass/ticket/778

I'll look at those too, but I'm going to be off the radar for
a few more days yet.

thanks,
Hamish

6

Martin Landa wrote:

>> IMHO, it would make maintenance much easier if one of 6.4 and
>> 6.5 would go rather sooner than later.
>
> I absolutely and quite strongly disagree. It is invaluable to have
> a staging area to test backports before putting them into the
> stable branch, and trunk has diverged too far from 6.4 to allow
> that to take the role.

well, the real point is that we should focus our energy on GRASS 7
development, and not playing with GRASS 6 as we do now. Is there any
comparison of devbr6 a relbr64? I am pretty sure that many changes,
fixes which has been committed to devbr6 were not applied later in
relbr64. It's too time/energy consuming for so small dev team to
maintain so many branches.

It's really time to focus on grass7 (if we really want to release this
version in reasonable time, less then one year or so). I fully agree
with MarkusM, it's time to kill devbr6.

+1.

If a change is too invasive to go into the 6.4 branch, it belongs on
the 7.0 trunk.

--
Glynn Clements <glynn@gclements.plus.com>

7

Markus N wrote:

Can you demonstrate that things are significantly tested? I
don't see this.

a good example perhaps is the parallelization work that has gone
into i.landsat.rgb and other shell scripts (in parallel with the
python scripts in trunk).

this is something which will be very useful for 6.4 users to have
access to, but was introduced too late in the cycle to go into
6.4.3 with any confidence. ok, it doesn't pass the critical bug
fix test, but a 4-6x speed up in a module is to be taken seriously. better that it sees some air in svn and shares the
method than sit invisible on my local hard drive.

another example I go back to all the time in my mind when thinking
about stable software is a time some years ago when I used the
release branch version of r.sun instead of the dev branch version
in an effort to use only tested code in production runs. It turns
out after a couple of months a new bug was found in the new
development branch code, and fixed before the next stable release
went out with the otherwise improved code. That choice literally
saved me more than a month's worth of work when on a tight
deadline, and was a lesson that sticks with me quite strongly.

thanks,
Hamish

8

On Wed, Aug 22, 2012 at 1:28 PM, Hamish <hamish_b@yahoo.com> wrote:

Markus M wrote:

IMHO, it would make maintenance much easier if one of 6.4
and 6.5 would go rather sooner than later.

Hamish:

> I absolutely and quite strongly disagree. It is invaluable
> to have a staging area to test backports

Markus N:

Here I have severe doubts that this happens. Can you
demonstrate that things are significantly tested?

Sure, just in the fact that they've been in 6.5svn for that
long without further problems.

I see two possibilities:
- you are right
- or nobody really uses it.

..

if you're grumpy with me for not backporting stuff, be grumpy
with me for being distracted; it's not the branch's fault. :slight_smile:

I am not grumpy with you - for me it indicates that the
concepts starts to fail. All these tickets look more like
forgotten than waiting for improvements (some are tiny
changes only).

MarkusN

9

Martin wrote:

well, the real point is that we should focus our energy on
GRASS 7 development, and not playing with GRASS 6 as we do
now.

er, we _are_ focusing our energy on GRASS 7 development... ?

and we absolutely should pick and choose which /tested/ bug
fixes go in to the next 6.4.x stable release, from a close by
code base.

Is there any comparison of devbr6 a relbr64? I am pretty sure
that many changes, fixes which has been committed to devbr6
were not applied later in relbr64.

very serious question: does it matter? if it is a serious bug
fix then sure it should make it into the release branch, and
if it diverges too far from 6.4 and is not intended to be
backported, then it arguably shouldn't have been put in there,
but if it is just sitting there collecting dust and not doing
anyone harm, who cares? if it is important enough it'll get
where it needs to be. If not, let it collect dust & not hurting
anyone.

It's too time/energy consuming for so small dev team to
maintain so many branches.

from my POV it's no trouble at all. I've always been of the
mind that devbr6 should only exist in svn, no need for nightly
snapshots or automated builds; although I have to admit that
those extras have found bugs quickly and have allowed us to get
bug reports from users who would never have checked out code from
svn and built it themselves before the thing made it into 6.4.
If just a single link to the 6.5 svn remained on the download
page I would not be sad.

It's really time to focus on grass7

besides some maintenance release work for the stable branch right
now, AFAICT we _are_ focusing development on trunk. And if 1 dev
wants to spend their time working on old 5.x code or whatever, so
what? It's their time not anyone else's.

(if we really want to release this version in reasonable time,
less then one year or so).

have we set release goals? e.g. is the LGPL IO lib for GDAL
going to happen to allow us to rework the raster directory
layout for grass 7.

I fully agree with MarkusM, it's time to kill devbr6.

If it gets to the point where I have to fork a copy of devbr6
onto github because it is still useful to me, well that's such
a level of dysfunctionality and craziness that I don't even
want to think about it much. I don't understand why 6.5 just
can't be left to slowly fade away like the 5.5 devbr was & still
is.

Glynn:

If a change is too invasive to go into the 6.4 branch, it
belongs on the 7.0 trunk.

AFAIK we don't have anything like that happening. Asking code
to be perfect the moment it gets backported from trunk to the
release branch is a bit much IMO. And AFA I'm concerned, we
should only apply rock solid code to 6.4 branch, and devbr6
gives us a little breathing space.

thanks,
Hamish

10

Markus N wrote:

All these tickets look more like forgotten than waiting for
improvements (some are tiny changes only).

Don't worry, I will try to unforget them :slight_smile:

Hamish
(who just this week exceeded 20k unread non-spam emails in his
ML inbox.. better to try and do too much than too little though :slight_smile:

11

even the GRASS website [0] gets confused about all those branches.
GRASS 6.4.3, the next stable release, is currently hidden under GRASS
6.4.2, current stable. Therefore there should be 4, not 3 sections:
6.4.2, 6.4.3, 6.5, 7.0. This is however IMHO too much, confusing for
users and a maintenance burden for developers.

in (my) users point of view I'm interested in two grass-lines, a stable one
(6.4.x) and a upcoming cutting edge (7.x) seems to be enough for me.

sometime I'm testing wingrass on the windows side of the computer world and
I'm loosing from time to time the overview where I can find what (fixes,
improvements, etc.): wingrass64x, wingrass6devbr or wingrass7.

a few times I'm asked by completely new wingrass-users which versions should
be used, then I recommend only 6.4.x and for a technology preview 7. why
should they starting with 6devbr?

just my 0,02 cents
Helmut

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/too-many-branches-tp4996931p4997022.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

12

2012/8/22 Hamish <hamish_b@yahoo.com>:

er, we _are_ focusing our energy on GRASS 7 development... ?

just check new features implemented in grass7 and you will find out
who from developers is focused on grass7. If _we_ would be really be
focused on grass7, this version would be probably already released,
after 4 years of development, we can hardly say when this version will
be released and which fundamentally new features is going to be
implemented in the next months (who knows about major refactoring
2D/3D raster libs).

Is there any comparison of devbr6 a relbr64? I am pretty sure
that many changes, fixes which has been committed to devbr6
were not applied later in relbr64.

very serious question: does it matter? if it is a serious bug

yes it is, we lost track what is in devbr6, what is going to be
backported, what we forgot to backport. This is serious point, if you
think it doesn't matter, then I am starting to understand why you want
to keep devbr6 alive :wink:

[...]

I have nothing more to say about that, Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

13

On Wed, Aug 22, 2012 at 3:07 PM, Martin Landa <landa.martin@gmail.com> wrote:

2012/8/22 Hamish <hamish_b@yahoo.com>:

Is there any comparison of devbr6 a relbr64?

Yes:
diff -ru --exclude=".svn" grass64_release grass65_release

To even exclude the timestamp differences in the HTML pages:
diff -ru --exclude=".svn" --exclude=".html" grass64_release
grass65_release | wc -l
856878

Not really the same :slight_smile:

I am pretty sure
that many changes, fixes which has been committed to devbr6
were not applied later in relbr64.

very serious question: does it matter? if it is a serious bug

Yes: most tickets I have indicated earlier which contain a backport
promise are relevant.

I have gone before every GRASS 6 release through this branch
differences. It took me every time days. And I start to not have
that time any more to catch up with incomplete tickets... (see above).

And yes, energy should go of course into GRASS 7.

MarkusN

14

2012/8/22 Martin Landa <landa.martin@gmail.com>:

2012/8/22 Hamish <hamish_b@yahoo.com>:

er, we _are_ focusing our energy on GRASS 7 development... ?

just check new features implemented in grass7 and you will find out
who from developers is focused on grass7. If _we_ would be really be

I have a clear focus on grass7 and do not backport any new features or
code reviews i introduce in grass7 to
grass6 branches by intention. :slight_smile:
All additional projects that i am developing (wps and vtk bridges,
tag2e) are based on grass7.

The grass6 test suite that i have implemented is not maintained any
more, but available here:
http://code.google.com/p/grass6-test-suite/
It can still be used to improve stability and maintainability of
grass6 ... but must be updated to use new/renamed options and flags
that have been introduced to several modules.

IMHO for the sake of maintainability and stability of grass7: we all
should implement tests for existing, modified and new modules and
libraries. I try this with most of the module and libraries i maintain
(gpde, gmath and g3d libraries, 3D raster and temporal modules, Python
temporal GIS library) ... but that's not enough.
Unfortunately, the module and library test suite we discussed at the
code sprint in Prague 2011 is still in a conceptional state ... .

But most of the Python code in grass7 outside of modules (lib/python
and GUI) can be tested with doctests and unit tests. Please consider
Pietro's really nice doctests in the GSoC pygrass project. With
pygrass we can directly tests raster and vector library functions,
several tests are already available.

Just my 2 test cents

Best regards
Soeren

15

Hi,

2012/8/22 Sören Gebbert <soerengebbert@googlemail.com>:

just check new features implemented in grass7 and you will find out
who from developers is focused on grass7. If _we_ would be really be

I have a clear focus on grass7 and do not backport any new features or

[...]

I didn't what to note any names. I am sure that everyone is doing his
best. It's free software :wink: Yeap, Soeren is one of the most active
grass7 devs :slight_smile:

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

16

After reading through the entire discussion I think even Hamish would agree that there is a broad consensus
that the number of branches needs to be reduced (as I read it, it should be grass64 and grass7)
and the sooner it is done, the fewer problems and confusion there will be.

It should also make it easier to test (I have 4 versions 6.4.2, 6.4.3, 6.5, 7.0 on my machine and to be honest, I am not sure
what works in which version, but lately I have been using GRASS7 a lot so a release in near future would be welcome).

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu

"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”

On Aug 22, 2012, at 3:57 AM, Markus Metz wrote:

Hi all,

even the GRASS website [0] gets confused about all those branches.
GRASS 6.4.3, the next stable release, is currently hidden under GRASS
6.4.2, current stable. Therefore there should be 4, not 3 sections:
6.4.2, 6.4.3, 6.5, 7.0. This is however IMHO too much, confusing for
users and a maintenance burden for developers. The purpose of the
existence of 6.5 is not clear to me, particularly since it is pretty
much identical to 6.4.3. Using 6.5 as testbed for backporting does not
make sense to me, I would prefer to use the current releasebranch as
testbed for backporting (higher quality, hopefully, and faster bug
fixing). IMHO, it would make maintenance much easier if one of 6.4 and
6.5 would go rather sooner than later.

Markus M

[0] http://grass.osgeo.org/download/software.php
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

17

Hamish wrote:

e.g. is the LGPL IO lib for GDAL going to happen to allow us to
rework the raster directory layout for grass 7.

I wouldn't hold your breath on that one.

In order to safely exorcise the GPL, the job needs two people. One who
can write the code for GDAL without looking at the GRASS code, and one
to provide specifications and clarifications based upon the GRASS
code. I can do one of those (preferably the latter, as I've been
involved in most of the substantial raster I/O changes since 6.0 and
maybe earlier), but the other post remains unfilled after ~4 years.

Glynn:
> If a change is too invasive to go into the 6.4 branch, it
> belongs on the 7.0 trunk.

AFAIK we don't have anything like that happening. Asking code
to be perfect the moment it gets backported from trunk to the
release branch is a bit much IMO. And AFA I'm concerned, we
should only apply rock solid code to 6.4 branch, and devbr6
gives us a little breathing space.

The breathing space is provided by the fact that the branch is a
branch, not a release. So long as people don't back-port code a few
days before the branch is due to be tagged for release, there
shouldn't be a problem.

Right now, we offer four levels of stability: 6.4.2, 6.4 branch, 6.5
branch, 7.0 trunk. We could afford to lose the 6.5 branch; 6.4 ought
to be stable enough for a branch.

Anyone running code from a branch has to be willing to deal with the
possibility that they might grab the version immediately after a bad
commit. If they can't, they should be using a release rather than a
branch.

The presence of 6.5 doesn't eliminate the possibility of a bad commit
to 6.4. It doesn't necessarily even reduce it all that much.

If bug-fixes get back-ported to 6.5, then to 6.4 shortly thereafter,
any mistakes are more likely to be found once they reach 6.4 than in
the short time that they live on 6.5, getting tested by a handful of
users (there isn't much incentive to run 6.5 if it's just 6.4 with a
slightly increased chance of bugs).

OTOH, if there are more substantial differences between 6.4 and 6.5,
then a successful fix in 6.5 is no guarantee of success in 6.4.

--
Glynn Clements <glynn@gclements.plus.com>

18

Markus M:

My :wink: was kind of a teaser. I regard 6.4.svn as more stable than
6.4.2.

I don't think it matters much, but for the purposes better discussion
I think it's worth pointing out that I am perhaps using a slightly
different definition of "stable" than you. To me, "stable" includes
well tested, bugs (and perhaps work arounds) are known. Untested code
with bug fixes applied is to me less stable, and I would not give it to
a new user or use in a production environment since it hasn't been through
the same QA labors. That's not to say that either definition is better
than the other, or others should make recommendations following my thoughts
on the matter, just the definition from the POV I'm looking at it from.

You said that there is no stable 6.4.3 that a user could see.
[This is directed at all other devs:] Then we should make sure that
there is a stable 6.4.3 that a user could see.

[devil's advocate] .. why not just do away with releases then and promote
the nightly builds as a rolling release?
[no, I'm not really suggesting that]

but really, for the stable release I'd be happy to see monthly releases
to add in new bug fixes (but only bug fixes :), subject to longer or
shorter cycles depending on how important the bugs found in that cycle were,
eventually trailing off to infinity like 5.4.x.

I was under the assumption that there were no major bugs in 6.4.2, so
hadn't been too worried that it has taken a bit longer. I had hoped the
broken addons repo for the MS Windows version could be taken care of by
a quick 6.4.2-3_setup.exe rebuild, but that didn't happen.

The news that there was a flaw in the wxGUI is news to me in the last
few days, and I would have pushed for a smaller-but-faster 6.4.3 release
sooner if I had realized that there were important bugs holding people
back.

At the the very least, please release 6.4.3rc1 before yesterday
(commonly used deadline definition).

anyone have ideas on this one?
#1692 calling a script within a script failing on Windows XP
v.db.* and lots of other fail.

wrt blockers, I'd take the stance that it just has to be less-broken
than 6.4.2, releasing a 6.4.3 with known flaws that were also in 6.4.2
is not the end of the world, but it is useful to harness the pre-release
energy to try and fix such things.

I'll note that I had been using devbr6 for experiments and adding debug
messages in ways I'm not comfortable doing in the 6.4 release branch to
investigate this particular bug (hmm, actually it might have been the
clean_temp.exe bug. no matter). Then I'd wait for the next nightly build,
test, and repeat.

Helena:

After reading through the entire discussion I think even Hamish would
agree that there is a broad consensus that the number of branches needs
to be reduced (as I read it, it should be grass64 and grass7)

There is no support for that from me. Devbr6 (I'll try to stop calling it
6.5svn, we had a discussion about that months ago) is highly useful to me,
I use it almost every day, and I'd be very upset and inconvenienced if it
were removed from svn. It has maturing code aimed for future stable releases
beyond the immediate next one, and backporting fixes from trunk directly
is not always a trivial task. (e.g. see r52853)

and the sooner it is done, the fewer problems and confusion there will be.

please, just let it slip away into old age and irrelevance in peace like
devbr5_5 ...

I think too much is being made of it, primarily because have been distracted
by other work and left small bugfixes too long waiting to be backported,
which accounts to many of the 'problems' -- the gardening I'd quietly been
doing there had been left unattended for while and started to fall on other
people. In general I am quite happy to volunteer to maintain the stable
branch(es), even if I have to do that alone, but from time to time the day
job and real life pull me away so it is not always as immediate as I'd like.

wrt the 'confusion' issue, I fully agree that the downloads page should be
cleaned up, and 6.5 de-emphasized there to a single line. I'd already added
discouraging "(restricted development; testbed for backporting, ... Utility
version for developers." text to it, and would not at all mind its table
being reduced to a simple link to
  http://trac.osgeo.org/grass/wiki/DownloadSource#GRASS6.5

even though, as mentioned above, the nightly Windows builds of it have
helped me to work on bugs in 6.4 in the past, in an environment where I
could experiment safely.

As for releasebranch_6_4 (calling it 6.4.3 is confusing I think), IM 2c O
that should also be a one-liner on the download page, but if there are
pending (important) bug fixes we should aim for minimal-change monthly
releases, instead of long waits between big releases and then higher-
stress to get them out the door.

wrt cutting a release branch for trunk, IMO to avoid double merging that
should wait as long as possible until we have identified release goals
and are nearing the bug-fixes-only stage. Even then we can rely on personal
discipline for a time instead of needing a special branch.

thanks,
Hamish

ps- hot off the press, checkitout: http://live.osgeo.org

19

+1

Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb@fws.gov

The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.

Helena Mitasova <hmitaso@ncsu.edu>
Sent by: grass-dev-bounces@lists.osgeo.org

08/22/2012 07:11 PM

To

GRASS developers list <grass-dev@lists.osgeo.org>

cc

Markus Metz <markus.metz.giswork@gmail.com>

Subject

Re: [GRASS-dev] too many branches

After reading through the entire discussion I think even Hamish would agree that there is a broad consensus
that the number of branches needs to be reduced (as I read it, it should be grass64 and grass7)
and the sooner it is done, the fewer problems and confusion there will be.

It should also make it easier to test (I have 4 versions 6.4.2, 6.4.3, 6.5, 7.0 on my machine and to be honest, I am not sure
what works in which version, but lately I have been using GRASS7 a lot so a release in near future would be welcome).

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu

"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”

On Aug 22, 2012, at 3:57 AM, Markus Metz wrote:

> Hi all,
>
> even the GRASS website [0] gets confused about all those branches.
> GRASS 6.4.3, the next stable release, is currently hidden under GRASS
> 6.4.2, current stable. Therefore there should be 4, not 3 sections:
> 6.4.2, 6.4.3, 6.5, 7.0. This is however IMHO too much, confusing for
> users and a maintenance burden for developers. The purpose of the
> existence of 6.5 is not clear to me, particularly since it is pretty
> much identical to 6.4.3. Using 6.5 as testbed for backporting does not
> make sense to me, I would prefer to use the current releasebranch as
> testbed for backporting (higher quality, hopefully, and faster bug
> fixing). IMHO, it would make maintenance much easier if one of 6.4 and
> 6.5 would go rather sooner than later.
>
> Markus M
>
>
> [0] ``http://grass.osgeo.org/download/software.php
> _______________________________________________
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> ``http://lists.osgeo.org/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

20

Hamish wrote:

> My :wink: was kind of a teaser. I regard 6.4.svn as more stable than
> 6.4.2.

I don't think it matters much, but for the purposes better discussion
I think it's worth pointing out that I am perhaps using a slightly
different definition of "stable" than you. To me, "stable" includes
well tested, bugs (and perhaps work arounds) are known. Untested code
with bug fixes applied is to me less stable, and I would not give it to
a new user or use in a production environment since it hasn't been through
the same QA labors. That's not to say that either definition is better
than the other, or others should make recommendations following my thoughts
on the matter, just the definition from the POV I'm looking at it from.

The terms "stable" and "unstable" normally refer to the likely extent
of any future changes. Any fixed release is perfectly "stable",
regardless of the quality of that release. A particular branch might
be of better quality, but a branch can never be as stable as a
release.

--
Glynn Clements <glynn@gclements.plus.com>