Hi all,
it's long time ago when GRASS 7.0.0beta3 has been published (more then
two months ago). I would suggest to publish beta4, what do you think?
Is there any blocker or something which should be finished (e.g.
g.list/g.remove backports)?
Cheers, Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa *
http://www.gismentors.eu/mentors/landa
On Oct 26, 2014 12:22 PM, “Martin Landa” <landa.martin@gmail.com> wrote:
Hi all,
it’s long time ago when GRASS 7.0.0beta3 has been published (more then
two months ago). I would suggest to publish beta4, what do you think?
Is there any blocker or something which should be finished (e.g.
g.list/g.remove backports)?
There are two important blockers:
Ciao
Markus
Cheers, Martin
–
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa *
http://www.gismentors.eu/mentors/landa
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
2014-10-26 17:51 GMT+01:00 Markus Neteler <neteler@osgeo.org>:
There are two important blockers:
- the g.list etc backport
OK
-the python API back port
it seems to be done by Pietro in r62382. Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa *
http://www.gismentors.eu/mentors/landa
On Sun, Oct 26, 2014 at 5:51 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Oct 26, 2014 12:22 PM, "Martin Landa" <landa.martin@gmail.com> wrote:
There are two important blockers:
- the g.list etc backport
- the python API back port
... additionally also the .po files to be done. I can do that as soon
as the python API backport is settled...
Markus
On Sun, Oct 26, 2014 at 9:05 PM, Martin Landa <landa.martin@gmail.com> wrote:
2014-10-26 17:51 GMT+01:00 Markus Neteler <neteler@osgeo.org>:
-the python API back port
it seems to be done by Pietro in r62382. Martin
That is a part - it needs to include the Sphinx docs as well. Happy to
help, we just need to coordinate the efforts.
Markus
PS: I was wondering about a partial bulk backport here, see
https://stackoverflow.com/questions/4547142/svn-automate-merge-of-trunk-into-branch
On Sun, Oct 26, 2014 at 12:51 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Oct 26, 2014 12:22 PM, "Martin Landa" <landa.martin@gmail.com> wrote:
>
> Hi all,
>
> it's long time ago when GRASS 7.0.0beta3 has been published (more then
> two months ago). I would suggest to publish beta4, what do you think?
> Is there any blocker or something which should be finished (e.g.
> g.list/g.remove backports)?There are two important blockers:
- the g.list etc backport
I backported g.remove/g.list in r62393 and r62396.
Best,
Huidae
-the python API back port
Ciao
Markus> Cheers, Martin
>
> --
> Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa *
> http://www.gismentors.eu/mentors/landa
> _______________________________________________
> 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
Hi,
On Sun, Oct 26, 2014 at 9:50 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Sun, Oct 26, 2014 at 9:05 PM, Martin Landa <landa.martin@gmail.com> wrote:
2014-10-26 17:51 GMT+01:00 Markus Neteler <neteler@osgeo.org>:
-the python API back port
it seems to be done by Pietro in r62382. Martin
That is a part - it needs to include the Sphinx docs as well. Happy to
help, we just need to coordinate the efforts.
I tried to close the gap between the pygrass version in trunk and in
release candidate, now they are at the same level.
I agree with you, we should backport also the sphinx docs.
PS: I was wondering about a partial bulk backport here, see
https://stackoverflow.com/questions/4547142/svn-automate-merge-of-trunk-into-branch
I think that this option could be extremely helpful when/if we will
make a python3 branch of GRASS.
Pietro
On Sun, Oct 26, 2014 at 7:22 AM, Martin Landa <landa.martin@gmail.com>
wrote:
Hi all,
it's long time ago when GRASS 7.0.0beta3 has been published (more then
two months ago). I would suggest to publish beta4, what do you think?
Is there any blocker or something which should be finished (e.g.
g.list/g.remove backports)?Hi,
I was working on #2326 a little bit last week but I'm far from finishing. I
have a first implementation of raise in run/write/read command functions
and some changes make GUI start again. Nothing done on the rest of the code.
A branch would be helpful for this, by the way.
We've been also discussing removing things from __init__.py files. I'm not
sure if we should apply this but we probably should replace the practice
import grass.script as grass
by something more reasonable, explicit imports of things or
import grass.script as gscript
or
import grass.script.core as gcore
import grass.script.core as gscore
Depending on what we consider more stable or nier and if we will empty
__init__.py.
Vaclav
http://trac.osgeo.org/grass/ticket/2326
Cheers, Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa *
http://www.gismentors.eu/mentors/landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi Vaclav,
On Tue, Oct 28, 2014 at 4:09 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Sun, Oct 26, 2014 at 7:22 AM, Martin Landa <landa.martin@gmail.com>
wrote:it's long time ago when GRASS 7.0.0beta3 has been published (more then
two months ago). I would suggest to publish beta4, what do you think?
Is there any blocker or something which should be finished (e.g.
g.list/g.remove backports)?I was working on #2326 a little bit last week but I'm far from finishing. I
have a first implementation of raise in run/write/read command functions and
some changes make GUI start again. Nothing done on the rest of the code.
Thanks for that!
A branch would be helpful for this, by the way.
yes, I also think that a branch would be useful... Do all the changes
that we need to do in one big commit it seems unfeasible, and without
a branch it is quite difficult to share and work as a team...
So have some branches with a very precise scope like: #2326 or make
GRASS compatible with python3 that can be reach in a short time (2
weeks/ 1 month), should allow us to broke GRASS without the fear of
bothering other users/developers until we reach a pretty stable code
that can be included to trunk.
IMO these branches should be automatically synchronized with trunk and
have a responsible to manage/handle the conflict that could raise from
the merging process.
[OT] I think git/github could make these things easier...
We've been also discussing removing things from __init__.py files. I'm not
sure if we should apply this but we probably should replace the practiceimport grass.script as grass
+1
It has always looked weird to me.
by something more reasonable, explicit imports of things or
import grass.script as gscript
or
import grass.script.core as gcore
import grass.script.core as gscore
+1
Pietro
Hi,
concerning the upcoming beta4 release, it would be nice to have
- python docs backport (Sphinx)
- finish dead code cleanup
(http://grasswiki.osgeo.org/wiki/GRASS_7_ideas_collection#Dead_code_cleanup)
- temporal GIS re-sync (?)
- anything else?
Markus
On Sun, Nov 2, 2014 at 2:36 PM, Markus Neteler <neteler@osgeo.org> wrote:
- anything else?
#2326 needs to be solved. It's originally major but the solution we agreed
on with Glynn makes it a clear blocker because it changes API. The reason
why it changes API is that the API was purely designed. We need to change
it before 7.0, so that people can start using the right interface. The
challenging part is affected code in GRASS GIS [2]. There is a lot of
changes required and there is no chance we can test all before (without)
releasing new version because the test coverage is very low.
[1] http://trac.osgeo.org/grass/ticket/2326
[2] http://trac.osgeo.org/grass/ticket/2326#comment:5
On 02/11/14 20:36, Markus Neteler wrote:
Hi,
concerning the upcoming beta4 release, it would be nice to have
- python docs backport (Sphinx)
- finish dead code cleanup
(http://grasswiki.osgeo.org/wiki/GRASS_7_ideas_collection#Dead_code_cleanup)
- temporal GIS re-sync (?)
- anything else?
Yes, I think that #2439 (g.gui.iclass / wxdigit crashes) needs to be solved before we ship grass7.0.
Moritz
On Sun, Nov 2, 2014 at 5:08 PM, Moritz Lennert <mlennert@club.worldonline.be
wrote:
On 02/11/14 20:36, Markus Neteler wrote:
Hi,
concerning the upcoming beta4 release, it would be nice to have
- python docs backport (Sphinx)
Luca, are you or anyone else planning to do that?
- finish dead code cleanup
(http://grasswiki.osgeo.org/wiki/GRASS_7_ideas_collection#
Dead_code_cleanup)
- temporal GIS re-sync (?)
- anything else?Yes, I think that #2439 (g.gui.iclass / wxdigit crashes) needs to be
solved before we ship grass7.0.
and some more feedback on Glynn's suggestion to re-examine how
floating-point values are converted to integers in fpreclass.c and
put_row.c would be appreciated...
http://trac.osgeo.org/grass/ticket/2053#comment:8
Anna
Moritz
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
to better coordinate the missing items for the upcoming beta4 release,
I have added a list at
http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing
--> Beta 4 release (TODOs): being planned as last beta before RC1
Please check (and update).
Markus
On 08/11/14 22:44, Markus Neteler wrote:
Hi,
to better coordinate the missing items for the upcoming beta4 release,
I have added a list athttp://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing
--> Beta 4 release (TODOs): being planned as last beta before RC1Please check (and update).
"temporal GIS backport to relbranch70 "
Is this really something we want to do in a beta4 stage ? AFAICT, the new version has not been tested extensively, or ?
Moritz
On Mon, Nov 10, 2014 at 8:51 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 08/11/14 22:44, Markus Neteler wrote:
Hi,
to better coordinate the missing items for the upcoming beta4 release,
I have added a list athttp://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing
--> Beta 4 release (TODOs): being planned as last beta before RC1Please check (and update).
"temporal GIS backport to relbranch70 "
Is this really something we want to do in a beta4 stage ?
Yes of course. At least partially since we cannot change the user
interface later nor rename modules or remove some.
Otherwise we'll see this in GRASS GIS 8 only.
AFAICT, the new version has not been tested extensively, or ?
That's what the beta is for.
Additionally there is a blocker bug open about where the temporal DB goes.
Markus
Hi devs,
On 6 November 2014 05:45, Anna Petrášová <kratochanna@gmail.com> wrote:
Luca, are you or anyone else planning to do that?
I'm going to backport all the python sphinx documentation, bot for
lib/python than gui/wxpython.
It's really a lot of changes. I spent several hours to try to backport
only the right stuff.
I didn't backport:
- the temporal documentation and some changes related to it
- something related to g.gui.rlisetup because I have to commit to some
changes in trunk before
- gunnintest docs and several test.
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
On Tue, Nov 11, 2014 at 4:19 PM, Luca Delucchi <lucadeluge@gmail.com> wrote:
Hi devs,
On 6 November 2014 05:45, Anna Petrášová <kratochanna@gmail.com> wrote:
Luca, are you or anyone else planning to do that?
I'm going to backport all the python sphinx documentation, bot for
lib/python than gui/wxpython.
It's really a lot of changes. I spent several hours to try to backport
only the right stuff.
Well done, Luca! Have have generated the docs (anticipated the
Saturday cronjob):
http://grass.osgeo.org/grass70/manuals/libpython/
I didn't backport:
- the temporal documentation and some changes related to it
- something related to g.gui.rlisetup because I have to commit to some
changes in trunk before
- gunnintest docs and several test.
Also some Python lib differences are yet there.
Markus
On 11 November 2014 22:13, Markus Neteler <neteler@osgeo.org> wrote:
On Tue, Nov 11, 2014 at 4:19 PM, Luca Delucchi <lucadeluge@gmail.com> wrote:
Hi devs,
On 6 November 2014 05:45, Anna Petrášová <kratochanna@gmail.com> wrote:
Luca, are you or anyone else planning to do that?
I'm going to backport all the python sphinx documentation, bot for
lib/python than gui/wxpython.
It's really a lot of changes. I spent several hours to try to backport
only the right stuff.Well done, Luca! Have have generated the docs (anticipated the
Saturday cronjob):
http://grass.osgeo.org/grass70/manuals/libpython/
Ok I found a small problem in the index there is this line
"Testing GRASS GIS source code and modules: (gunittest package"
but in GRASS 7.0 there is not gunittest package.
I don't understand if gunittest will be backported before 7.0 release,
if we backport we can leave that line, otherwise it should be removed
I didn't backport:
- the temporal documentation and some changes related to it
- something related to g.gui.rlisetup because I have to commit to some
changes in trunk before
- gunnintest docs and several test.Also some Python lib differences are yet there.
yes something...
Markus
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
Hi all,
http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing
the only (?) remaining outstanding missing backport is the temporal framework...
What do you plan, Soeren?
thanks
Markus