Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
On Mon, Nov 3, 2008 at 1:15 PM, Paul Kelly <[EMAIL PROTECTED]> 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
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 <[EMAIL PROTECTED]> 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
On Mon, Nov 3, 2008 at 2:12 AM, Maris Nartiss <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: >> 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 <[EMAIL PROTECTED]>: >>> >>> 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 > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
(cc Laura) On Mon, Nov 3, 2008 at 1:15 PM, Paul Kelly <[EMAIL PROTECTED]> 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
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 <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]>: >> >> 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
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
On Sun, 2 Nov 2008, Markus Neteler wrote: Hi Paul, all, On Sun, Nov 2, 2008 at 5:59 PM, Paul Kelly <[EMAIL PROTECTED]> wrote: Hi Markus On Sun, 2 Nov 2008, Markus Neteler wrote: (cc Tim Sutton) On Mon, Oct 27, 2008 at 7:30 AM, Hamish <[EMAIL PROTECTED]> 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 ___
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
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 <[EMAIL PROTECTED]>: > > 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
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
Hi Paul, all, On Sun, Nov 2, 2008 at 5:59 PM, Paul Kelly <[EMAIL PROTECTED]> wrote: > Hi Markus > > On Sun, 2 Nov 2008, Markus Neteler wrote: > >> (cc Tim Sutton) >> >> On Mon, Oct 27, 2008 at 7:30 AM, Hamish <[EMAIL PROTECTED]> 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
Hi Markus On Sun, 2 Nov 2008, Markus Neteler wrote: (cc Tim Sutton) On Mon, Oct 27, 2008 at 7:30 AM, Hamish <[EMAIL PROTECTED]> 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
(cc Tim Sutton) On Mon, Oct 27, 2008 at 7:30 AM, Hamish <[EMAIL PROTECTED]> 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
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. 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
On Fri, 24 Oct 2008, Markus Neteler wrote: On Fri, Oct 24, 2008 at 1:45 AM, Paul Kelly <[EMAIL PROTECTED]> wrote: 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
On Fri, Oct 24, 2008 at 1:45 AM, Paul Kelly <[EMAIL PROTECTED]> wrote: > 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
On Thu, 23 Oct 2008, Glynn Clements wrote: Paul Kelly wrote: 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
Paul Kelly wrote: > >> 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 <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
On Wed, 22 Oct 2008, Markus Neteler wrote: On Wed, Oct 22, 2008 at 5:27 PM, Glynn Clements <[EMAIL PROTECTED]> wrote: 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
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. 2008/10/23 Markus Neteler <[EMAIL PROTECTED]>: > On Thu, Oct 23, 2008 at 8:31 AM, Maris Nartiss <[EMAIL PROTECTED]> wrote: >> 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. > >> 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. > >> 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 > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
On Thu, Oct 23, 2008 at 8:31 AM, Maris Nartiss <[EMAIL PROTECTED]> wrote: > 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. > 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. > 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
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. 2008/10/23 Markus Neteler <[EMAIL PROTECTED]>: > On Wed, Oct 22, 2008 at 5:27 PM, Glynn Clements > <[EMAIL PROTECTED]> wrote: >> 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 > 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
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
On Wed, Oct 22, 2008 at 5:27 PM, Glynn Clements <[EMAIL PROTECTED]> wrote: > 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 grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
Hamish wrote: > > 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 <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
On Wed, Oct 22, 2008 at 9:36 AM, Marco Pasetti <[EMAIL PROTECTED]> wrote: > Hi all, > >> 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) > 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
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. 2008/10/22 Markus Neteler <[EMAIL PROTECTED]>: > On Wed, Oct 22, 2008 at 3:20 AM, Helena Mitasova <[EMAIL PROTECTED]> wrote: >> On Oct 21, 2008, at 7:39 PM, Hamish wrote: >>> Markus wrote: > 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 > 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
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
Hi all, 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
On Wed, Oct 22, 2008 at 3:20 AM, Helena Mitasova <[EMAIL PROTECTED]> wrote: > On Oct 21, 2008, at 7:39 PM, Hamish wrote: >> Markus wrote: 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. 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming oops
On Oct 21, 2008, at 9:20 PM, Helena Mitasova wrote: On Oct 21, 2008, at 7:39 PM, Hamish wrote: Markus wrote: let me suggest to create the GRASS 6.4.0 release branch the next days Paul: 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 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 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 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
On Oct 21, 2008, at 7:39 PM, Hamish wrote: Markus wrote: let me suggest to create the GRASS 6.4.0 release branch the next days Paul: 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 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 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
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
Markus wrote: > > let me suggest to create the GRASS 6.4.0 release branch the next > > days Paul: > 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
Hello Markus On Tue, 21 Oct 2008, Markus Neteler wrote: 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
