Blockers #3617 and #3621 apply to 7.6 as well as 7.4. Broken in all versions 7.4.1 on up. No way to get a map out of GRASS on the Mac.
Michael
_________________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
On 8/25/18, 10:27 AM, "grass-dev on behalf of grass-dev-request@lists.osgeo.org" <grass-dev-bounces@lists.osgeo.org on behalf of grass-dev-request@lists.osgeo.org> wrote:
Date: Sat, 25 Aug 2018 18:27:10 +0200
From: Markus Neteler <neteler@osgeo.org>
To: Vaclav Petras <wenzeslaus@gmail.com>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] [release planning] 7.6.0
Message-ID:
<CALFmHhsnAKF11nAeqNbZ9Qu+0DcSvcWHqA2OsSEP+gnpeo_mZg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Wed, Aug 22, 2018 at 3:34 AM Vaclav Petras <wenzeslaus@gmail.com> wrote:
>On Tue, Jun 26, 2018 at 10:33 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
>>On Sun, Jun 17, 2018 at 5:24 PM, Markus Neteler <neteler@osgeo.org> wrote:
>>>On Mon, Jun 11, 2018 at 6:07 PM, Markus Neteler <neteler@osgeo.org> wrote:
...
>>#3585 Don't require -c for --tmp-location
>>#3586 Add XY location to grass command interface
>>
>>#3585 (Don't require -c for --tmp-location) – GRASS GIS
>>#3586 (Add XY location to grass command interface) – GRASS GIS
>>
>
>I fixed and closed these two last week.
Thanks a lot!
>#3348 or other bugs or annoyances don't prevent us from branching as they don't involve large code changes
>which would make subsequent backports impossible nor they are API changes which could lead to bad legacy APIs or API breaks.
ok.
>There are no tickets marked as blocker or critical and there is only 8 defect tickets.
Blockers #3617 and #3621 apply to 7.6 as well as 7.4. Broken in all versions 7.4.1 on up. No way to get a map out of GRASS on the Mac.
Some of these may be fixed in the patch provided by Sanjeet as part of GSoC when she was working on wxPython4 compatibility. So I would first put her changes to trunk (once we create the new branch) and then backport selected fixes.
Anna
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
On Sun, Jun 17, 2018 at 5:24 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Mon, Jun 11, 2018 at 6:07 PM, Markus Neteler <neteler@osgeo.org> wrote:
… #3585 Don’t require -c for --tmp-location #3586 Add XY location to grass command interface
#3348 or other bugs or annoyances don’t prevent us from branching as they don’t involve large code changes
which would make subsequent backports impossible nor they are API changes which could lead to bad legacy APIs or API breaks.
ok.
There are no tickets marked as blocker or critical and there is only 8 defect tickets.
On Mon, Aug 27, 2018 at 3:35 AM Anna Petrášová <kratochanna@gmail.com> wrote:
On Sun, Aug 26, 2018 at 12:35 PM Michael Barton <Michael.Barton@asu.edu> wrote:
Blockers #3617 and #3621 apply to 7.6 as well as 7.4. Broken in all versions 7.4.1 on up. No way to
get a map out of GRASS on the Mac.
Some of these may be fixed in the patch provided by Sanjeet as part of GSoC when she was
working on wxPython4 compatibility. So I would first put her changes to trunk
Can you please point us to the latest patch?
(once we create the new branch) and then backport selected fixes.
I was thinking about it again: we are yet one of the few packages
requiring Python2. What if some of us try the Python3 patch and give
feedback (of course an ideal thing for a git branch...)?
And then, if nothing dramatic goes wrong, we merge it prior to
creating the relbranch76?
Reflecting about our common release frequency I fear that we end up
with 7.8 in the (far) future to make GRASS GIS ready for Python3.
So: I volunteer to patch locally and test etc. the new Python3 support.
Am 27. August 2018 07:52:22 MESZ schrieb Markus Neteler <neteler@osgeo.org>:
On Mon, Aug 27, 2018 at 3:35 AM Anna Petrášová <kratochanna@gmail.com>
wrote:
On Sun, Aug 26, 2018 at 12:35 PM Michael Barton
<Michael.Barton@asu.edu> wrote:
Blockers #3617 and #3621 apply to 7.6 as well as 7.4. Broken in all
versions 7.4.1 on up. No way to
get a map out of GRASS on the Mac.
Some of these may be fixed in the patch provided by Sanjeet as part
of GSoC when she was
working on wxPython4 compatibility. So I would first put her changes
to trunk
Can you please point us to the latest patch?
(once we create the new branch) and then backport selected fixes.
I was thinking about it again: we are yet one of the few packages
requiring Python2. What if some of us try the Python3 patch and give
feedback (of course an ideal thing for a git branch...)?
And then, if nothing dramatic goes wrong, we merge it prior to
creating the relbranch76?
Reflecting about our common release frequency I fear that we end up
with 7.8 in the (far) future to make GRASS GIS ready for Python3.
So: I volunteer to patch locally and test etc. the new Python3 support.
Opinions?
+1
I think Python 3 support should be a must nowadays.
I didn't follow Sanjeet's GSoC work very closely. How far are we in theory with Python 3 support with her patches ?
-----Original Message-----
From: grass-dev <grass-dev-bounces@lists.osgeo.org> On Behalf Of Moritz Lennert
Sent: mandag 27. august 2018 07:59
To: grass-dev@lists.osgeo.org; Markus Neteler <neteler@osgeo.org>; GRASS developers list <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] [release planning] 7.6.0
Am 27. August 2018 07:52:22 MESZ schrieb Markus Neteler <neteler@osgeo.org>:
On Mon, Aug 27, 2018 at 3:35 AM Anna Petrášová <kratochanna@gmail.com>
wrote:
On Sun, Aug 26, 2018 at 12:35 PM Michael Barton
<Michael.Barton@asu.edu> wrote:
Blockers #3617 and #3621 apply to 7.6 as well as 7.4. Broken in all
versions 7.4.1 on up. No way to
get a map out of GRASS on the Mac.
Some of these may be fixed in the patch provided by Sanjeet as part
of GSoC when she was
working on wxPython4 compatibility. So I would first put her changes
to trunk
Can you please point us to the latest patch?
(once we create the new branch) and then backport selected fixes.
I was thinking about it again: we are yet one of the few packages
requiring Python2. What if some of us try the Python3 patch and give
feedback (of course an ideal thing for a git branch...)?
And then, if nothing dramatic goes wrong, we merge it prior to creating
the relbranch76?
Reflecting about our common release frequency I fear that we end up
with 7.8 in the (far) future to make GRASS GIS ready for Python3.
So: I volunteer to patch locally and test etc. the new Python3 support.
Opinions?
+1
I think Python 3 support should be a must nowadays.
I didn't follow Sanjeet's GSoC work very closely. How far are we in theory with Python 3 support with her patches ?
--> "There are patches in the respective directories in the
grass_trunk. The patches have been created against the svn revision
73073 of GRASS GIS."
... in essence: the longer we wait, the more difficult will be to use
these patches.
And: by experience we know that bugs only get fixed when they are evident
# I have now forked the FullSupportPython3 github project, then therein:
cd FullSupportPython3/grass_trunk/
# generate combi-patch
cat */* > python3_patch.diff
# change to local trunk copy
cd ~/software/grass7_trunk/
# apply patch
patch -p0 < ~/software/grass75_FullSupportPython3/grass_trunk/python3_patch.diff
po 27. 8. 2018 v 8:53 odesílatel Markus Neteler <neteler@osgeo.org> napsal:
… in essence: the longer we wait, the more difficult will be to use
these patches.
I would guess that Anna is planning to apply these patches to trunk
when releasebranch_7_6 will be there (?)
That was the plan. I am worried if it goes into 7.6 it will slow down the release. We could then release 7.8 with full Python3 support as the main feature sooner.
→ “There are patches in the respective directories in the
grass_trunk. The patches have been created against the svn revision
73073 of GRASS GIS.”
… in essence: the longer we wait, the more difficult will be to use
these patches.
And: by experience we know that bugs only get fixed when they are evident
I have now forked the FullSupportPython3 github project, then therein:
Perhaps FullSupportPython3 git needs to be rebased to current trunk?
It still works for me, there are 2 patches for ctypes, I use the patch_ctypes_changes_from_fork.diff, that might be the issue you have. But I agree it needs to be merged soon.
That would be great. I am hopeful that these might fix many issues. Can we separate those that pertain to wxPython 4 from those that are generally Python 3 related? Even if there is delay in moving to Python 3, the fixes for wxPython can be used in Python 2 environments.
Michael
···
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Blockers #3617 and #3621 apply to 7.6 as well as 7.4. Broken in all versions 7.4.1 on up. No way to get a map out of GRASS on the Mac.
Some of these may be fixed in the patch provided by Sanjeet as part of GSoC when she was working on wxPython4 compatibility. So I would first put her changes to trunk (once we create the new branch) and then backport selected fixes.
Anna
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
On Sun, Jun 17, 2018 at 5:24 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Mon, Jun 11, 2018 at 6:07 PM, Markus Neteler <neteler@osgeo.org> wrote:
… #3585 Don’t require -c for --tmp-location #3586 Add XY location to grass command interface
#3348 or other bugs or annoyances don’t prevent us from branching as they don’t involve large code changes
which would make subsequent backports impossible nor they are API changes which could lead to bad legacy APIs or API breaks.
ok.
There are no tickets marked as blocker or critical and there is only 8 defect tickets.
It still works for me, there are 2 patches for ctypes,
Ah, I had overlooked that.
I use the patch_ctypes_changes_from_fork.diff
that might be the issue you have. But I agree it needs to be merged soon.
Funny suggestion: we make a branch on the github mirror
Might simplify testing…
My guess is that it may complicate other things. Let’s just branch 7.6 in Subversion and apply the patches to trunk afterwards. Anna’s suggestion of a quick 7.8 release with Python 3 support makes sense. I’m just afraid that this might create big time gap between 7.8 and 8.0. In that case, I would lean towards putting these patches to 7.6 but only in case there is a lot of people eager to test the code ideally with both Python 2 and 3 because we won’t be switching to Python 3 being the recommend one yet (or?). In any case, there is no reason to postpone branching of 7.6. This can be still decided and merged later before 7.6.0 RC1.
On Mon, Aug 27, 2018 at 5:52 PM Markus Neteler <neteler@osgeo.org <mailto:neteler@osgeo.org>> wrote:
>
> On Mon, Aug 27, 2018 at 4:14 PM Anna Petrášová <kratochanna@gmail.com <mailto:kratochanna@gmail.com>> wrote:
> ...
> > It still works for me, there are 2 patches for ctypes,
>
> Ah, I had overlooked that.
>
> > I use the patch_ctypes_changes_from_fork.diff
> > that might be the issue you have. But I agree it needs to be merged soon.
>
> Funny suggestion: we make a branch on the github mirror
> Might simplify testing...
My guess is that it may complicate other things. Let's just branch 7.6 in Subversion and apply the patches to trunk afterwards. Anna's suggestion of a quick 7.8 release with Python 3 support makes sense. I'm just afraid that this might create big time gap between 7.8 and 8.0.
For many projects, moving to Python 3 justifies a jump to next major version...
My guess is that it may complicate other things. Let’s just branch 7.6
in Subversion and apply the patches to trunk afterwards. Anna’s
suggestion of a quick 7.8 release with Python 3 support makes sense. I’m
just afraid that this might create big time gap between 7.8 and 8.0.
For many projects, moving to Python 3 justifies a jump to next major
version…
So, finally a reason to move on to G8.x!
So, seems the majority wants the branch now and then fast forward to Python 3 in trunk with next major release soon.
st 29. 8. 2018 v 3:01 odesílatel Vaclav Petras <wenzeslaus@gmail.com> napsal:
sense. I'm just afraid that this might create big time gap between 7.8
and 8.0. In that case, I would lean towards putting these patches to
7.6 but only in case there is a lot of people eager to test the code
ideally with both Python 2 and 3 because we won't be switching to
Python 3 being the recommend one yet (or?). In any case, there is no
reason to postpone branching of 7.6. This can be still decided and
merged later before 7.6.0 RC1.
make sense to me. Initial Python3 could be part of 7.6.0 release. We
can improve it in point versions. But at first we need to test Python3
support in trunk. I will be happy to do it when possible.
