Discussion:
GRASS 6.4.0 release branch forthcoming
(too old to reply)
Markus Neteler
2008-10-21 10:16:48 UTC
Permalink
Hi,

let me suggest to create the GRASS 6.4.0 release branch the next
days to get started with stability tests. The last release is long time
ago and more and more efforts go into GRASS 7 (which is good).
Time to get 6.4.0 out of the doors, say, to bring it to our users.

While I am not keen on *heavy* backporting, we will certainly
maintain the branch (as we still do at low level for 6.3.x).

Is there any blocker (!) which prevents us from creating the
6.4.0 release branch?

Looking at the roadmap in trac, I see
GRASS 6.3.1: 3 bugs left open
https://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&milestone=6.3.1

GRASS 6.4.0: many bugs left open
https://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&milestone=6.4.0

Please check the 6.4.0 bug list for showstoppers which block
the creation of the release branch (think massive backporting).

Markus
Paul Kelly
2008-10-21 11:14:28 UTC
Permalink
Hello Markus
Post by Markus Neteler
Hi,
let me suggest to create the GRASS 6.4.0 release branch the next
days to get started with stability tests. The last release is long time
ago and more and more efforts go into GRASS 7 (which is good).
Time to get 6.4.0 out of the doors, say, to bring it to our users.
I agree - but do we need to create a release branch in advance of the
release? Any development in the 6.4 branch at present is intended for the
6.4.0 release anyway; it's not as if we need to branch off the release to
allow development to continue in the devel branch, as all new development
is going on in trunk.

I think to avoid having three separate branches (6.4 dev, 6.4 release and
7.0 dev/trunk) it would be best to only create the release branch
immediately before 6.4.0 is tagged.

Am open to persuasion though.

Paul
Hamish
2008-10-21 23:39:12 UTC
Permalink
Post by Paul Kelly
Post by Markus Neteler
let me suggest to create the GRASS 6.4.0 release branch the next
days
I agree - but do we need to create a release branch in advance of the
release? Any development in the 6.4 branch at present is intended for
the 6.4.0 release anyway; it's not as if we need to branch off the
release to allow development to continue in the devel branch, as all
new development is going on in trunk.
I think to avoid having three separate branches (6.4 dev, 6.4 release
and 7.0 dev/trunk) it would be best to only create the release
branch immediately before 6.4.0 is tagged.
I think Paul is right, create 6.4.0 release branch moments before 6.4.0rc1,
otherwise there is more backporting to do, which is a pain.

or is the idea to release rc1 in the next days?



I had some things I wanted to get done before 6.4.0-final, I added/
commented on a couple in the trac system yesterday, and I'll add a few
more as I can remember them ;)


Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Helena Mitasova
2008-10-22 01:20:50 UTC
Permalink
Post by Hamish
Post by Paul Kelly
Post by Markus Neteler
let me suggest to create the GRASS 6.4.0 release branch the next
days
I agree - but do we need to create a release branch in advance of the
release? Any development in the 6.4 branch at present is intended for
the 6.4.0 release anyway; it's not as if we need to branch off the
release to allow development to continue in the devel branch, as all
new development is going on in trunk.
I think to avoid having three separate branches (6.4 dev, 6.4 release
and 7.0 dev/trunk) it would be best to only create the release
branch immediately before 6.4.0 is tagged.
I think Paul is right, create 6.4.0 release branch moments before 6.4.0rc1,
otherwise there is more backporting to do, which is a pain.
or is the idea to release rc1 in the next days?
I think that is the idea. It took 6 months to get from 6.3RC1 to 6.3
release,
so if we would like to see GRASS64 out by the end of the year the 6.3RC1
is overdue by now. It would be much simpler if we had only GRASS64
and GRASS7 -
currently there is 6.2, 6.3, 6.4 and 7 on the download site.

Helena
Post by Hamish
I had some things I wanted to get done before 6.4.0-final, I added/
commented on a couple in the trac system yesterday, and I'll add a few
more as I can remember them ;)
Hamish
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev
Helena Mitasova
2008-10-22 01:22:29 UTC
Permalink
Post by Helena Mitasova
Post by Hamish
Post by Paul Kelly
Post by Markus Neteler
let me suggest to create the GRASS 6.4.0 release branch the next
days
I agree - but do we need to create a release branch in advance of the
release? Any development in the 6.4 branch at present is intended for
the 6.4.0 release anyway; it's not as if we need to branch off the
release to allow development to continue in the devel branch, as all
new development is going on in trunk.
I think to avoid having three separate branches (6.4 dev, 6.4 release
and 7.0 dev/trunk) it would be best to only create the release
branch immediately before 6.4.0 is tagged.
I think Paul is right, create 6.4.0 release branch moments before 6.4.0rc1,
otherwise there is more backporting to do, which is a pain.
or is the idea to release rc1 in the next days?
I think that is the idea. It took 6 months to get from 6.3RC1 to
6.3 release,
so if we would like to see GRASS64 out by the end of the year the 6.3RC1
oops - I meant GASS64RC1
Post by Helena Mitasova
is overdue by now. It would be much simpler if we had only GRASS64
and GRASS7 -
currently there is 6.2, 6.3, 6.4 and 7 on the download site.
Helena
Post by Hamish
I had some things I wanted to get done before 6.4.0-final, I added/
commented on a couple in the trac system yesterday, and I'll add a few
more as I can remember them ;)
Hamish
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus Neteler
2008-10-22 07:08:25 UTC
Permalink
Post by Hamish
Post by Markus Neteler
let me suggest to create the GRASS 6.4.0 release branch the next
days
I think Paul is right, create 6.4.0 release branch moments before
6.4.0rc1, otherwise there is more backporting to do, which is a pain.
or is the idea to release rc1 in the next days?
Yes, I forgot to mention that idea.
I think that is the idea. It took 6 months to get from 6.3RC1 to 6.3 release,
so if we would like to see GRASS64 out by the end of the year the 6.3RC1
is overdue by now. It would be much simpler if we had only GRASS64 and
GRASS7 - currently there is 6.2, 6.3, 6.4 and 7 on the download site.
I agree. For a user it's becoming messy to understand which version
to choose.
Post by Hamish
I had some things I wanted to get done before 6.4.0-final, I added/
commented on a couple in the trac system yesterday, and I'll add a few
more as I can remember them ;)
Well, it's unrealistic to hope that we resolve all bugs/enhancements.

