[GRASS-dev] too many branches

cmbarton · August 22, 2012, 5:28pm

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:

freeze (really freeze this time) 6.x for new features after the 6.4.4 release
keep 6.5 for bug fixes (bug fixes only, no enhancements, no backports of new features) to the 6.x line
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)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Aug 22, 2012, at 6:32 AM, <grass-dev-request@lists.osgeo.org>
wrote:

From: Markus Neteler <neteler@osgeo.org>

Date: August 22, 2012 6:18:32 AM MST

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

Subject: Re: [GRASS-dev] too many branches

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

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

Markus_Metz · August 22, 2012, 7:19pm

On Wed, Aug 22, 2012 at 7:28 PM, Michael Barton <michael.barton@asu.edu> 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, <grass-dev-request@lists.osgeo.org>
wrote:

From: Markus Neteler <neteler@osgeo.org>
Date: August 22, 2012 6:18:32 AM MST
To: GRASS developers list <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] too many branches

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

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
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

neteler · August 22, 2012, 7:57pm

On Wed, Aug 22, 2012 at 9:19 PM, Markus Metz
<markus.metz.giswork@gmail.com> 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

hellik · August 22, 2012, 8:05pm

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

+1

Helmut

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

martinl · August 24, 2012, 12:37pm

Hi,

2012/8/22 Markus Neteler <neteler@osgeo.org>:

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.

we started discussion with an idea to reduce number of branches we
currently maintain I personally think it's too much soon for grass
7 release branch. Let's say I would postpone it to the beginning of
the next year, then GRASS 7 could be released eg. around June. Make
sense to you?

Martin

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

Helena_Mitasova4 · August 24, 2012, 10:22pm

Martin,

I agree.
I think we have too many issues with 6.4* that need to be resolved quickly that we can start thinking about grass7
after we have a stable (in the sense as described by Glynn)
version of GRASS that people can download and that works.

Currently, we have stable GRASS6.4.2, but it is not very useable on Windows
and GRASS6.4.3 changes every day so students have different versions depending on when they downloaded
and addressing any issues that they may have gets messy pretty quickly.
Moreover, there are issues with Mac binaries as well.

Helena

On Aug 24, 2012, at 8:37 AM, Martin Landa wrote:

Hi,

2012/8/22 Markus Neteler <neteler@osgeo.org>:

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.

we started discussion with an idea to reduce number of branches we
currently maintain I personally think it's too much soon for grass
7 release branch. Let's say I would postpone it to the beginning of
the next year, then GRASS 7 could be released eg. around June. Make
sense to you?

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev