[GRASS-dev] GRASS 6.4.0 release branch forthcoming

(cc Tim Sutton)

On Mon, Oct 27, 2008 at 7:30 AM, Hamish <hamish_b@yahoo.com> wrote:

Paul wrote:

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.

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...

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]

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.

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

Hi Markus

On Sun, 2 Nov 2008, Markus Neteler wrote:

(cc Tim Sutton)

On Mon, Oct 27, 2008 at 7:30 AM, Hamish <hamish_b@yahoo.com> wrote:

Paul wrote:

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.

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?

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.

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

Hi Paul, all,

On Sun, Nov 2, 2008 at 5:59 PM, Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:

Hi Markus

On Sun, 2 Nov 2008, Markus Neteler wrote:

(cc Tim Sutton)

On Mon, Oct 27, 2008 at 7:30 AM, Hamish <hamish_b@yahoo.com> wrote:

Paul wrote:

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.

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).

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.

...

[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

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.

2008/11/2, Markus Neteler <neteler@osgeo.org>:

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

On Sun, 2 Nov 2008, Markus Neteler wrote:

Hi Paul, all,

On Sun, Nov 2, 2008 at 5:59 PM, Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:

Hi Markus

On Sun, 2 Nov 2008, Markus Neteler wrote:

(cc Tim Sutton)

On Mon, Oct 27, 2008 at 7:30 AM, Hamish <hamish_b@yahoo.com> wrote:

Paul wrote:

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.

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).

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.

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.

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

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.

2008/11/2, Maris Nartiss <maris.gis@gmail.com>:

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.

2008/11/2, Markus Neteler <neteler@osgeo.org>:

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

MN:

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

On Mon, 3 Nov 2008, Hamish wrote:

MN:

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?

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.

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

(cc Laura)

On Mon, Nov 3, 2008 at 1:15 PM, Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:

On Mon, 3 Nov 2008, Hamish wrote:

MN:

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

On Mon, Nov 3, 2008 at 2:12 AM, Maris Nartiss <maris.gis@gmail.com> wrote:

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

2008/11/2, Maris Nartiss <maris.gis@gmail.com>:

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.

2008/11/2, Markus Neteler <neteler@osgeo.org>:

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

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

I'll look into this precision issue, though not sure how long it will take.
-Laura

On Nov 3, 2008, at 9:43 AM, Markus Neteler wrote:

(cc Laura)

On Mon, Nov 3, 2008 at 1:15 PM, Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:

On Mon, 3 Nov 2008, Hamish wrote:

MN:

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

On Mon, Nov 3, 2008 at 1:15 PM, Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:

On Mon, 3 Nov 2008, Hamish wrote:

MN:

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?

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