I suggest to get out 6.4.0rc1 asap for reality check (especially also for the
Windows port). If backporting becomes to heavy, we could even re-do the
relbranch in future.

Markus
Marco Pasetti
2008-10-22 07:36:23 UTC
Permalink
Hi all,
Post by Markus Neteler
I suggest to get out 6.4.0rc1 asap for reality check (especially also for the
Windows port). If backporting becomes to heavy, we could even re-do the
relbranch in future.
Unfortunately I'm very busy now; I'll discuss my thesis on November the
18th, and I'm still working on it.
That means that I'm forced to delay the GRASS job after 11/18. I know that
this is an annoying problem, but that's all I can do :-(
IMHO, I think that we could release the 6.4.0 branch and delay the Windows
binaries on late November.

Regards,

Marco
Markus Neteler
2008-10-22 08:06:18 UTC
Permalink
Post by Marco Pasetti
Hi all,
Post by Markus Neteler
I suggest to get out 6.4.0rc1 asap for reality check (especially also for the
Windows port). If backporting becomes to heavy, we could even re-do the
relbranch in future.
Unfortunately I'm very busy now; I'll discuss my thesis on November the
18th, and I'm still working on it.
That means that I'm forced to delay the GRASS job after 11/18. I know that
this is an annoying problem, but that's all I can do :-(
(good luck with your thesis)
Post by Marco Pasetti
IMHO, I think that we could release the 6.4.0 branch and delay the Windows
binaries on late November.
Please note: we are talking about release candidates here, not the final
release.

Markus
Maris Nartiss
2008-10-22 08:03:00 UTC
Permalink
Hello all.
Could we have some bug sorting party this weekend? I (hopefully) will
have free time this weekend to recompile devbranch6 and take a look at
current bug list. It would be good to at least re-tag some of bugs
which must be fixed before 6.4.0 goes out and which ones can wait till
GRASS 7 goes mainstream. I have not tested devbranch6 for some time
but IIRC there where some regressions comparing to 6.2/6.3 (in NVIZ).

Just my 0.002,
Maris.
Post by Markus Neteler
Post by Hamish
Post by Markus Neteler
let me suggest to create the GRASS 6.4.0 release branch the next
days
I think Paul is right, create 6.4.0 release branch moments before
6.4.0rc1, otherwise there is more backporting to do, which is a pain.
or is the idea to release rc1 in the next days?
Yes, I forgot to mention that idea.
Well, it's unrealistic to hope that we resolve all bugs/enhancements.
I suggest to get out 6.4.0rc1 asap for reality check (especially also for the
Windows port). If backporting becomes to heavy, we could even re-do the
relbranch in future.
Markus
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev
Glynn Clements
2008-10-22 15:27:48 UTC
Permalink
Post by Hamish
Post by Paul Kelly
I agree - but do we need to create a release branch in advance of the
release? Any development in the 6.4 branch at present is intended for
the 6.4.0 release anyway; it's not as if we need to branch off the
release to allow development to continue in the devel branch, as all
new development is going on in trunk.
I think to avoid having three separate branches (6.4 dev, 6.4 release
and 7.0 dev/trunk) it would be best to only create the release
branch immediately before 6.4.0 is tagged.
I think Paul is right, create 6.4.0 release branch moments before 6.4.0rc1,
otherwise there is more backporting to do, which is a pain.
or is the idea to release rc1 in the next days?
I had some things I wanted to get done before 6.4.0-final, I added/
commented on a couple in the trac system yesterday, and I'll add a few
more as I can remember them ;)
I would suggest leaving 6.4.0 for a while yet. Otherwise, you'll be up
to 6.123.0 by the time that we start thinking about releasing 7.0.

I'd be more concerned about 6.3.1, as there have been a fair number of
straightforward bug-fixes since 6.3.0.
--
Glynn Clements <***@gclements.plus.com>
Markus Neteler
2008-10-22 21:37:29 UTC
Permalink
On Wed, Oct 22, 2008 at 5:27 PM, Glynn Clements
Post by Glynn Clements
I'd be more concerned about 6.3.1, as there have been a fair number of
straightforward bug-fixes since 6.3.0.
Well, I know easily 50 fixes which I have NOT backported to 6.3.svn, knowing,
that 6.4.0.RCX is forthcoming soon. Many are related to portability, too.
So I do think that we need a 6.4.0 the next months (at least I won't go through
all those fixes to check if they are present in 6.3.svn - even the code layout
isn't reindented).

Markus
Maris Nartiss
2008-10-23 06:31:25 UTC
Permalink
Hello all,
as I understood from Glynn, it's too early to release 6.4.0 as GRASS 7
is still too far away. I also agree with Markus, that we need to
release something for packagers, as more and more users are suggested
to use SVN version and not some semi-stable version from packages.
GRASS 6.3.0 was technical preview release - it was never promised to
be stable. I see no point in releasing 6.3.1 with just some fixes.
My proposal - let's make another "technical preview" from devbranch6
called i.e. 6.3.90 (just a devbranch6 tag within week or so) - we get
something out for users who don't compile GRASS, still it's not final
6.4.0, that should be stable and bug free, as main release between 6.2
and 7.0 should be.


Just my 0.002,
Maris.
Post by Markus Neteler
On Wed, Oct 22, 2008 at 5:27 PM, Glynn Clements
Post by Glynn Clements
I'd be more concerned about 6.3.1, as there have been a fair number of
straightforward bug-fixes since 6.3.0.
Well, I know easily 50 fixes which I have NOT backported to 6.3.svn, knowing,
that 6.4.0.RCX is forthcoming soon. Many are related to portability, too.
So I do think that we need a 6.4.0 the next months (at least I won't go through
all those fixes to check if they are present in 6.3.svn - even the code layout
isn't reindented).
Markus
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus Neteler
2008-10-23 07:15:47 UTC
Permalink
Post by Maris Nartiss
Hello all,
as I understood from Glynn, it's too early to release 6.4.0 as GRASS 7
is still too far away.
This reasoning is unclear to me. While I want to avoid GRASS 6.132.x,
there is no real problem to have a 6.6 is unavoidable.

In 6.4.svn are thousands (!) of fixes which don't reach the user yet
in an organized way.
Post by Maris Nartiss
I also agree with Markus, that we need to
release something for packagers, as more and more users are suggested
to use SVN version and not some semi-stable version from packages.
GRASS 6.3.0 was technical preview release - it was never promised to
be stable. I see no point in releasing 6.3.1 with just some fixes.
I agree.
Post by Maris Nartiss
My proposal - let's make another "technical preview" from devbranch6
called i.e. 6.3.90 (just a devbranch6 tag within week or so) - we get
something out for users who don't compile GRASS, still it's not final
6.4.0, that should be stable and bug free, as main release between 6.2
and 7.0 should be.
You mean, with bulk-copying 6.4.svn into 6.3.svn? Or by downgrading
devel_grass6 branch to 6.3.90 or likewise in include/version.h? Or
by creating a 6.3.90 relbranch from devel_grass6?

Just to understand your suggestion...

Markus
Maris Nartiss
2008-10-23 08:40:24 UTC
Permalink
Hello Markus,
well - let's wait for other developer input (especially - do 6.4 has
to be last stable 6.x release).

I forgot about that include/VERSION file. Doh.
My idea was really simple - just create develbranch_6 tag called
6.3.9x and make only one change in that tag - include/VERSION. Test,
release. No branching, backporting. When we will receive feedback
about current develbranch_6 state, we can decide if it's ready to
become 6.4 (stable), or there are some areas that need to be worked
on. 6.3.0 was really good idea and worked well, still IMHO we need
more 6.3-like releases between our stable versions.

Others - don't waste time by pointing places where I'm wrong. Please,
give ideas how to avoid those looong times between releases. Thanks!

Maris.
Post by Markus Neteler
Post by Maris Nartiss
Hello all,
as I understood from Glynn, it's too early to release 6.4.0 as GRASS 7
is still too far away.
This reasoning is unclear to me. While I want to avoid GRASS 6.132.x,
there is no real problem to have a 6.6 is unavoidable.
In 6.4.svn are thousands (!) of fixes which don't reach the user yet
in an organized way.
Post by Maris Nartiss
I also agree with Markus, that we need to
release something for packagers, as more and more users are suggested
to use SVN version and not some semi-stable version from packages.
GRASS 6.3.0 was technical preview release - it was never promised to
be stable. I see no point in releasing 6.3.1 with just some fixes.
I agree.
Post by Maris Nartiss
My proposal - let's make another "technical preview" from devbranch6
called i.e. 6.3.90 (just a devbranch6 tag within week or so) - we get
something out for users who don't compile GRASS, still it's not final
6.4.0, that should be stable and bug free, as main release between 6.2
and 7.0 should be.
You mean, with bulk-copying 6.4.svn into 6.3.svn? Or by downgrading
devel_grass6 branch to 6.3.90 or likewise in include/version.h? Or
by creating a 6.3.90 relbranch from devel_grass6?
Just to understand your suggestion...
Markus
Paul Kelly
2008-10-23 09:55:10 UTC
Permalink
Post by Markus Neteler
On Wed, Oct 22, 2008 at 5:27 PM, Glynn Clements
Post by Glynn Clements
I'd be more concerned about 6.3.1, as there have been a fair number of
straightforward bug-fixes since 6.3.0.
Well, I know easily 50 fixes which I have NOT backported to 6.3.svn, knowing,
that 6.4.0.RCX is forthcoming soon. Many are related to portability, too.
So I do think that we need a 6.4.0 the next months (at least I won't go through
all those fixes to check if they are present in 6.3.svn - even the code layout
isn't reindented).
I'm not sure if this is what Glynn meant, but I ask - why does 6.3.1 have
to be released from the 6.3.0 release branch? Why not just release 6.3.1
straight from develbranch_6? I really don't see the need to always have a
release branch for releases. IMHO it slows things down and is a major
impediment to "release early, release often" working.

I feel a release branch is only needed when a stable release is being made
from a branch and major development work is going to continue in that
branch and needs to be isolated from the release. This did not apply to
6.3.0 (because it wasn't a stable release) and will not apply to the next
release, whatever we call it (because major development work is now
happening in trunk).

If the release of 6.4.0 means a feature freeze for 6.x, then I think we
should not do it yet and should release more 6.3.x versions direct from
develbranch_6 until we feel ready to freeze 6.x and gamble the future on
7.x. If on the other hand 6.4.0 does not mean a feature freeze and we are
still going to be able to add new modules (e.g. from Summer of Code in
2009?) and there will be 6.5.x and 6.6.x releases, then I don't see a
problem with going ahead with 6.4.0 but I think if we are careful to
manage features and bug fixes then there is no need for a release branch.
Three branches would be really awkward for backporting and I feel we
should avoid it if at all possible.

Paul
Glynn Clements
2008-10-23 17:48:03 UTC
Permalink
Post by Paul Kelly
Post by Markus Neteler
Post by Glynn Clements
I'd be more concerned about 6.3.1, as there have been a fair number of
straightforward bug-fixes since 6.3.0.
Well, I know easily 50 fixes which I have NOT backported to 6.3.svn, knowing,
that 6.4.0.RCX is forthcoming soon. Many are related to portability, too.
So I do think that we need a 6.4.0 the next months (at least I won't go through
all those fixes to check if they are present in 6.3.svn - even the code layout
isn't reindented).
I'm not sure if this is what Glynn meant, but I ask - why does 6.3.1 have
to be released from the 6.3.0 release branch? Why not just release 6.3.1
straight from develbranch_6? I really don't see the need to always have a
release branch for releases. IMHO it slows things down and is a major
impediment to "release early, release often" working.
Any release from develbranch_6 will contain incompatible changes, so
it should be called 6.4.0, not 6.3.1. Versions which share the same
major and minor numbers, differing only in the release number,
shouldn't have even minor incompatibilities.

Ideally, such versions should retain build-time compatibility as well
as run-time compatibility, so that third-party code will continue to
work in spite of any update.
--
Glynn Clements <***@gclements.plus.com>
Paul Kelly
2008-10-23 23:45:17 UTC
Permalink
Post by Glynn Clements
Post by Paul Kelly
Post by Markus Neteler
Post by Glynn Clements
I'd be more concerned about 6.3.1, as there have been a fair number of
straightforward bug-fixes since 6.3.0.
Well, I know easily 50 fixes which I have NOT backported to 6.3.svn, knowing,
that 6.4.0.RCX is forthcoming soon. Many are related to portability, too.
So I do think that we need a 6.4.0 the next months (at least I won't go through
all those fixes to check if they are present in 6.3.svn - even the code layout
isn't reindented).
I'm not sure if this is what Glynn meant, but I ask - why does 6.3.1 have
to be released from the 6.3.0 release branch? Why not just release 6.3.1
straight from develbranch_6? I really don't see the need to always have a
release branch for releases. IMHO it slows things down and is a major
impediment to "release early, release often" working.
Any release from develbranch_6 will contain incompatible changes, so
it should be called 6.4.0, not 6.3.1.
Ah OK now I see. Also as Helena said in private mail now that 6.4 is "out
of the bag", so to speak, because 6.3.0 was released from its own branch
and develbranch_6 was renamed to 6.4-SVN, users would see any 6.3.x
versions released as being not up to date because they are aware that 6.4
is somehow available.

Not saying 6.3.1 from the 6.3 release branch is a bad idea, but I doubt
anyone will have the motivation to merge the bugfixes and prepare a
release. So I feel there is no real option but to go straight to 6.4.0.
I'm still not sure if we need a release branch though.

Paul
Markus Neteler
2008-10-24 18:19:31 UTC
Permalink
On Fri, Oct 24, 2008 at 1:45 AM, Paul Kelly
So I feel there is no real option but to go straight to 6.4.0. I'm still not
sure if we need a release branch though.
You mean we should just tag RC1 from develbranch_6?
We commonly used a release branch so far to avoid breakage.

Markus
Paul Kelly
2008-10-27 05:50:46 UTC
Permalink
Post by Markus Neteler
On Fri, Oct 24, 2008 at 1:45 AM, Paul Kelly
So I feel there is no real option but to go straight to 6.4.0. I'm still not
sure if we need a release branch though.
You mean we should just tag RC1 from develbranch_6?
We commonly used a release branch so far to avoid breakage.
Yes, it is a bit risky going ahead with no release branch. It would mean
we would have to be very careful deciding what went into 6.4, and if an
incompatible change was to be made at some time in the future, a release
branch would have to be created *at that stage*, to preserve the
functional state of 6.4 in order to create future 6.4.x bugfix releases if
necessary.

My point is just that it would be a huge headache having three branches -
backporting from 7.x to 6.x is already enough work - and if we felt that
develbranch_6 is quite stable already we could probably manage the 6.4.0
release without creating a new branch. As far as I can see, commits to
develbranch_6 consist mostly of bugfixes already at this stage, so this
might not be too hard to do?

I still think at some point a 6.4 release branch will be needed (when we
want to add new features) but I think we should put off creating it as
long as possible to reduce work. That's all - it depends on other
developers agreeing to restrict the changes we make to develbranch_6 for a
while though.

Paul
Hamish
2008-10-27 06:30:47 UTC
Permalink
Post by Paul Kelly
I still think at some point a 6.4 release branch will be needed (when we
want to add new features) but I think we should put off creating it as
long as possible to reduce work. That's all - it depends on other
developers agreeing to restrict the changes we make to develbranch_6
for a while though.
If only to keep options open for a possible 6.5/6 release we'll eventually
need a releasebranch_6_4. For stability reasons this should be done, at
minimum, before the last (say) two RCs before the final release -- ie the
onset of the hard freeze.

Because this is likely to be the last new-features release before 7.0,
and that "may be some time", I don't mind a softer freeze a little later
than normal. What does a soft-freeze mean? I'd say keep going as we have
been with devbr6, and rely on developer discipline to not commit anything
too radical. As we already have an outlet for radicalness with gr7, I
don't think it will be too hard.


So my 2c plan of action would be to first finalize the module list (trac
task #344) in the next week by bringing over addons destined for main.
Once that is done we could tag a release_$DATE_grass_6_4_0RC1 directly
from devbr6 and declare devbr6 to be temporarily in stability mode.

Once r.out.gdal and other critical issues are dealt with, and the newly
merged modules have had a chance to settle in (inevitable portability
issues that pop up, etc) we could tag another RC, say 3 weeks after RC1.
We can decide at that point if RC2 will be the bugfix-only branch point
or again tagged directly from devbr6. No way of knowing, but it seems
reasonable to me to expect that RC2 could be the branch point.

After the release branch point, backports to that branch will be naturally
kept in check by the PITA that it is to sync things.

A question remains for me wrt after 6.4.0 is released if grass7<->devbr6
development will be kept in sync as it is now. (for possible 6.5/6)
I'll defer an opinion about that until the time of the last 6.4.0 RC.



Hamish
Markus Neteler
2008-11-02 16:38:17 UTC
Permalink
(cc Tim Sutton)
Post by Hamish
Post by Paul Kelly
I still think at some point a 6.4 release branch will be needed (when we
want to add new features) but I think we should put off creating it as
long as possible to reduce work. That's all - it depends on other
developers agreeing to restrict the changes we make to develbranch_6
for a while though.
There is an additional reason:
QGIS is going into feature freeze (they are already at 1.0 Preview 1).

I really want to avoid that they have to package 6.3.0 into it, just
because some GRASS developers are unhappy to see a 6.4.0
release branch.
Post by Hamish
So my 2c plan of action would be to first finalize the module list (trac
task #344) in the next week by bringing over addons destined for main.
Once that is done we could tag a release_$DATE_grass_6_4_0RC1 directly
from devbr6 and declare devbr6 to be temporarily in stability mode.
ok, let's go...
Post by Hamish
Once r.out.gdal and other critical issues are dealt with, and the newly
merged modules have had a chance to settle in (inevitable portability
issues that pop up, etc)
[portability will only pop up if packaging is actually done which isn't
for winGRASS unless a relbranch is there]
Post by Hamish
we could tag another RC, say 3 weeks after RC1.
We can decide at that point if RC2 will be the bugfix-only branch point
or again tagged directly from devbr6. No way of knowing, but it seems
reasonable to me to expect that RC2 could be the branch point.
After the release branch point, backports to that branch will be naturally
kept in check by the PITA that it is to sync things.
I am willing to help with backporting as before.
Post by Hamish
A question remains for me wrt after 6.4.0 is released if grass7<->devbr6
development will be kept in sync as it is now. (for possible 6.5/6)
I'll defer an opinion about that until the time of the last 6.4.0 RC.
Me, too. We can decide that later.

Markus
Paul Kelly
2008-11-02 16:59:27 UTC
Permalink
Hi Markus
Post by Markus Neteler
(cc Tim Sutton)
Post by Hamish
Post by Paul Kelly
I still think at some point a 6.4 release branch will be needed (when we
want to add new features) but I think we should put off creating it as
long as possible to reduce work. That's all - it depends on other
developers agreeing to restrict the changes we make to develbranch_6
for a while though.
QGIS is going into feature freeze (they are already at 1.0 Preview 1).
I really want to avoid that they have to package 6.3.0 into it, just
because some GRASS developers are unhappy to see a 6.4.0
release branch.
Can you explain further? If we say that develbranch_6_4 is not going to
have new incompatible features added to it before releasebranch_6_4 is
created, is that enough? I can't imagine that we would need to create a
release branch before it is absolutely necessary, just to give reassurance
to the QGIS developers that we are going to keep our word not to add new
incompatible features?
Post by Markus Neteler
Post by Hamish
So my 2c plan of action would be to first finalize the module list (trac
task #344) in the next week by bringing over addons destined for main.
Once that is done we could tag a release_$DATE_grass_6_4_0RC1 directly
from devbr6 and declare devbr6 to be temporarily in stability mode.
ok, let's go...
FWIW I think Hamish's plan sounds good too.
Post by Markus Neteler
Post by Hamish
Once r.out.gdal and other critical issues are dealt with, and the newly
merged modules have had a chance to settle in (inevitable portability
issues that pop up, etc)
[portability will only pop up if packaging is actually done which isn't
for winGRASS unless a relbranch is there]
If there's a release candidate I'm sure it will spur people on to do some
testing on the various platforms. FWIW I have a working MinGW compilation
environment again, on Windows Vista, and I'm happy to do some Windows
testing there. Why do you say we need a release branch for that?

Paul
Markus Neteler
2008-11-02 17:23:35 UTC
Permalink
Hi Paul, all,

On Sun, Nov 2, 2008 at 5:59 PM, Paul Kelly
Post by Paul Kelly
Hi Markus
Post by Markus Neteler
(cc Tim Sutton)
Post by Paul Kelly
I still think at some point a 6.4 release branch will be needed (when we
want to add new features) but I think we should put off creating it as
long as possible to reduce work. That's all - it depends on other
developers agreeing to restrict the changes we make to develbranch_6
for a while though.
QGIS is going into feature freeze (they are already at 1.0 Preview 1).
I really want to avoid that they have to package 6.3.0 into it, just
because some GRASS developers are unhappy to see a 6.4.0
release branch.
Can you explain further? If we say that develbranch_6_4 is not going to have
new incompatible features added to it before releasebranch_6_4 is created,
This is a not easy goal, but we can try. Simply *all* devs have to accept
a feature freeze (in the past we weren't very successful on that AFAIR).
Post by Paul Kelly
is that enough? I can't imagine that we would need to create a release
branch before it is absolutely necessary, just to give reassurance to the
QGIS developers that we are going to keep our word not to add new
incompatible features?
That's not the point I think. I spoke to Tim Sutton in Cape Town.
What they need is a release (candidate) to work with. A moving
target like devel_grass6 isn't acceptable for them.

In the past, they used the 6.3.relbranch since they could be sure
that this wasn't polluted with new features. They hope for something
similar for 6.4 now.

...
Post by Paul Kelly
Post by Markus Neteler
[portability will only pop up if packaging is actually done which isn't
for winGRASS unless a relbranch is there]
If there's a release candidate I'm sure it will spur people on to do some
testing on the various platforms. FWIW I have a working MinGW compilation
environment again, on Windows Vista, and I'm happy to do some Windows
testing there. Why do you say we need a release branch for that?
We can certainly freeze devel_grass6 and just tag RC1 directly from that
and test it rigorously. But are we sure that nobody inserts new features?
Especially in the wxPython arena, there are a couple of issues yet to be
submitted (AFAIK) which would easily count as new feature.

But I am fine with the soft-freeze plan as far as we keep discipline (including
me :). We just need to actually DO it.

Markus
Maris Nartiss
2008-11-02 17:54:02 UTC
Permalink
Hello Markus,
first - wxGUI features should not affect QGIS. If QGIS needs
something, we can create a tag and use it for testing/QGIS needs.
Probably it needs -alpha/-beta and not -RC, as it's not completely
forzen, just something for wider audience.

I know, it's bad timing, but right now I'm rewriting parts of v.drape
(WHERE and NULL support). I would like to have those changes in before
something gets released. Right now I'm stuck with attribute data
manipulation, but I will try to commit it within next two days. (Still
GRASS is taking more of my free/work time than it should)

Anyone else having list of uncommited changes that must get into next
testing release?

Maris.
Post by Markus Neteler
We can certainly freeze devel_grass6 and just tag RC1 directly from that
and test it rigorously. But are we sure that nobody inserts new features?
Especially in the wxPython arena, there are a couple of issues yet to be
submitted (AFAIK) which would easily count as new feature.
But I am fine with the soft-freeze plan as far as we keep discipline (including
me :). We just need to actually DO it.
Markus
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev
Maris Nartiss
2008-11-03 10:12:55 UTC
Permalink
Hello Markus and others.

I just commited change to v.drape.
Now it has WHERE statement support and it will ignore features without
height information from raster (i.e. NULL or outside of computational
region). Previously v.drape was just issuing warning about region
issues and failing with assetion failed error. User can include
skipped points by specifying static height to assign to them.

Please test it and check language as I'm not a native speaker.
Maris.
Post by Maris Nartiss
Hello Markus,
first - wxGUI features should not affect QGIS. If QGIS needs
something, we can create a tag and use it for testing/QGIS needs.
Probably it needs -alpha/-beta and not -RC, as it's not completely
forzen, just something for wider audience.
I know, it's bad timing, but right now I'm rewriting parts of v.drape
(WHERE and NULL support). I would like to have those changes in before
something gets released. Right now I'm stuck with attribute data
manipulation, but I will try to commit it within next two days. (Still
GRASS is taking more of my free/work time than it should)
Anyone else having list of uncommited changes that must get into next
testing release?
Maris.
Post by Markus Neteler
We can certainly freeze devel_grass6 and just tag RC1 directly from that
and test it rigorously. But are we sure that nobody inserts new features?
Especially in the wxPython arena, there are a couple of issues yet to be
submitted (AFAIK) which would easily count as new feature.
But I am fine with the soft-freeze plan as far as we keep discipline (including
me :). We just need to actually DO it.
Markus
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev
Dylan Beaudette
2008-11-03 16:28:52 UTC
Permalink
Post by Maris Nartiss
Hello Markus and others.
I just commited change to v.drape.
Now it has WHERE statement support and it will ignore features without
height information from raster (i.e. NULL or outside of computational
region). Previously v.drape was just issuing warning about region
issues and failing with assetion failed error. User can include
skipped points by specifying static height to assign to them.
Please test it and check language as I'm not a native speaker.
Maris.
Thanks for fixing this, I was not able to do so. I'll give it a check
over the next couple of days.

Cheers,

Dylan
Post by Maris Nartiss
Post by Maris Nartiss
Hello Markus,
first - wxGUI features should not affect QGIS. If QGIS needs
something, we can create a tag and use it for testing/QGIS needs.
Probably it needs -alpha/-beta and not -RC, as it's not completely
forzen, just something for wider audience.
I know, it's bad timing, but right now I'm rewriting parts of v.drape
(WHERE and NULL support). I would like to have those changes in before
something gets released. Right now I'm stuck with attribute data
manipulation, but I will try to commit it within next two days. (Still
GRASS is taking more of my free/work time than it should)
Anyone else having list of uncommited changes that must get into next
testing release?
Maris.
Post by Markus Neteler
We can certainly freeze devel_grass6 and just tag RC1 directly from that
and test it rigorously. But are we sure that nobody inserts new features?
Especially in the wxPython arena, there are a couple of issues yet to be
submitted (AFAIK) which would easily count as new feature.
But I am fine with the soft-freeze plan as far as we keep discipline (including
me :). We just need to actually DO it.
Markus
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev
Paul Kelly
2008-11-02 19:28:31 UTC
Permalink
Post by Markus Neteler
Hi Paul, all,
On Sun, Nov 2, 2008 at 5:59 PM, Paul Kelly
Post by Paul Kelly
Hi Markus
Post by Markus Neteler
(cc Tim Sutton)
Post by Paul Kelly
I still think at some point a 6.4 release branch will be needed (when we
want to add new features) but I think we should put off creating it as
long as possible to reduce work. That's all - it depends on other
developers agreeing to restrict the changes we make to develbranch_6
for a while though.
QGIS is going into feature freeze (they are already at 1.0 Preview 1).
I really want to avoid that they have to package 6.3.0 into it, just
because some GRASS developers are unhappy to see a 6.4.0
release branch.
Can you explain further? If we say that develbranch_6_4 is not going to have
new incompatible features added to it before releasebranch_6_4 is created,
This is a not easy goal, but we can try. Simply *all* devs have to accept
a feature freeze (in the past we weren't very successful on that AFAIR).
Post by Paul Kelly
is that enough? I can't imagine that we would need to create a release
branch before it is absolutely necessary, just to give reassurance to the
QGIS developers that we are going to keep our word not to add new
incompatible features?
That's not the point I think. I spoke to Tim Sutton in Cape Town.
What they need is a release (candidate) to work with. A moving
target like devel_grass6 isn't acceptable for them.
Ah yes I understand. But my point was we don't need a release branch to
create 6.4.0RC1, if we are disciplined about new features.
Post by Markus Neteler
We can certainly freeze devel_grass6 and just tag RC1 directly from that
and test it rigorously. But are we sure that nobody inserts new features?
This is really important. It is of general importance to GRASS actually (a
PSC issue I suppose, but better to discuss it here) because of the OSGeo
requirements for quality control etc., and for the PSC to maintain that
quality control. Our quality control model is a very basic "developers are
allowed to make changes to the codebase as they see fit". I think this
works very well for nearly everything but if you feel we may have problems
with communication then we need to discuss it.

As a team of developers, we don't have the equivalent of an evil overlord
or a benevolent dictator to approve every SVN commit or to keep an eye on
everything that's going on and speak to individual developers if they
commit something that doesn't seem in policy. GRASS is too big and
complicated and diverse for that. We really rely on developers keeping the
grass-dev list updated with what they're doing, and summarising the
reasons for changes they're making. If somebody says:

I've committed (or am about to commit) the following changes to module X
There were previous problems X, Y and Z
These changes fix the problems by eliminating step Q

or that kind of thing, it's easy for others to see the motivation behind
the changes and comment on the appropriateness or otherwise of the way
things are being done. When this happens and feedback is given it
generally works very well, but it relies to a certain extent on other
developers taking the time to review the changes. I suspect some
developers get disheartened if they do this and noone has the time to
review and reply at the time, and then they don't bother in future. That
can be particularly off-putting for new or occasional developers.

But the thing is, even if this happens, IT IS NOT WASTED EFFORT! I know
from experience that just taking the time to explain to others the changes
you are making can make them make much more sense in your own head, and
the mailing list archives are always going to be there in future, which
future developers can search to find the reasoning behind a particular
change. So it is always a good idea to keep grass-dev updated with what
you are working on. Around the time of a release when we are deciding what
to put in and keep out, this is particularly important.
Post by Markus Neteler
Especially in the wxPython arena, there are a couple of issues yet to be
submitted (AFAIK) which would easily count as new feature.
Then these features should be discussed on grass-dev and we should come to
a consensus if they are needed for 6.4.0 or can be held back. IMHO,
probably controversial, there are still enough regular bug reports for the
wxPython GUI that it is not ready to go into a stable release. IIUC there
are also still issues with wxwidgets versions on various platforms. I
still see wxGUI as the futuristic 7.x GUI, especially given we are doing
the wholescale move towards Python (rewriting scripts etc.) for 7.x
anyway. gis.m has had loads of bugfixes since 6.2 and I think it should be
the standard promoted GUI in 6.4. But I would love to see more discussion
of the wxGUI on grass-dev.

Paul
Hamish
2008-11-03 11:53:14 UTC
Permalink
Post by Markus Neteler
We can certainly freeze devel_grass6 and just tag RC1
directly from that and test it rigorously. But are we
sure that nobody inserts new features?
new Vect fns req'd for v.buffer2 should be merged ASAP then.

As a priority I think we can copy r.viewshed over intact,
replace v.buffer/v.parallel/v.delaunay with "v2"s,
replace r.watershed with r.watershed.fast (enough testing?),

and decide others in task #344
https://trac.osgeo.org/grass/ticket/344


How to copy a dir from one SVN repo to the other (maintaining history)?


Hamish
Paul Kelly
2008-11-03 12:15:47 UTC
Permalink
Post by Hamish
Post by Markus Neteler
We can certainly freeze devel_grass6 and just tag RC1
directly from that and test it rigorously. But are we
sure that nobody inserts new features?
new Vect fns req'd for v.buffer2 should be merged ASAP then.
Was the issue with the linkm library ever resolved?
Post by Hamish
As a priority I think we can copy r.viewshed over intact,
r.viewshed still needs updating to GRASS style and conventions, e.g. there
are at least quite a lot of printf() statements - from a quick glance a
lot of these seem to be in code used for debugging and benchmarking and
there are also comments such as "only used in standalone version". Code
that is not used should be removed I feel, but it could be a lot of work.
Post by Hamish
replace v.buffer/v.parallel/v.delaunay with "v2"s,
replace r.watershed with r.watershed.fast (enough testing?),
and decide others in task #344
https://trac.osgeo.org/grass/ticket/344
How to copy a dir from one SVN repo to the other (maintaining history)?
Hamish
Markus Neteler
2008-11-03 14:43:48 UTC
Permalink
(cc Laura)

On Mon, Nov 3, 2008 at 1:15 PM, Paul Kelly
Post by Paul Kelly
Post by Hamish
Post by Markus Neteler
We can certainly freeze devel_grass6 and just tag RC1
directly from that and test it rigorously. But are we
sure that nobody inserts new features?
As a priority I think we can copy r.viewshed over intact,
r.viewshed still needs updating to GRASS style and conventions, e.g. there
are at least quite a lot of printf() statements - from a quick glance a lot
of these seem to be in code used for debugging and benchmarking and there
are also comments such as "only used in standalone version". Code that is
not used should be removed I feel, but it could be a lot of work.
Possible it is a mixture of the standalone non-GRASS version and the
GRASS version?

There is yet a precision problem in r.viewshed, just run
grass-addons/raster/r.viewshed/testscript.sh
in any location to see the problem and differences to r.los.

Markus
Laura Toma
2008-11-03 17:58:29 UTC
Permalink
I'll look into this precision issue, though not sure how long it
will take.
-Laura
Post by Markus Neteler
(cc Laura)
On Mon, Nov 3, 2008 at 1:15 PM, Paul Kelly
Post by Paul Kelly
Post by Hamish
Post by Markus Neteler
We can certainly freeze devel_grass6 and just tag RC1
directly from that and test it rigorously. But are we
sure that nobody inserts new features?
As a priority I think we can copy r.viewshed over intact,
r.viewshed still needs updating to GRASS style and conventions, e.g. there
are at least quite a lot of printf() statements - from a quick glance a lot
of these seem to be in code used for debugging and benchmarking and there
are also comments such as "only used in standalone version". Code that is
not used should be removed I feel, but it could be a lot of work.
Possible it is a mixture of the standalone non-GRASS version and the
GRASS version?
There is yet a precision problem in r.viewshed, just run
grass-addons/raster/r.viewshed/testscript.sh
in any location to see the problem and differences to r.los.
Markus
Markus Neteler
2008-11-27 23:16:29 UTC
Permalink
On Mon, Nov 3, 2008 at 1:15 PM, Paul Kelly
Post by Paul Kelly
Post by Hamish
Post by Markus Neteler
We can certainly freeze devel_grass6 and just tag RC1
directly from that and test it rigorously. But are we
sure that nobody inserts new features?
new Vect fns req'd for v.buffer2 should be merged ASAP then.
I have moved v.buffer2 over and don't observe any compile
issues. Seems to be ok?
Post by Paul Kelly
Was the issue with the linkm library ever resolved?
No idea - any pointers?

For new updated roadmap,see
http://grass.osgeo.org/wiki/GRASS_6.4_Feature_Plan

Markus

Continue reading on narkive:
Loading...