too many branches

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

too many branches

Markus Metz-3
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

hamish-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)
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

Markus Neteler
On Wed, Aug 22, 2012 at 12:39 PM, Hamish <[hidden email]> 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

Martin Landa
In reply to this post by hamish-2
Hi,

2012/8/22 Hamish <[hidden email]>:
> 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

hamish-2
In reply to this post by Markus Neteler
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. :-)

> 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

Glynn Clements
In reply to this post by Martin Landa

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 <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

hamish-2
In reply to this post by Markus Neteler
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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

Markus Neteler
In reply to this post by hamish-2
On Wed, Aug 22, 2012 at 1:28 PM, Hamish <[hidden email]> 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. :-)

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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

hamish-2
In reply to this post by Martin Landa
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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

hamish-2
In reply to this post by Markus Neteler
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 :-)


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 :)
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

Helmut Kudrnovsky
In reply to this post by Markus Metz-3
>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
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

Martin Landa
In reply to this post by hamish-2
2012/8/22 Hamish <[hidden email]>:
> 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 ;-)

[...]

I have nothing more to say about that, Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

Markus Neteler
On Wed, Aug 22, 2012 at 3:07 PM, Martin Landa <[hidden email]> wrote:
> 2012/8/22 Hamish <[hidden email]>:
>>> 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 :)

>>> 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

Sören Gebbert
In reply to this post by Martin Landa
2012/8/22 Martin Landa <[hidden email]>:
> 2012/8/22 Hamish <[hidden email]>:
>> 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. :)
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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

Martin Landa
Hi,

2012/8/22 Sören Gebbert <[hidden email]>:
>> 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 ;-) Yeap, Soeren is one of the most active
grass7 devs :-)

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

Michael Barton
In reply to this post by Markus Metz-3
The way I thought I understood the plan is that we would have an odd numbered version for development, testing, etc and an even numbered release version. So it has seemed to me that 6.4.3 is the place where we were supposed to be testing any enhancements and bug fixes before doing an even numbered 'stable' release. So I too have remained confused about why we needed a testing/development version 6.5 that fed into a testing/development version 6.4.3, that fed into a final stable release (6.4 on the way). But maybe I misunderstand this workflow and someone can explain it to me.

But that can be all moot now that we are moving towards a 6.4.4 release. 

Why don't we:

1) freeze (really freeze this time) 6.x for new features after the 6.4.4 release
2) keep 6.5 for bug fixes (bug fixes only, no enhancements, no backports of new features) to the 6.x line
3) start a 7.0 release branch and a 7.1 dev branch so that we can begin to move toward a GRASS 7 release

How does this sound???

Michael

____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)




On Aug 22, 2012, at 6:32 AM, <[hidden email]>
 wrote:

From: Markus Neteler <[hidden email]>
Date: August 22, 2012 6:18:32 AM MST
To: GRASS developers list <[hidden email]>
Subject: Re: [GRASS-dev] too many branches


On Wed, Aug 22, 2012 at 3:07 PM, Martin Landa <[hidden email]> wrote:
2012/8/22 Hamish <[hidden email]>:
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 :)

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




_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

Markus Metz-3
On Wed, Aug 22, 2012 at 7:28 PM, Michael Barton <[hidden email]> wrote:
> The way I thought I understood the plan is that we would have an odd
> numbered version for development, testing, etc and an even numbered release
> version. So it has seemed to me that 6.4.3 is the place where we were
> supposed to be testing any enhancements and bug fixes before doing an even
> numbered 'stable' release. So I too have remained confused about why we
> needed a testing/development version 6.5 that fed into a testing/development
> version 6.4.3, that fed into a final stable release (6.4 on the way). But
> maybe I misunderstand this workflow and someone can explain it to me.

I think we need to need to achieve some agreement about what is
allowed to get changed in 6.4.x. I thought that only bug fixes and
popular enhancements should go into 6.4.x. I thought that a
development branch 6.5 should be used for new features which do not
qualify for 6.4.x. I thought that bug fixes should immediately go into
all branches and not implemented in one branch, then forgotten. I
thought that testing of a bug fix takes place in the svn version of
6.4.x. If the bugs are confirmed fixed, a new 6.4.x can be released.
But this is what I thought initially. By now I learned that quite a
lot is possible in 6.4.x, even the API can change and script
compatibility can be broken (IMHO excusable because new features were
implemented too quickly without proper testing, the problem was the
inclusion of new, not well tested modules).

What has happened in the last years is that bugs where more or less
randomly fixed in 1, 2, or 3 branches, if in only one branch, it could
have been any of the 3. 6.5 was just used to backport new features
which have first been implemented in 7.0, and which then went into
6.4.x. In the worst case, bugs were fixed in a branch that was meant
for new features, but not in the releasebranch, and then forgotten.
IMHO this is a mess.

>
> But that can be all moot now that we are moving towards a 6.4.4 release.
>
> Why don't we:
>
> 1) freeze (really freeze this time) 6.x for new features after the 6.4.4
> release
> 2) keep 6.5 for bug fixes (bug fixes only, no enhancements, no backports of
> new features) to the 6.x line
> 3) start a 7.0 release branch and a 7.1 dev branch so that we can begin to
> move toward a GRASS 7 release
>
> How does this sound???

I agree, but would like to see a feature freeze after 6.4.3. New
features should go into the next larger minor version (I thought).

About 6.5, it can not really be used as technology preview, because 7
is too different. The wxGUI might be an argument for 6.5 though.

Markus M

PS: As a user I can not use 6.x for production work because GRASS 6 is
not able to perform the kind of analyses I have to do for my job. I
have to use GRASS 7.

>
>
>
> On Aug 22, 2012, at 6:32 AM, <[hidden email]>
>  wrote:
>
> From: Markus Neteler <[hidden email]>
> Date: August 22, 2012 6:18:32 AM MST
> To: GRASS developers list <[hidden email]>
> Subject: Re: [GRASS-dev] too many branches
>
>
> On Wed, Aug 22, 2012 at 3:07 PM, Martin Landa <[hidden email]>
> wrote:
>
> 2012/8/22 Hamish <[hidden email]>:
>
> 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 :)
>
> 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
>
>
>
>
> _______________________________________________
> grass-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

Markus Neteler
On Wed, Aug 22, 2012 at 9:19 PM, Markus Metz
<[hidden email]> wrote:
...
> PS: As a user I can not use 6.x for production work because GRASS 6 is
> not able to perform the kind of analyses I have to do for my job. I
> have to use GRASS 7.

... so the idea to start a GRASS 7 release branch would address that nicely.

MarkusN
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

Helmut Kudrnovsky
>... so the idea to start a GRASS 7 release branch would address that nicely.

+1

Helmut
best regards
Helmut
Reply | Threaded
Open this post in threaded view
|

Re: too many branches

Helena Mitasova-7
In reply to this post by Markus Metz-3
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
[hidden email]

"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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
12