Hi devs,
... so, getting out 7.0 seems to be endless...
A radical solution might be to change trunk into GRASS GIS 8. Then we
do not need to wait in 7 for API stabilization and can release it "as
is" and go ahead with the planned massive improvements.
Best
Markus
+1
On 21/06/2014, Markus Neteler <neteler@osgeo.org> wrote:
Hi devs,
... so, getting out 7.0 seems to be endless...
A radical solution might be to change trunk into GRASS GIS 8. Then we
do not need to wait in 7 for API stabilization and can release it "as
is" and go ahead with the planned massive improvements.Best
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
----
On 20/06/14 21:17, Markus Neteler wrote:
Hi devs,
... so, getting out 7.0 seems to be endless...
A radical solution might be to change trunk into GRASS GIS 8. Then we
do not need to wait in 7 for API stabilization and can release it "as
is" and go ahead with the planned massive improvements.
This sound ok to me. So, ideally, at all times we should have one release branch and one development branch. Releases can then just be tagged from the release branch which gets only selected, well-tested, not to invasive backports from the dev branch.
Once we decide that the dev branch is sufficiently different from release that backports become unfeasible, and sufficiently stabilised that we can branch a release branch out of it, we declare the previous release branch a legacy maintenance branch (with only limited bug fixing from that point on), and branch a new release branch.
The proposed RFC4 release procedure would then apply to the release branch.
I think this will help reduce the number of branches which currently is a hassle.
But, even though, I know you are in a hurry to get a grass7 release out of the door, don't you think that we should finish 6.4.4 first ?
To be honest I think we will have to accept shipping OSGEOLive with 6.4.4...
Moritz
Hi,
2014-06-23 10:56 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:
... so, getting out 7.0 seems to be endless...
A radical solution might be to change trunk into GRASS GIS 8. Then we
do not need to wait in 7 for API stabilization and can release it "as
is" and go ahead with the planned massive improvements.
I think that there is no need for GRASS 8 at this moment, it's not
related to GRASS 7 release management. The real problem is that we
don't have clear list of desired features for GRASS 7. Once we start
with RC stage we need to be sure that we are close to the final
release - to avoid RC for months or even several months like happen in
the past. We should also vote about RFC4 before we start with RC
stage. Personally I would start with GRASS 8 when there will be a
clear reason for that.
This sound ok to me. So, ideally, at all times we should have one release
branch and one development branch. Releases can then just be tagged from the
release branch which gets only selected, well-tested, not to invasive
backports from the dev branch.
That is also reason why I would keep trunk as 7.1 before we start with
tagging 7.0.0RC1.
Once we decide that the dev branch is sufficiently different from release
that backports become unfeasible, and sufficiently stabilised that we can
branch a release branch out of it, we declare the previous release branch a
legacy maintenance branch (with only limited bug fixing from that point on),
and branch a new release branch.
I would prefer to create just release branches. E.g.
* We start with tagging 7.0.0RC1.
* We create releasebranch_7_1 from trunk
* Trunk becomes 7.2 or GRASS 8
* We continue with backports only in releasebranch_7_0 towards final release
* Development will continue in trunk and releasebranch_7_1
* After some period we freeze releasebranch_7_1 and create
releasebrach_7_2 from trunk/releasebranch_7_1.
* We start RC stage in releasebranch_7_1
* Development will continue in trunk a releasebranch_7_2.
[...]
But, even though, I know you are in a hurry to get a grass7 release out of
the door, don't you think that we should finish 6.4.4 first ?To be honest I think we will have to accept shipping OSGEOLive with 6.4.4...
Right, as far as I know Markus is off-line since 27/6. So let's start
with idea to mark RC2 as a final and release it _this_week_! I don't
know about any blockers. Any opinion? If you know about blockers let
us know about that ASAP!
Martin
On 23/06/14 17:35, Martin Landa wrote:
Hi,
2014-06-23 10:56 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:
... so, getting out 7.0 seems to be endless...
A radical solution might be to change trunk into GRASS GIS 8. Then we
do not need to wait in 7 for API stabilization and can release it "as
is" and go ahead with the planned massive improvements.I think that there is no need for GRASS 8 at this moment, it's not
related to GRASS 7 release management. The real problem is that we
don't have clear list of desired features for GRASS 7. Once we start
with RC stage we need to be sure that we are close to the final
release - to avoid RC for months or even several months like happen in
the past. We should also vote about RFC4 before we start with RC
stage. Personally I would start with GRASS 8 when there will be a
clear reason for that.This sound ok to me. So, ideally, at all times we should have one release
branch and one development branch. Releases can then just be tagged from the
release branch which gets only selected, well-tested, not to invasive
backports from the dev branch.That is also reason why I would keep trunk as 7.1 before we start with
tagging 7.0.0RC1.Once we decide that the dev branch is sufficiently different from release
that backports become unfeasible, and sufficiently stabilised that we can
branch a release branch out of it, we declare the previous release branch a
legacy maintenance branch (with only limited bug fixing from that point on),
and branch a new release branch.I would prefer to create just release branches. E.g.
* We start with tagging 7.0.0RC1.
* We create releasebranch_7_1 from trunk
* Trunk becomes 7.2 or GRASS 8
>
* We continue with backports only in releasebranch_7_0 towards final release
* Development will continue in trunk and releasebranch_7_1
* After some period we freeze releasebranch_7_1 and create
releasebrach_7_2 from trunk/releasebranch_7_1.
* We start RC stage in releasebranch_7_1
* Development will continue in trunk a releasebranch_7_2.
Ok, so you prefer a solution with three branches (besides the legacy maintenance branches), in this case
- releasebranchX.Y
- releasebranchX.Y+1
- trunk
?
This does have the advantage to allow experiments to happen in trunk. But it has the disadvantage of having to manage backporting between these branches.
My proposal would be just two branches:
- releasebranchX.Y
- trunk
The release branch would only live throughout the time of a specific release and then become legacy maintenance.
The question is how to introduce highly experimental stuff. We can open a windows between release branches to introduce new stuff in trunk. At one point (something like a month before the creation of a release branch) we stop any experimentation in trunk and iron out what needs ironing out before creating a release branch out of trunk...
This risk of that approach is that some feature will not be tested as long before release as in your proposal, but it has the advantage that everyone just works in trunk, with release branches just created at the time of releases. If I'm not mistaken this is more of less how QGIS development works, or ?
One option would be to have people experiment more in their personal trees and commit innovative features to trunk only when in late beta stage. This would probably mean switching to git or something like that since it seems more adapted to this style of development than subversion.
Moritz
On 23/06/14 17:35, Martin Landa wrote:
Hi,
2014-06-23 10:56 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:
But, even though, I know you are in a hurry to get a grass7 release out of
the door, don't you think that we should finish 6.4.4 first ?To be honest I think we will have to accept shipping OSGEOLive with 6.4.4...
Right, as far as I know Markus is off-line since 27/6. So let's start
with idea to mark RC2 as a final and release it _this_week_! I don't
know about any blockers. Any opinion? If you know about blockers let
us know about that ASAP!
I launched a new thread with an evaluation of current bugs and last call for fixes.
Two tickets seem to warrant a backport, but I'm not familiar enough with them to judge. Maybe we should just go ahead and backport, then release RC2, test that with a special focus on these two backports, and then release by the end of the week ?
Moritz
On Tue, Jun 24, 2014 at 10:10 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
My proposal would be just two branches:
- releasebranchX.Y
- trunkThe release branch would only live throughout the time of a specific release
and then become legacy maintenance.
I like your idea just two branches (stable and unstable!). This should
help our users to be less confused by the GRASS version system.
The question is how to introduce highly experimental stuff. We can open a
windows between release branches to introduce new stuff in trunk. At one
point (something like a month before the creation of a release branch) we
stop any experimentation in trunk and iron out what needs ironing out before
creating a release branch out of trunk...This risk of that approach is that some feature will not be tested as long
before release as in your proposal, but it has the advantage that everyone
just works in trunk, with release branches just created at the time of
releases. If I'm not mistaken this is more of less how QGIS development
works, or ?
Do you think that we can create branches for specific tasks, like for
example I would like to work to make GRASS compatible with python2 and
python3, so I would like to have a branch: python3?
One option would be to have people experiment more in their personal trees
and commit innovative features to trunk only when in late beta stage. This
would probably mean switching to git or something like that since it seems
more adapted to this style of development than subversion.
Personally I would love to move GRASS to a distributed revision
control system such as git/hg. making easier for developers to make
our branches (e.g. python3) and share easily experimental and/or not
working code, without the risk of breaking the trunk version.
Pietro
Hi,
To be honest I think we will have to accept shipping OSGEOLive with 6.4.4...
The focus there is a split between being a showcase for new features and
super-stable introduction for new users. (power users might see past small
transient bugs, but if a new user finds rough edges in the first 5-15 minutes,
or before they get past the initial learning curve, the window of opportunity
is lost and they'll give up)
So far the balance on the disc has been to more favour stable over new. Feature
freeze is in just a couple weeks, QGIS plugin would need to be 100% ready and
rebuilt, and we'd not have a sample dataset included, would need to have a
GRASS_BATCH_FILE import script to set one up from the data already on the
disc.
fyi I plan to write a script which will be on the disc which will automatically
add the appropriate ppa repos and download+install the latest grass7 snapshot
and sample data. What version does the foss4g workshop want to use? Note the NC
dataset only ships in geotiff+shapefile form so it can be used by all the
other projects too, due to disc space limitations the workshop setup will
have to download that too. (spearfish is small enough to include for G6 though)
There is a link on the live disc desktop to this URL:
http://trac.osgeo.org/osgeo/wiki/Live_GIS_Workshop_Install
fwiw I will also be writing a G6 script for pre-installing some G6 addon modules.
If you have any you want included, place your orders in a osgeo trac ticket
please (LiveDVD component), cc 'hamish'.
Right, as far as I know Markus is off-line since 27/6. So let's start
with idea to mark RC2 as a final and release it _this_week_! I don't
know about any blockers. Any opinion? If you know about blockers let
us know about that ASAP!
I have been very busy with work recently, and will be for the next weeks too.
In the past I've been able to review all commits to the stable branch, right
now I am rather behind in that task. So if it goes out now just be warned that
I might be asking for a small-change 6.4.5 release after a month as some sort
of 6.4.4.1, since there are always some bugs to find. 
I would also be a
bit slow on the Debian packaging this time and not sure if I could write the
release announcement. Work and GSoC has all my time right now, sorry.
fwiw the debian rule for packages being accepted into the stable branch is not
that they are perfect, only that they are less buggy than the old version. For
the spatialite export bug I think that's fair advice to follow: it is not fixed,
but no more broken than the previous release. Since v.out.ogr is such a critical
module, and the fix requires the module to be improved with a bunch of 2D vs 3D
export logic, my vote would be to release 6.4.4 without it, but then try hard
soon after release to get it fixed, so maximum pre-release testing time. -- Even
though it's pretty crazy/embarrassing that GRASS isn't supporting export to
Spatialite currently. My thoughts on r.li are very similar, chances are that the
big backport still has some maturing to do, but the earlier version was wrong
so perhaps-problems-but-improving beats known-bad.
best regards,
Hamish
Hi,
2014-06-24 11:06 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:
Two tickets seem to warrant a backport, but I'm not familiar enough with
could you write us which tickets you have in mind? Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
On Tue, Jun 24, 2014 at 10:05 AM, Martin Landa <landa.martin@gmail.com>
wrote:
Hi,
2014-06-24 11:06 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:
> Two tickets seem to warrant a backport, but I'm not familiar enough withcould you write us which tickets you have in mind? Martin
I think that for this Moritz created different thread to not mess this one
with specific issues.
[GRASS-dev] Critical bugs for 6.4.4 release: last chance to react,
otherwise we'll release with these bugs
http://lists.osgeo.org/pipermail/grass-dev/2014-June/069641.html
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
2014-06-24 16:21 GMT+02:00 Vaclav Petras <wenzeslaus@gmail.com>:
[...]
I think that for this Moritz created different thread to not mess this one
with specific issues.[GRASS-dev] Critical bugs for 6.4.4 release: last chance to react, otherwise
we'll release with these bugs
OK, Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
On Tue, Jun 24, 2014 at 5:32 AM, Pietro <peter.zamb@gmail.com> wrote:
On Tue, Jun 24, 2014 at 10:10 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
> My proposal would be just two branches:
>
> - releasebranchX.Y
> - trunk
>
> The release branch would only live throughout the time of a specific
release
> and then become legacy maintenance.I like your idea just two branches (stable and unstable!). This should
help our users to be less confused by the GRASS version system.I agree. The alternative is to end up with release, devel_for_release and
trunk which we already had and we were not satisfied.
> The question is how to introduce highly experimental stuff. We can open a
> windows between release branches to introduce new stuff in trunk. At one
> point (something like a month before the creation of a release branch) we
> stop any experimentation in trunk and iron out what needs ironing out
before
> creating a release branch out of trunk...
>
> This risk of that approach is that some feature will not be tested as
long
> before release as in your proposal, but it has the advantage that
everyone
> just works in trunk, with release branches just created at the time of
> releases. If I'm not mistaken this is more of less how QGIS development
> works, or ?Do you think that we can create branches for specific tasks, like for
example I would like to work to make GRASS compatible with python2 and
python3, so I would like to have a branch: python3?This would be very useful in making the two branches policy work smoothly.
Let the experiments happen in branch and then merge them to trunk. How
difficult is this in SVN? I remember that for temporal framework Soeren end
up with local code and then he committed directly to trunk. Branches would
be of course just for bigger projects, for example for python3 or for API
changes.
> One option would be to have people experiment more in their personal
trees
> and commit innovative features to trunk only when in late beta stage.
This
> would probably mean switching to git or something like that since it
seems
> more adapted to this style of development than subversion.Personally I would love to move GRASS to a distributed revision
control system such as git/hg. making easier for developers to make
our branches (e.g. python3) and share easily experimental and/or not
working code, without the risk of breaking the trunk version.I would prefer Git over SVN. It would help me a lot in my workflows (e.g.,
local branch with my commits and then merge to trunk/master). However, I'm
not sure if this is feasible for GRASS now, it seems that move to SVN
happened just while ago. This depends on how difficult would be to use
experimental branches in SVN as suggested above. We should try SVN first.
The true is that a lot of projects migrate to Git and/or they have at least
mirror at GitHub (or some other but usually GitHub) of their repository
(does mirroring work for SVN?). Moreover, because of my GSoC, I'm looking
at some quality assurance online tools and lots of them require GitHub
repository. Also note that Trac >1.0 has a support for Git, although it is
(was?) considered slower.
Vaclav
Just noting, that I like Martin's analogy to GRASS 5.0 versus 5.1 some
time ago. History is repeating.
2014-06-23 17:35 GMT+02:00 Martin Landa <landa.martin@gmail.com>:
Hi,
2014-06-23 10:56 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:
... so, getting out 7.0 seems to be endless...
A radical solution might be to change trunk into GRASS GIS 8. Then we
do not need to wait in 7 for API stabilization and can release it "as
is" and go ahead with the planned massive improvements.I think that there is no need for GRASS 8 at this moment, it's not
related to GRASS 7 release management. The real problem is that we
don't have clear list of desired features for GRASS 7. Once we start
with RC stage we need to be sure that we are close to the final
release - to avoid RC for months or even several months like happen in
the past. We should also vote about RFC4 before we start with RC
stage. Personally I would start with GRASS 8 when there will be a
clear reason for that.This sound ok to me. So, ideally, at all times we should have one release
branch and one development branch. Releases can then just be tagged from the
release branch which gets only selected, well-tested, not to invasive
backports from the dev branch.That is also reason why I would keep trunk as 7.1 before we start with
tagging 7.0.0RC1.Once we decide that the dev branch is sufficiently different from release
that backports become unfeasible, and sufficiently stabilised that we can
branch a release branch out of it, we declare the previous release branch a
legacy maintenance branch (with only limited bug fixing from that point on),
and branch a new release branch.I would prefer to create just release branches. E.g.
* We start with tagging 7.0.0RC1.
* We create releasebranch_7_1 from trunk
* Trunk becomes 7.2 or GRASS 8
* We continue with backports only in releasebranch_7_0 towards final release
* Development will continue in trunk and releasebranch_7_1
* After some period we freeze releasebranch_7_1 and create
releasebrach_7_2 from trunk/releasebranch_7_1.
* We start RC stage in releasebranch_7_1
* Development will continue in trunk a releasebranch_7_2.[...]
But, even though, I know you are in a hurry to get a grass7 release out of
the door, don't you think that we should finish 6.4.4 first ?To be honest I think we will have to accept shipping OSGEOLive with 6.4.4...
Right, as far as I know Markus is off-line since 27/6. So let's start
with idea to mark RC2 as a final and release it _this_week_! I don't
know about any blockers. Any opinion? If you know about blockers let
us know about that ASAP!Martin
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp