2012/8/25 Michael Barton michael.bar...@asu.edu:
My suggestion was to start a GRASS 7 release branch and stop adding new
features to 6.x *after* 6.4.4 stable is released. Too complicated to work on
2 active release branches at the same time.
why after 6.4.4? The next release is also stable
OK. Then after 6.4.3.
Even better
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:
Hi,
6.4.3 is planned for September. As I wrote earlier creating release
branch for G7 at this stage of development is too early (from my POV).
I would say that we could create this branch later in the beginning of
2013. It's not really connected to GRASS 6.
Martin
2012/8/26 Michael Barton
On Sun, Aug 26, 2012 at 10:43 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
6.4.3 is planned for September. As I wrote earlier creating release
branch for G7 at this stage of development is too early (from my POV).
I would say that we could create this branch later in the beginning of
-requ...@lists.osgeo.orgmailto:grass-dev-requ...@lists.osgeo.org
wrote:
From: Helena Mitasova hmit...@ncsu.edumailto:hmit...@ncsu.edu
Subject: Re: [GRASS-dev] too many branches
Date: August 24, 2012 3:22:00 PM MST
To: Martin Landa landa.mar...@gmail.commailto:landa.mar...@gmail.com
Cc: GRASS
Hi,
2012/8/22 Markus Neteler nete...@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
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
Markus M:
My ;-) 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
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
Hamish wrote:
My ;-) 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
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
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
On Wed, Aug 22, 2012 at 12:39 PM, Hamish hamis...@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
Hi,
2012/8/22 Hamish hamis...@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
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
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
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
On Wed, Aug 22, 2012 at 1:28 PM, Hamish hamis...@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
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
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
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
2012/8/22 Hamish hamis...@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
On Wed, Aug 22, 2012 at 3:07 PM, Martin Landa landa.mar...@gmail.com wrote:
2012/8/22 Hamish hamis...@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
2012/8/22 Martin Landa landa.mar...@gmail.com:
2012/8/22 Hamish hamis...@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
Hi,
2012/8/22 Sören Gebbert soerengebb...@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
, 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.mar...@gmail.com wrote:
2012/8/22 Hamish hamis...@yahoo.com:
Is there any comparison of devbr6 a relbr64?
Yes:
diff -ru
@lists.osgeo.org
Subject: Re: [GRASS-dev] too many branches
On Wed, Aug 22, 2012 at 3:07 PM, Martin Landa landa.mar...@gmail.com
wrote:
2012/8/22 Hamish hamis...@yahoo.com:
Is there any comparison of devbr6 a relbr64?
Yes:
diff -ru --exclude=.svn grass64_release grass65_release
To even
On Wed, Aug 22, 2012 at 9:19 PM, Markus Metz
markus.metz.gisw...@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
... 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.
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
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
31 matches
Mail list logo
