Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Thu, Feb 1, 2018 at 9:27 PM, Martin Landa  wrote:
> 2018-01-31 10:57 GMT+01:00 Martin Landa :
>> Ubuntu packages were uploaded to UbuntuGIS Unstable too (grass,
>> gdal-grass, and qgis (*)).
...
> also QGIS for Trusty updated. Ma

Great!
Fedora, EPEL 7 and even EPEL6 are also done.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2018-01-31 10:57 GMT+01:00 Martin Landa :
> Ubuntu packages were uploaded to UbuntuGIS Unstable too (grass,
> gdal-grass, and qgis (*)).
>
> Ma
>
> (*) there are still some problem when rebuilding QGIS for trusty, this
> package has been updated yet.

also QGIS for Trusty updated. Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[massimo di stefano]

You're right .. blind: ctrl+c / ctrl-v

```
sudo apt-add-repository --remove ppa:grass/grass-stable
```

And then update + upgrade gave me a shiny GRASS 74

Thanks.

> On Jan 31, 2018, at 6:29 PM, Martin Landa  wrote:
> 
> 2018-01-31 23:52 GMT+01:00 massimo di stefano :
>> # Add Ubuntu Unstable PPA when running LTS Ubuntu release
>> sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable
>> # Otherwise add GRASS Stable PPA
>> sudo add-apt-repository ppa:grass/grass-stable
> 
> you misunderstood the statement.
> 
> Run
> 
> sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable
> 
> when using LTS.
> 
> On non-LTS release (like Ubuntu 17.10) run
> 
> sudo add-apt-repository ppa:grass/grass-stable
> 
> instead.
> 
> So probably instructions needs some clarification ;-) Ma
> 
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa



signature.asc
Description: Message signed with OpenPGP
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

2018-01-31 23:52 GMT+01:00 massimo di stefano :
> # Add Ubuntu Unstable PPA when running LTS Ubuntu release
> sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable
> # Otherwise add GRASS Stable PPA
> sudo add-apt-repository ppa:grass/grass-stable

you misunderstood the statement.

Run

sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable

when using LTS.

On non-LTS release (like Ubuntu 17.10) run

sudo add-apt-repository ppa:grass/grass-stable

instead.

So probably instructions needs some clarification ;-) Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2018-01-31 23:52 GMT+01:00 massimo di stefano :
> Err:19 http://ppa.launchpad.net/grass/grass-stable/ubuntu xenial/main amd64
> Packages
>   404  Not Found
> Hit:48 http://download.onlyoffice.com/repo/debian squeeze InRelease
> Ign:20 http://ppa.launchpad.net/grass/grass-stable/ubuntu xenial/main i386
> Packages
> Ign:21 http://ppa.launchpad.net/grass/grass-stable/ubuntu xenial/main all
> Packages
> Ign:22 http://ppa.launchpad.net/grass/grass-stable/ubuntu xenial/main
> Translation-en

remove grass-stable PPA, it's useless for LTS.

> Get:49 http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu
> xenial/main amd64 Packages [49.3 kB]
> Get:51 http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu
> xenial/main i386 Packages [49.3 kB]
> Get:52 http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu
> xenial/main Translation-en [19.2 kB]
> Fetched 9,247 kB in 2s (4,091 kB/s)
> Reading package lists... Done
> W: The repository 'http://ppa.launchpad.net/grass/grass-stable/ubuntu xenial
> Release' does not have a Release file.
> N: Data from such a repository can't be authenticated and is therefore
> potentially dangerous to use.
> N: See apt-secure(8) manpage for repository creation and user configuration
> details.
> E: Failed to fetch
> http://ppa.launchpad.net/grass/grass-stable/ubuntu/dists/xenial/main/binary-amd64/Packages
> 404  Not Found
> E: Some index files failed to download. They have been ignored, or old ones
> used instead.

The error is related to grass-stable PPA. Please review your
registered PPAs first. Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[massimo di stefano]

Hi,

The ks for the release!

I was going to update a server running ubuntu 16.04, after running the 
instruction below:


# Add Ubuntu Unstable PPA when running LTS Ubuntu release
sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable
# Otherwise add GRASS Stable PPA
sudo add-apt-repository ppa:grass/grass-stable
Apt-get update gave me:


Err:19 http://ppa.launchpad.net/grass/grass-stable/ubuntu xenial/main amd64 
Packages
  404  Not Found
Hit:48 http://download.onlyoffice.com/repo/debian squeeze InRelease
Ign:20 http://ppa.launchpad.net/grass/grass-stable/ubuntu xenial/main i386 
Packages
Ign:21 http://ppa.launchpad.net/grass/grass-stable/ubuntu xenial/main all 
Packages
Ign:22 http://ppa.launchpad.net/grass/grass-stable/ubuntu xenial/main 
Translation-en
Get:49 http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu xenial/main 
amd64 Packages [49.3 kB]
Get:51 http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu xenial/main 
i386 Packages [49.3 kB]
Get:52 http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu xenial/main 
Translation-en [19.2 kB]
Fetched 9,247 kB in 2s (4,091 kB/s)
Reading package lists... Done
W: The repository 'http://ppa.launchpad.net/grass/grass-stable/ubuntu xenial 
Release' does not have a Release file.
N: Data from such a repository can't be authenticated and is therefore 
potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration 
details.
E: Failed to fetch 
http://ppa.launchpad.net/grass/grass-stable/ubuntu/dists/xenial/main/binary-amd64/Packages
  404  Not Found
E: Some index files failed to download. They have been ignored, or old ones 
used instead.


—Massimo.


> On Jan 31, 2018, at 5:44 PM, Markus Neteler  wrote:
> 
> On Wed, Jan 31, 2018 at 10:57 AM, Martin Landa  wrote:
>> Hi,
>> 
>> 2018-01-31 9:43 GMT+01:00 Moritz Lennert :
>>> Do we get a reasonable set of binaries ready for tomorrow?
>>> Then we could publish the announcement.
>> 
>> Ubuntu packages were uploaded to UbuntuGIS Unstable too (grass,
>> gdal-grass, and qgis (*)).
> 
> ok thanks!
> 
> Can (all) please verify that the download instructions are right?
> 
> * https://grass.osgeo.org/download/software/linux/#g74x
>  --> are the Ubuntu instructions right?
> 
> * https://grass.osgeo.org/download/software/ms-windows/#g74x
> * (Mac OSX forthcoming)
> * other systems?
> 
> thanks
> Markus
> 
>> Ma
>> 
>> (*) there are still some problem when rebuilding QGIS for trusty, this
>> package has been updated yet.
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev



signature.asc
Description: Message signed with OpenPGP
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Wed, Jan 31, 2018 at 10:57 AM, Martin Landa  wrote:
> Hi,
>
> 2018-01-31 9:43 GMT+01:00 Moritz Lennert :
>> Do we get a reasonable set of binaries ready for tomorrow?
>> Then we could publish the announcement.
>
> Ubuntu packages were uploaded to UbuntuGIS Unstable too (grass,
> gdal-grass, and qgis (*)).

ok thanks!

Can (all) please verify that the download instructions are right?

* https://grass.osgeo.org/download/software/linux/#g74x
  --> are the Ubuntu instructions right?

* https://grass.osgeo.org/download/software/ms-windows/#g74x
* (Mac OSX forthcoming)
* other systems?

thanks
Markus

> Ma
>
> (*) there are still some problem when rebuilding QGIS for trusty, this
> package has been updated yet.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2018-01-31 9:43 GMT+01:00 Moritz Lennert :
> Do we get a reasonable set of binaries ready for tomorrow?
> Then we could publish the announcement.

Ubuntu packages were uploaded to UbuntuGIS Unstable too (grass,
gdal-grass, and qgis (*)).

Ma

(*) there are still some problem when rebuilding QGIS for trusty, this
package has been updated yet.

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

On 30/01/18 20:49, Sebastiaan Couwenberg wrote:

On 01/30/2018 08:33 PM, Markus Neteler wrote:

On Sun, Jan 28, 2018 at 3:33 PM, Moritz Lennert
 wrote:

On 28/01/18 14:57, Markus Neteler wrote:

On Sat, Jan 27, 2018 at 12:13 AM, Markus Neteler 

On 26/01/18 11:14, Markus Neteler wrote:


...

I'll notify the packagers, and prepare announcement etc.



Do we get a reasonable set of binaries ready for tomorrow?
Then we could publish the announcement.


Bas has already uploaded to Debian unstable on Friday. It will normally
migrate to Debian testing in a few days.


Did that happen? Time to announce...!


Should migrate tomorrow, see:

  https://qa.debian.org/excuses.php?package=grass
  https://qa.debian.org/excuses.php?package=libgdal-grass
  https://qa.debian.org/excuses.php?package=qgis


Done: https://tracker.debian.org/news/928783

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Sebastiaan Couwenberg]

On 01/30/2018 08:33 PM, Markus Neteler wrote:
> On Sun, Jan 28, 2018 at 3:33 PM, Moritz Lennert
>  wrote:
>> On 28/01/18 14:57, Markus Neteler wrote:
>>> On Sat, Jan 27, 2018 at 12:13 AM, Markus Neteler 
 On 26/01/18 11:14, Markus Neteler wrote:
>>>
>>> ...
> I'll notify the packagers, and prepare announcement etc.
>>>
>>>
>>> Do we get a reasonable set of binaries ready for tomorrow?
>>> Then we could publish the announcement.
>>
>> Bas has already uploaded to Debian unstable on Friday. It will normally
>> migrate to Debian testing in a few days.
> 
> Did that happen? Time to announce...!

Should migrate tomorrow, see:

 https://qa.debian.org/excuses.php?package=grass
 https://qa.debian.org/excuses.php?package=libgdal-grass
 https://qa.debian.org/excuses.php?package=qgis

Kind Regards,

Bas

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Sun, Jan 28, 2018 at 3:33 PM, Moritz Lennert
 wrote:
> On 28/01/18 14:57, Markus Neteler wrote:
>> On Sat, Jan 27, 2018 at 12:13 AM, Markus Neteler 
>>> On 26/01/18 11:14, Markus Neteler wrote:
>>
>> ...
 I'll notify the packagers, and prepare announcement etc.
>>
>>
>> Do we get a reasonable set of binaries ready for tomorrow?
>> Then we could publish the announcement.
>
> Bas has already uploaded to Debian unstable on Friday. It will normally
> migrate to Debian testing in a few days.

Did that happen? Time to announce...!

thanks
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

On 28/01/18 14:57, Markus Neteler wrote:

On Sat, Jan 27, 2018 at 12:13 AM, Markus Neteler  wrote:

On 26/01/18 11:14, Markus Neteler wrote:

...

I'll notify the packagers, and prepare announcement etc.


Do we get a reasonable set of binaries ready for tomorrow?
Then we could publish the announcement.


Bas has already uploaded to Debian unstable on Friday. It will normally 
migrate to Debian testing in a few days.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2018-01-28 14:57 GMT+01:00 Markus Neteler :
> Do we get a reasonable set of binaries ready for tomorrow?
> Then we could publish the announcement.

Windows standalone and OSGeo4W already uploaded. Currently uploading
new packages to UbuntuGIS Expr (grass + gdal-grass + qgis), to build
all related packages takes a while. Then the packages will be copied
to UbuntuGIS Unstable. I hope today I will be able to finish the job.

Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Sat, Jan 27, 2018 at 12:13 AM, Markus Neteler  wrote:
> On 26/01/18 11:14, Markus Neteler wrote:
...
>> I'll notify the packagers, and prepare announcement etc.

Do we get a reasonable set of binaries ready for tomorrow?
Then we could publish the announcement.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Hi

Am 26.01.2018 3:12 nachm. schrieb "Moritz Lennert" <
mlenn...@club.worldonline.be>:

On 26/01/18 11:14, Markus Neteler wrote:

> On Fri, Jan 26, 2018 at 9:47 AM, Markus Neteler  wrote:
>
>> Hi devs,
>>
>> release time!
>> I am now starting to tag and package 7.4.0 final.
>>
>
> Done:
> https://grass.osgeo.org/grass74/source/grass-7.4.0.tar.gz
>
> I'll notify the packagers, and prepare announcement etc.
>

Hoorraay !!

Thanks a lot, Markus !


Well, thanks to so many developers!!
We need a hall of fame here :)

It is a community effort, with folks programming, bug fixing, writing docs,
crafting screenshots (that always take forever!), packaging, … so much
more. Even writing a bug report is not for free, and sometimes take effort
to dare to write it.

Thanks to the great GRASS GIS team and friends!

Best,
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

On 26/01/18 11:14, Markus Neteler wrote:

On Fri, Jan 26, 2018 at 9:47 AM, Markus Neteler  wrote:

Hi devs,

release time!
I am now starting to tag and package 7.4.0 final.


Done:
https://grass.osgeo.org/grass74/source/grass-7.4.0.tar.gz

I'll notify the packagers, and prepare announcement etc.


Hoorraay !!

Thanks a lot, Markus !

Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Fri, Jan 26, 2018 at 9:47 AM, Markus Neteler  wrote:
> Hi devs,
>
> release time!
> I am now starting to tag and package 7.4.0 final.

Done:
https://grass.osgeo.org/grass74/source/grass-7.4.0.tar.gz

I'll notify the packagers, and prepare announcement etc.

Markus

-- 
Markus Neteler, PhD
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Hi devs,

release time!
I am now starting to tag and package 7.4.0 final.

Best,
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Metz]

On Thu, Jan 25, 2018 at 8:23 PM, Helmut Kudrnovsky  wrote:
>
> Markus Neteler wrote
> > Am 25.01.2018 6:37 nachm. schrieb "Martin Landa" 
>
> > landa.martin@
>
> > :
> >
> > Hi,
> >
> > 2018-01-25 17:52 GMT+01:00 Markus Neteler 
>
> > neteler@
>
> > :
> >>> what about backporting changes in i.atcorr? Ma
> >>
> >> There are quite a lot, and still ongoing...
> >
> > probably @MarkusM will have opinion.

Usually I backport only bug fixes, last bug-fix backported with r72149. All
else are new features not to be backported.

> >
> >> The other option to finalize them and include them in a new RC3 prior
to
> > final.
> >
> > Than probably RC3 would be needed. Ma
> >
> >
> > I'm rather -0 to make again another RC.
> > Please let's publish 7.4.0 as it is now.
>
> I'm also in favor to release it now.

+1

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Helmut Kudrnovsky]

Markus Neteler wrote
> Am 25.01.2018 6:37 nachm. schrieb "Martin Landa" 

> landa.martin@

> :
> 
> Hi,
> 
> 2018-01-25 17:52 GMT+01:00 Markus Neteler 

> neteler@

> :
>>> what about backporting changes in i.atcorr? Ma
>>
>> There are quite a lot, and still ongoing...
> 
> probably @MarkusM will have opinion.
> 
>> The other option to finalize them and include them in a new RC3 prior to
> final.
> 
> Than probably RC3 would be needed. Ma
> 
> 
> I'm rather -0 to make again another RC.
> Please let's publish 7.4.0 as it is now.

I'm also in favor to release it now.




-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2018-01-25 20:11 GMT+01:00 Veronica Andreo :
> I think it would be better to release just now (next couple of days) and
> backport i.atcorr (great) changes to 7.4.1.

I tend to agree. Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Veronica Andreo]

El 25 ene. 2018 7:45 p.m., "Markus Neteler"  escribió:



Am 25.01.2018 6:37 nachm. schrieb "Martin Landa" :

Hi,

2018-01-25 17:52 GMT+01:00 Markus Neteler :
>> what about backporting changes in i.atcorr? Ma
>
> There are quite a lot, and still ongoing...

probably @MarkusM will have opinion.

> The other option to finalize them and include them in a new RC3 prior to
final.

Than probably RC3 would be needed. Ma


I'm rather -0 to make again another RC.
Please let's publish 7.4.0 as it is now.


I think it would be better to release just now (next couple of days) and
backport i.atcorr (great) changes to 7.4.1.

If we make another RC and all that we will be releasing very close to qgis
huge release (which is planned for feb 23) and nobody will notice our
release then.

My 2 cents

Vero
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Am 25.01.2018 6:37 nachm. schrieb "Martin Landa" :

Hi,

2018-01-25 17:52 GMT+01:00 Markus Neteler :
>> what about backporting changes in i.atcorr? Ma
>
> There are quite a lot, and still ongoing...

probably @MarkusM will have opinion.

> The other option to finalize them and include them in a new RC3 prior to
final.

Than probably RC3 would be needed. Ma


I'm rather -0 to make again another RC.
Please let's publish 7.4.0 as it is now.

Markus


--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2018-01-25 17:52 GMT+01:00 Markus Neteler :
>> what about backporting changes in i.atcorr? Ma
>
> There are quite a lot, and still ongoing...

probably @MarkusM will have opinion.

> The other option to finalize them and include them in a new RC3 prior to 
> final.

Than probably RC3 would be needed. Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Thu, Jan 25, 2018 at 5:27 PM, Martin Landa  wrote:
> Hi Markus,
>
> 2018-01-25 11:47 GMT+01:00 Markus Neteler :
>> Release date:
>> If there are no objections, I'd publish 7.4.0 by tomorrow.
>
> what about backporting changes in i.atcorr? Ma

There are quite a lot, and still ongoing...

The other option to finalize them and include them in a new RC3 prior to final.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi Markus,

2018-01-25 11:47 GMT+01:00 Markus Neteler :
> Release date:
> If there are no objections, I'd publish 7.4.0 by tomorrow.

what about backporting changes in i.atcorr? Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

On 25/01/18 11:47, Markus Neteler wrote:

Hi,

time to get 7.4.0 out of the door:

To be completed:
- https://trac.osgeo.org/grass/wiki/Release/7.4.0-News
- https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures74
   (more screenshots wanted!)


No time here, but some easy ideas:

- Screenshots already available in manuals of new modules (r.geomorphon, 
v.clip, ...)


- Screenshot of the data catalogue



Release date:
If there are no objections, I'd publish 7.4.0 by tomorrow.



+1 !

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Hi,

time to get 7.4.0 out of the door:

To be completed:
- https://trac.osgeo.org/grass/wiki/Release/7.4.0-News
- https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures74
  (more screenshots wanted!)

Release date:
If there are no objections, I'd publish 7.4.0 by tomorrow.

Best,
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Thu, Jan 18, 2018 at 2:05 PM, Stefan Blumentrath
 wrote:
> FYI: Seems OSGeo is considering to move from Transifex to Weblate 
> (https://weblate.org/en/)
> See: https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051488.html

FWIW: Weblate ticket :)
https://trac.osgeo.org/osgeo/ticket/2092

BTW: I think we should discuss this under a different subject than "release".

Cheers
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Stefan Blumentrath]

FYI: Seems OSGeo is considering to move from Transifex to Weblate 
(https://weblate.org/en/)
See: https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051488.html

Cheers
Stefan

-Original Message-
From: Maris Nartiss [mailto:maris@gmail.com] 
Sent: onsdag 17. januar 2018 11.50
To: Stefan Blumentrath <stefan.blumentr...@nina.no>
Cc: Moritz Lennert <mlenn...@club.worldonline.be>; Martin Landa 
<landa.mar...@gmail.com>; grass-dev <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] [release planning] 7.4.0

2018-01-16 22:31 GMT+02:00 Stefan Blumentrath <stefan.blumentr...@nina.no>:
> FYI:
> Seems Maris is not alone with his scepticism towards the benefits of 
> Transifex.
> Looks like several people in the QGIS project made not only good experience 
> with Transifex:
> See: 
> http://lists.osgeo.org/pipermail/qgis-developer/2018-January/051452.ht
> ml
Experience of Polish, Ukrainian and other teams starts a bit earlier in that 
thread:
https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051429.html

I am not against others using Tx as long as I (and other "teams") have an 
opt-out.

Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Maris Nartiss]

2018-01-16 22:31 GMT+02:00 Stefan Blumentrath :
> FYI:
> Seems Maris is not alone with his scepticism towards the benefits of 
> Transifex.
> Looks like several people in the QGIS project made not only good experience 
> with Transifex:
> See: http://lists.osgeo.org/pipermail/qgis-developer/2018-January/051452.html
Experience of Polish, Ukrainian and other teams starts a bit earlier
in that thread:
https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051429.html

I am not against others using Tx as long as I (and other "teams") have
an opt-out.

Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Stefan Blumentrath]

FYI:
Seems Maris is not alone with his scepticism towards the benefits of Transifex.
Looks like several people in the QGIS project made not only good experience 
with Transifex:
See: http://lists.osgeo.org/pipermail/qgis-developer/2018-January/051452.html


Von: grass-dev <grass-dev-boun...@lists.osgeo.org> im Auftrag von Moritz 
Lennert <mlenn...@club.worldonline.be>
Gesendet: Freitag, 12. Januar 2018 13:27
An: Maris Nartiss
Cc: Martin Landa; grass-dev
Betreff: Re: [GRASS-dev] [release planning] 7.4.0

Le Fri, 12 Jan 2018 13:00:41 +0200,
Maris Nartiss <maris@gmail.com> a écrit :

> 2018-01-07 23:24 GMT+02:00 Martin Landa <landa.mar...@gmail.com>:
> > Hi all,
> >
> > 2018-01-07 22:03 GMT+01:00 Veronica Andreo <veroand...@gmail.com>:
> >> Just out of curiosity: Why not use transifex also for Latvian? Is
> >> there any particular reason for that?
> >
> > I agree, to exclude LV from trasifex is not systematic approach once
> > we agreed that we will use transifex...
> >
> > Ma
> I somehow, as a current translator of GRASS to Latvian, don't remember
> agreeing for this.
>
> I fail to see any benefit of using web-based translation tools. Yes, I
> am familiar with Transifex and Launchpad, also with KBabel, Lokalize
> and fixing raw po files. I have been working as a coordinator of KDE
> Latvian "team" since 2005, translating QGIS and various smaller
> projects. And still I fail to see why moving to web based tool would
> be beneficial.
>
> Translating with a web interface is just a joke. Slow and cumbersome.
> Not convenient for fast review of large amount of strings. No
> scripting abilities. No diff support. No possibility to reject
> contributions. KDE project as whole rejected all translation work done
> in Launchpad (due to extremely low quality) before Ubuntu guys dropped
> KDE from Launchpad.
> Transifex still is showing wrong labels for plural form strings for
> Latvian language. I reported it in 2015 and their answer was "change
> string order in the file". (Really?!?) Thus anyone using web interface
> will provide wrong translations for Latvian language.
> "Easier to contribute" argument is also not solved by moving to web
> platform, as it still depends on people. I got access to translate one
> project on Transifex only after it was removed from my company
> production servers as being obsolete. Yes, I submitted my translated
> po file, but the fact that we managed to translate, integrate, test,
> deploy to production and replace with different component all before
> my request to add language and assign me rights to translate was
> fulfilled speaks on its own.
>
> QGIS moved to Transifex some time a go. Number of new contributors to
> Latvian language due to "it is easier to contribute": 0. Keep in mind
> – contrary to GRASS GIS, QGIS is widely used in Latvia, including some
> (millions € worth) governmental IT projects, thus one could expect
> large number of contributors; Recently a new issue was identified (see
> Qgis-tr Tue Jan 9 15:16:15 PST 2018) – it is hard to track
> contributors and thus list them in credits; Following multiple
> branches is still unsolved.
>
> KDE SC (number of strings approaches 200k, comparing to GRASS shy 15k)
> is still pure po+svn workflow (with teams being free to use anything
> as they wish as long as final output is a po file commit to svn). So
> far all proposals for global migration have died out (example:
> https://marc.info/?l=kde-i18n-doc=135873075615507=2); The Summit
> approach of KDE SC is worth of exploring – so far it is the best
> solution for tracking multiple branches simultaneously. Still Summit
> plays off only for really active teams.
>
> Finally – I fail to see any problem for skipping *_lv.po files as long
> as data exchange with Transifex is scripted (or I decide to move to
> ArcGIS). I'm not blocking others of using Transifex workflow, if it
> feels appealing for someone. Yes, that means that I'll have to do all
> pot->po merge dance for Latvian language and I'm fine with it.

I like Transifex and the idea that it potentially allows anyone to
easily to a translate a day without having to download the source code.

I do understand Maris' argument, however, and agree that Transifex'
interface does not make translation easier for someone who knows how to
handle the appropriate files. And I am sensitive to the argument that
we do not have an active translation community.

Maybe we should conduct a survey on the relevant mailing lists, but if
the whole Transifex migration has as only outcome that those who
translated in text before now have to use the web interface, I agree
that this risk being slightly count

Re: [GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

Le Fri, 12 Jan 2018 13:00:41 +0200,
Maris Nartiss  a écrit :

> 2018-01-07 23:24 GMT+02:00 Martin Landa :
> > Hi all,
> >
> > 2018-01-07 22:03 GMT+01:00 Veronica Andreo :  
> >> Just out of curiosity: Why not use transifex also for Latvian? Is
> >> there any particular reason for that?  
> >
> > I agree, to exclude LV from trasifex is not systematic approach once
> > we agreed that we will use transifex...
> >
> > Ma  
> I somehow, as a current translator of GRASS to Latvian, don't remember
> agreeing for this.
> 
> I fail to see any benefit of using web-based translation tools. Yes, I
> am familiar with Transifex and Launchpad, also with KBabel, Lokalize
> and fixing raw po files. I have been working as a coordinator of KDE
> Latvian "team" since 2005, translating QGIS and various smaller
> projects. And still I fail to see why moving to web based tool would
> be beneficial.
> 
> Translating with a web interface is just a joke. Slow and cumbersome.
> Not convenient for fast review of large amount of strings. No
> scripting abilities. No diff support. No possibility to reject
> contributions. KDE project as whole rejected all translation work done
> in Launchpad (due to extremely low quality) before Ubuntu guys dropped
> KDE from Launchpad.
> Transifex still is showing wrong labels for plural form strings for
> Latvian language. I reported it in 2015 and their answer was "change
> string order in the file". (Really?!?) Thus anyone using web interface
> will provide wrong translations for Latvian language.
> "Easier to contribute" argument is also not solved by moving to web
> platform, as it still depends on people. I got access to translate one
> project on Transifex only after it was removed from my company
> production servers as being obsolete. Yes, I submitted my translated
> po file, but the fact that we managed to translate, integrate, test,
> deploy to production and replace with different component all before
> my request to add language and assign me rights to translate was
> fulfilled speaks on its own.
> 
> QGIS moved to Transifex some time a go. Number of new contributors to
> Latvian language due to "it is easier to contribute": 0. Keep in mind
> – contrary to GRASS GIS, QGIS is widely used in Latvia, including some
> (millions € worth) governmental IT projects, thus one could expect
> large number of contributors; Recently a new issue was identified (see
> Qgis-tr Tue Jan 9 15:16:15 PST 2018) – it is hard to track
> contributors and thus list them in credits; Following multiple
> branches is still unsolved.
> 
> KDE SC (number of strings approaches 200k, comparing to GRASS shy 15k)
> is still pure po+svn workflow (with teams being free to use anything
> as they wish as long as final output is a po file commit to svn). So
> far all proposals for global migration have died out (example:
> https://marc.info/?l=kde-i18n-doc=135873075615507=2); The Summit
> approach of KDE SC is worth of exploring – so far it is the best
> solution for tracking multiple branches simultaneously. Still Summit
> plays off only for really active teams.
> 
> Finally – I fail to see any problem for skipping *_lv.po files as long
> as data exchange with Transifex is scripted (or I decide to move to
> ArcGIS). I'm not blocking others of using Transifex workflow, if it
> feels appealing for someone. Yes, that means that I'll have to do all
> pot->po merge dance for Latvian language and I'm fine with it.

I like Transifex and the idea that it potentially allows anyone to
easily to a translate a day without having to download the source code.

I do understand Maris' argument, however, and agree that Transifex'
interface does not make translation easier for someone who knows how to
handle the appropriate files. And I am sensitive to the argument that
we do not have an active translation community.

Maybe we should conduct a survey on the relevant mailing lists, but if
the whole Transifex migration has as only outcome that those who
translated in text before now have to use the web interface, I agree
that this risk being slightly counter-productive.

On the other hand, once the Transifex workflow is worked out, it would
allow us to campaign for more translaters offering them a very easy
access. I hear Maris' info about the none-existing effect on QGIS
translation, but would be interested if this is also true for other
languages.

In any case, I think we should keep things flexible and allow those
that want to to use a different workflow than the web-based interface,
at least on a language-by-language basis.

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Maris Nartiss]

2018-01-07 23:24 GMT+02:00 Martin Landa :
> Hi all,
>
> 2018-01-07 22:03 GMT+01:00 Veronica Andreo :
>> Just out of curiosity: Why not use transifex also for Latvian? Is there any
>> particular reason for that?
>
> I agree, to exclude LV from trasifex is not systematic approach once
> we agreed that we will use transifex...
>
> Ma
I somehow, as a current translator of GRASS to Latvian, don't remember
agreeing for this.

I fail to see any benefit of using web-based translation tools. Yes, I
am familiar with Transifex and Launchpad, also with KBabel, Lokalize
and fixing raw po files. I have been working as a coordinator of KDE
Latvian "team" since 2005, translating QGIS and various smaller
projects. And still I fail to see why moving to web based tool would
be beneficial.

Translating with a web interface is just a joke. Slow and cumbersome.
Not convenient for fast review of large amount of strings. No
scripting abilities. No diff support. No possibility to reject
contributions. KDE project as whole rejected all translation work done
in Launchpad (due to extremely low quality) before Ubuntu guys dropped
KDE from Launchpad.
Transifex still is showing wrong labels for plural form strings for
Latvian language. I reported it in 2015 and their answer was "change
string order in the file". (Really?!?) Thus anyone using web interface
will provide wrong translations for Latvian language.
"Easier to contribute" argument is also not solved by moving to web
platform, as it still depends on people. I got access to translate one
project on Transifex only after it was removed from my company
production servers as being obsolete. Yes, I submitted my translated
po file, but the fact that we managed to translate, integrate, test,
deploy to production and replace with different component all before
my request to add language and assign me rights to translate was
fulfilled speaks on its own.

QGIS moved to Transifex some time a go. Number of new contributors to
Latvian language due to "it is easier to contribute": 0. Keep in mind
– contrary to GRASS GIS, QGIS is widely used in Latvia, including some
(millions € worth) governmental IT projects, thus one could expect
large number of contributors; Recently a new issue was identified (see
Qgis-tr Tue Jan 9 15:16:15 PST 2018) – it is hard to track
contributors and thus list them in credits; Following multiple
branches is still unsolved.

KDE SC (number of strings approaches 200k, comparing to GRASS shy 15k)
is still pure po+svn workflow (with teams being free to use anything
as they wish as long as final output is a po file commit to svn). So
far all proposals for global migration have died out (example:
https://marc.info/?l=kde-i18n-doc=135873075615507=2); The Summit
approach of KDE SC is worth of exploring – so far it is the best
solution for tracking multiple branches simultaneously. Still Summit
plays off only for really active teams.

Finally – I fail to see any problem for skipping *_lv.po files as long
as data exchange with Transifex is scripted (or I decide to move to
ArcGIS). I'm not blocking others of using Transifex workflow, if it
feels appealing for someone. Yes, that means that I'll have to do all
pot->po merge dance for Latvian language and I'm fine with it.

I hope I clarified a bit.
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Dear all,

the new release candidate GRASS GIS 7.4.0RC2 is out!

Please double check the announcement:
https://trac.osgeo.org/grass/wiki/Release/7.4.0-News

Next we need binary packages. Once we believe that things are in order
I'd like to promote RC2 to final (hence, no more relevant changes
allowed).

thanks!
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Mon, Jan 8, 2018 at 8:21 PM, Markus Metz
 wrote:
> On Mon, Jan 8, 2018 at 7:57 PM, Markus Neteler  wrote:
...
>> Anything else left for RC2?
>
> From my side, nothing. Let's get RC2 out!

ok, procedure started :-)

markusN

-- 
Markus Neteler, PhD
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Metz]

On Mon, Jan 8, 2018 at 7:57 PM, Markus Neteler  wrote:
>
> On Mon, Jan 8, 2018 at 4:30 PM, Markus Metz
>  wrote:
> > On Mon, Jan 8, 2018 at 10:47 AM, Markus Neteler 
wrote:
> >>
> >> Hi devs,
> >>
> >> if there are no objections, I'll package 7.4.0RC2 in the next few days.
> >
> > I have just submitted a fix for i.atcorr in r72055, in the hope that it
> > still makes it into 7.4.0RC2.
>
> Yes, they are in! Thanks for the fixes.
>
> Anything else left for RC2?

>From my side, nothing. Let's get RC2 out!

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Mon, Jan 8, 2018 at 4:30 PM, Markus Metz
 wrote:
> On Mon, Jan 8, 2018 at 10:47 AM, Markus Neteler  wrote:
>>
>> Hi devs,
>>
>> if there are no objections, I'll package 7.4.0RC2 in the next few days.
>
> I have just submitted a fix for i.atcorr in r72055, in the hope that it
> still makes it into 7.4.0RC2.

Yes, they are in! Thanks for the fixes.

Anything else left for RC2?

markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Metz]

On Mon, Jan 8, 2018 at 10:47 AM, Markus Neteler  wrote:
>
> Hi devs,
>
> if there are no objections, I'll package 7.4.0RC2 in the next few days.

I have just submitted a fix for i.atcorr in r72055, in the hope that it
still makes it into 7.4.0RC2.

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Hi devs,

if there are no objections, I'll package 7.4.0RC2 in the next few days.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi all,

2018-01-07 22:03 GMT+01:00 Veronica Andreo :
> Just out of curiosity: Why not use transifex also for Latvian? Is there any
> particular reason for that?

I agree, to exclude LV from trasifex is not systematic approach once
we agreed that we will use transifex...

Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Veronica Andreo]

Hello Maris,

Just out of curiosity: Why not use transifex also for Latvian? Is there any
particular reason for that?

I do Spanish translations and I find transifex so convenient and easy to
use. Moreover all other languages are there and it is also easier, IMHO, to
collect and pull the translations from one place only.

What about this tool that Luca mentioned, tx push (
https://docs.transifex.com/client/push)  to push your translations to
transifex so we can have all translations up to date in one place only to
avoid any possible future collision? Maybe you can figure out how it works
:)

Cheers,
Vero

El 7 ene. 2018 4:04 p.m., "Markus Neteler"  escribió:

> Hello Māris
>
> On Sun, Jan 7, 2018 at 5:53 PM, Maris Nartiss  wrote:
> > 2018-01-07 9:55 GMT+02:00 Markus Neteler :
> >> Hi Māris,
> >>
> >> Thanks but the last but one language edit you did in trunk (r71617,
> >> r70824, etc) which I merged into the relbranches yesterday.
> >> But yesterday you edited relbr74 (r72041)... does this need to go into
> >> trunk and relbr72 now?
> > No, I just merged trunk to 7.4 + manually checked for any fuzzy
> > strings to ensure LV readiness for release. No need to do anything
> > from your side.
> > As 7.4.0 will be out, I don't see any need for updating 7.2.x.
>
> ok... however, all other languages are updated and 7.2 is the master
> in transifex.
> It may create collisions in the future for LV if not kept in sync.
>
> >> It would be important to declare one as Latvian master.
> >> Or, ideally, you manage completeley the Latvian translations yourself
> :-)
> >
> > Taking into account that I am the only translator and quite possibly
> > also the only user (except my students when I force them to do some
> > analysis in GRASS) of GRASS in Latvian, I'll manage translations in
> > future. Thus no need to take any action from your side any more. More
> > free time for you :-)
>
> Sounds great! Please also consider this for your source code changes in
> trunk :)
>
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Hello Māris

On Sun, Jan 7, 2018 at 5:53 PM, Maris Nartiss  wrote:
> 2018-01-07 9:55 GMT+02:00 Markus Neteler :
>> Hi Māris,
>>
>> Thanks but the last but one language edit you did in trunk (r71617,
>> r70824, etc) which I merged into the relbranches yesterday.
>> But yesterday you edited relbr74 (r72041)... does this need to go into
>> trunk and relbr72 now?
> No, I just merged trunk to 7.4 + manually checked for any fuzzy
> strings to ensure LV readiness for release. No need to do anything
> from your side.
> As 7.4.0 will be out, I don't see any need for updating 7.2.x.

ok... however, all other languages are updated and 7.2 is the master
in transifex.
It may create collisions in the future for LV if not kept in sync.

>> It would be important to declare one as Latvian master.
>> Or, ideally, you manage completeley the Latvian translations yourself :-)
>
> Taking into account that I am the only translator and quite possibly
> also the only user (except my students when I force them to do some
> analysis in GRASS) of GRASS in Latvian, I'll manage translations in
> future. Thus no need to take any action from your side any more. More
> free time for you :-)

Sounds great! Please also consider this for your source code changes in trunk :)

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Maris Nartiss]

Hello Markus,

2018-01-07 9:55 GMT+02:00 Markus Neteler :
> Hi Māris,
>
> Thanks but the last but one language edit you did in trunk (r71617,
> r70824, etc) which I merged into the relbranches yesterday.
> But yesterday you edited relbr74 (r72041)... does this need to go into
> trunk and relbr72 now?
No, I just merged trunk to 7.4 + manually checked for any fuzzy
strings to ensure LV readiness for release. No need to do anything
from your side.
As 7.4.0 will be out, I don't see any need for updating 7.2.x.

> It would be important to declare one as Latvian master.
> Or, ideally, you manage completeley the Latvian translations yourself :-)
Taking into account that I am the only translator and quite possibly
also the only user (except my students when I force them to do some
analysis in GRASS) of GRASS in Latvian, I'll manage translations in
future. Thus no need to take any action from your side any more. More
free time for you :-)

>> I compiled 7.4 and started GUI – looks fine for me :)
>
> Good!
>
> Markus

Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Hi Māris,

On Sat, Jan 6, 2018 at 7:35 PM, Maris Nartiss  wrote:
> Hello Markus,
> I updated the grass-addons/tools/transifex_merge.sh script to skip lv
> files. Thus no further action is needed from you in case if you merge
> translations from Tx to release branch/trunk.

Thanks but the last but one language edit you did in trunk (r71617,
r70824, etc) which I merged into the relbranches yesterday.
But yesterday you edited relbr74 (r72041)... does this need to go into
trunk and relbr72 now?

It would be important to declare one as Latvian master.
Or, ideally, you manage completeley the Latvian translations yourself :-)

> I compiled 7.4 and started GUI – looks fine for me :)

Good!

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Maris Nartiss]

Hello Markus,
I updated the grass-addons/tools/transifex_merge.sh script to skip lv
files. Thus no further action is needed from you in case if you merge
translations from Tx to release branch/trunk.

I compiled 7.4 and started GUI – looks fine for me :)

Māris.


2018-01-06 15:00 GMT+02:00 Markus Neteler :
> Hi,
>
> I have now
> - updated 7.5 (trunk) from Transifex except for Latvian and fixed some
> errors in the .po files, submitted;
> - updated 7.4 from Transifex except for Latvian; merged Latvian from
> trunk; fixed some errors in the .po files, submitted;
> - updated 7.2 from Transifex except for Latvian; merged Latvian from
> trunk; fixed some errors in the .po files, submitted;
>
> Procedure:
> For merging,
> - trunk: I used grass-addons/tools/transifex_merge.sh, then reverted
> the Latvian changes
> - rel branches: I used grass-addons/tools/transifex_merge.sh, then
> merged the Latvian changes from trunk using msgmerge -N
>
> Hope I got it right. Please test.
>
> Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Hi,

I have now
- updated 7.5 (trunk) from Transifex except for Latvian and fixed some
errors in the .po files, submitted;
- updated 7.4 from Transifex except for Latvian; merged Latvian from
trunk; fixed some errors in the .po files, submitted;
- updated 7.2 from Transifex except for Latvian; merged Latvian from
trunk; fixed some errors in the .po files, submitted;

Procedure:
For merging,
- trunk: I used grass-addons/tools/transifex_merge.sh, then reverted
the Latvian changes
- rel branches: I used grass-addons/tools/transifex_merge.sh, then
merged the Latvian changes from trunk using msgmerge -N

Hope I got it right. Please test.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Maris Nartiss]

2018-01-02 23:33 GMT+02:00 Markus Neteler :
> Hi,
>
> ... isn't that basically re rewrite of the script? At time is uses msgmerge.
> Maris, why must .po files be replaced rather than using msgmerge?
Hello,
I might not see whole picture of workflow clearly. My points:
* if whole translation is performed in Transifex, then (after initial
import to Tx) SVN PO file has 0 value as all changes should be
performed in Transifex;
* if msgmerge is used (although as it can be seen from the previous
point, it's useless), -N (no fuzzy matching) should be used to not
generate fuzzy matches as translation flow will be from Tx to SVN and
not backwards thus fuzzy PO file can not be fixed (in a normal
workflow).

Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Hi,

On Thu, Dec 21, 2017 at 1:11 PM, Luca Delucchi  wrote:
> On 21 December 2017 at 10:24, Maris Nartiss  wrote:
>> If I understood correctly, the proposed workflow is to switch
>> Transifex to 7.4 branch and keep it there till 7.6 branch is created.
>> Sounds OK.
>>
>
> +1

At time there is G72 listed.
https://www.transifex.com/grass-gis/public/

How to change it to 7.4 branch there without making a mess?
Luca, do you know?

>> Here is a quick list of TODOs:
>> * provide a script to run before each stable release that pulls
>> translated messages from Transifex and replaces(!) PO files in SVN. It
>> is important to replace existing PO files with Tx version to prevent
>> generation of fuzzy entries in the final PO file;
>
> this could be done with un update to grass-addons/tools/transifex_merge.sh

... isn't that basically re rewrite of the script? At time is uses msgmerge.
Maris, why must .po files be replaced rather than using msgmerge?

>> * update documentation:
>> ** How to release;
>> ** locale/README;
>> ** Wiki & web page;
>> * document how switching between branches should be done.
>>
>> As for any team willing to translate only in SVN (that's me) – only
>> the pulling script will have to be modified to exclude language while
>> pulling translations from Transifex. That's really easy and I'll do
>> that as soon as the script is in place.
>
> ok, this should work, another way could be to use transifex client to
> push the new data in transifex, this is also required for changes like
> the one done by markus neteler [0]
>
> I tried with tx push [1], but this sucks, I asked to transifex support...

What is the state here?
We really need to get 7.4.0RC2 done.

thanks
Markus


>>
>> Māris.
>>
>
> [0] 
> https://trac.osgeo.org/grass/changeset?reponame==71766%40grass%2Fbranches%2Freleasebranch_7_2%2Flocale%2Fpo%2Fgrasswxpy_fr.po=71470%40grass%2Fbranches%2Freleasebranch_7_2%2Flocale%2Fpo%2Fgrasswxpy_fr.po
> [1] https://docs.transifex.com/client/push
>
> --
> ciao
> Luca
>
> www.lucadelu.org



-- 
Markus Neteler, PhD
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Am 25.12.2017 11:07 nachm. schrieb "Martin Landa" :

Hi,

2017-12-17 22:46 GMT+01:00 Markus Neteler :
> I'd like to get RC2 out.
> Any objections?

no objections, please go ahead. Ma


We still lack the solution for managing the translations... At least one
sync.

Markus


--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2017-12-17 22:46 GMT+01:00 Markus Neteler :
> I'd like to get RC2 out.
> Any objections?

no objections, please go ahead. Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Luca Delucchi]

On 21 December 2017 at 10:24, Maris Nartiss  wrote:
> If I understood correctly, the proposed workflow is to switch
> Transifex to 7.4 branch and keep it there till 7.6 branch is created.
> Sounds OK.
>

+1

> Here is a quick list of TODOs:
> * provide a script to run before each stable release that pulls
> translated messages from Transifex and replaces(!) PO files in SVN. It
> is important to replace existing PO files with Tx version to prevent
> generation of fuzzy entries in the final PO file;

this could be done with un update to grass-addons/tools/transifex_merge.sh

> * update documentation:
> ** How to release;
> ** locale/README;
> ** Wiki & web page;
> * document how switching between branches should be done.
>
> As for any team willing to translate only in SVN (that's me) – only
> the pulling script will have to be modified to exclude language while
> pulling translations from Transifex. That's really easy and I'll do
> that as soon as the script is in place.

ok, this should work, another way could be to use transifex client to
push the new data in transifex, this is also required for changes like
the one done by markus neteler [0]

I tried with tx push [1], but this sucks, I asked to transifex support...

>
> Māris.
>

[0] 
https://trac.osgeo.org/grass/changeset?reponame==71766%40grass%2Fbranches%2Freleasebranch_7_2%2Flocale%2Fpo%2Fgrasswxpy_fr.po=71470%40grass%2Fbranches%2Freleasebranch_7_2%2Flocale%2Fpo%2Fgrasswxpy_fr.po
[1] https://docs.transifex.com/client/push

-- 
ciao
Luca

www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Maris Nartiss]

If I understood correctly, the proposed workflow is to switch
Transifex to 7.4 branch and keep it there till 7.6 branch is created.
Sounds OK.

Here is a quick list of TODOs:
* provide a script to run before each stable release that pulls
translated messages from Transifex and replaces(!) PO files in SVN. It
is important to replace existing PO files with Tx version to prevent
generation of fuzzy entries in the final PO file;
* update documentation:
** How to release;
** locale/README;
** Wiki & web page;
* document how switching between branches should be done.

As for any team willing to translate only in SVN (that's me) – only
the pulling script will have to be modified to exclude language while
pulling translations from Transifex. That's really easy and I'll do
that as soon as the script is in place.

Māris.


2017-12-20 22:13 GMT+02:00 Markus Neteler :
> On Wed, Dec 20, 2017 at 5:31 PM, Moritz Lennert
>  wrote:
> ...
>> I agree that we do not have to guarantee that the development version is
>> translated. IMHO, priority for translation should go to the stable,
>
> +1
>
>> or soon-to-be version which would mean that as soon as we create a release
>> branch, translations should be maintained for this release branch as long as
>> it is supported,
>
> +1
>
>> but any old release branch should be in strict bug-fix only
>> mode as soon as a new release is out, so message strings should not change
>> much.
>>
>> Does that sound feasible ?
>
> This is what I also think. Yet the workflow isn't fully implemented
> yet. And Maris will appreciate to not lose his translations (how to do
> that?)...
>
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Wed, Dec 20, 2017 at 5:31 PM, Moritz Lennert
 wrote:
...
> I agree that we do not have to guarantee that the development version is
> translated. IMHO, priority for translation should go to the stable,

+1

> or soon-to-be version which would mean that as soon as we create a release
> branch, translations should be maintained for this release branch as long as
> it is supported,

+1

> but any old release branch should be in strict bug-fix only
> mode as soon as a new release is out, so message strings should not change
> much.
>
> Does that sound feasible ?

This is what I also think. Yet the workflow isn't fully implemented
yet. And Maris will appreciate to not lose his translations (how to do
that?)...

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

On 20/12/17 14:51, Luca Delucchi wrote:

On 20 December 2017 at 13:35, Moritz Lennert
 wrote:


Sorry, if I'm a bit dense here: when you change the text of a message in
trunk, then if transifex only covers trunk then you only get the translation
of the trunk version, or ? How does this "cover all the different versions"
?


ok I understood, so we have to choose between:
- choose one version to use, probably the best idea is to use the last
stable version
- create a project for each version (but I don't know if we are able
to get translations from previous)
- if we use trunk we have to backport text changes to stable version


I agree that we do not have to guarantee that the development version is 
translated. IMHO, priority for translation should go to the stable, or 
soon-to-be version which would mean that as soon as we create a release 
branch, translations should be maintained for this release branch as 
long as it is supported, but any old release branch should be in strict 
bug-fix only mode as soon as a new release is out, so message strings 
should not change much.


Does that sound feasible ?

Moritz


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Luca Delucchi]

On 20 December 2017 at 13:35, Moritz Lennert
 wrote:
>
> Sorry, if I'm a bit dense here: when you change the text of a message in
> trunk, then if transifex only covers trunk then you only get the translation
> of the trunk version, or ? How does this "cover all the different versions"
> ?

ok I understood, so we have to choose between:
- choose one version to use, probably the best idea is to use the last
stable version
- create a project for each version (but I don't know if we are able
to get translations from previous)
- if we use trunk we have to backport text changes to stable version

>
> Moritz



-- 
ciao
Luca

www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

On 20/12/17 13:27, Luca Delucchi wrote:

On 20 December 2017 at 13:11, Moritz Lennert
 wrote:



But source text might be different between versions, or ?



yes it is different but trunk should cover all the different version,
msgmerge should get the right text


Sorry, if I'm a bit dense here: when you change the text of a message in 
trunk, then if transifex only covers trunk then you only get the 
translation of the trunk version, or ? How does this "cover all the 
different versions" ?


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Luca Delucchi]

On 20 December 2017 at 13:11, Moritz Lennert
 wrote:
>
>
> But source text might be different between versions, or ?
>

yes it is different but trunk should cover all the different version,
msgmerge should get the right text

> Moritz
>

-- 
ciao
Luca

www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

On 20/12/17 10:58, Luca Delucchi wrote:

On 20 December 2017 at 10:27, Moritz Lennert
 wrote:



What about trunk ?



I think we should use trunk and after merge the po file to all grass 7
version, if I remember correctly msgmerge should be able to merge the
right one.
We have to change the source, I discovered 7.4 exists

https://grass.osgeo.org/grass74/binary/linux/snapshot/transifex/

I think we should have only one translation project i suggest to
change grass72 to grass
https://www.transifex.com/grass-gis/grass72/ ->
https://www.transifex.com/grass-gis/grass/

and use or the last stable version of po file or trunk one.


But source text might be different between versions, or ?

Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Veronica Andreo]

Hi,

2017-12-20 10:58 GMT+01:00 Luca Delucchi :

> On 20 December 2017 at 10:27, Moritz Lennert
>  wrote:
>
> >
> > What about trunk ?
> >
>
> I think we should use trunk and after merge the po file to all grass 7
> version, if I remember correctly msgmerge should be able to merge the
> right one.
> We have to change the source, I discovered 7.4 exists
>
> https://grass.osgeo.org/grass74/binary/linux/snapshot/transifex/
>
> I think we should have only one translation project i suggest to
> change grass72 to grass
> https://www.transifex.com/grass-gis/grass72/ ->
> https://www.transifex.com/grass-gis/grass/
>
> and use or the last stable version of po file or trunk one


+1 for trunk and then merge the translations to other branches

Vero
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Luca Delucchi]

On 20 December 2017 at 10:27, Moritz Lennert
 wrote:

>
> What about trunk ?
>

I think we should use trunk and after merge the po file to all grass 7
version, if I remember correctly msgmerge should be able to merge the
right one.
We have to change the source, I discovered 7.4 exists

https://grass.osgeo.org/grass74/binary/linux/snapshot/transifex/

I think we should have only one translation project i suggest to
change grass72 to grass
https://www.transifex.com/grass-gis/grass72/ ->
https://www.transifex.com/grass-gis/grass/

and use or the last stable version of po file or trunk one.


>
> Moritz



-- 
ciao
Luca

www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

On 20/12/17 00:14, Luca Delucchi wrote:

On 19 December 2017 at 22:31, Markus Neteler  wrote:



To find out:

- how message changes in the source code are uploaded to transifex



https://grass.osgeo.org/grass72/binary/linux/snapshot/transifex/


What about trunk ?


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Luca Delucchi]

On 19 December 2017 at 22:31, Markus Neteler  wrote:

>
> To find out:
>
> - how message changes in the source code are uploaded to transifex
>

https://grass.osgeo.org/grass72/binary/linux/snapshot/transifex/

> - how translated messages get back into
>- trunk
>- the release branch
>

the script grass-addons/tools/transifex_merge.sh should do this

> - how translation updates done in SVN in the .po files get into transifex or
> if that's lost
>

probably they are lost, I think we should use only transifex for translation

> Thanks
> Markus



-- 
ciao
Luca

www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Dec 19, 2017 5:21 PM, "Luca Delucchi"  wrote:
>
> On 17 December 2017 at 22:46, Markus Neteler  wrote:
> >
> > Current TODOs:
> > - sync with transifex. Better: really understand how it works. Someone
> > must have set it up :)
>
> what is needed for this?

To find out:

- how message changes in the source code are uploaded to transifex

- how translated messages get back into
   - trunk
   - the release branch

- how translation updates done in SVN in the .po files get into transifex
or if that's lost

Thanks
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Luca Delucchi]

On 17 December 2017 at 22:46, Markus Neteler  wrote:
> Hi,
>

Hi,

>
> Current TODOs:
> - sync with transifex. Better: really understand how it works. Someone
> must have set it up :)

what is needed for this?

>
> Markus
>


-- 
ciao
Luca

www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Hi,

I'd like to get RC2 out.
Any objections?

Current TODOs:
- sync with transifex. Better: really understand how it works. Someone
must have set it up :)
- improve the i.ortho.* tools docs
- see https://trac.osgeo.org/grass/wiki/Grass7Planning#a7.4.0

Markus


PS: Please (all) fill in:
https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures74
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Stefan Blumentrath]

Zofie did use the tools in trunk. So, she can tell details.
What I understood is that all works well now, with proper GCPs. However, the 
algorithm seems to be very (very) sensitive to poorly placed GCPs. A single GCP 
can cause severely misplaced results. No idea if it is possible to do something 
about that...
@Zofie, please elaborate if I missed important details or misunderstood...

Cheers
Stefan

-Original Message-
From: neteler.os...@gmail.com [mailto:neteler.os...@gmail.com] On Behalf Of 
Markus Neteler
Sent: fredag 24. november 2017 16.01
To: Martin Landa <landa.mar...@gmail.com>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>; Žofie Cimburová 
<zoficimbur...@gmail.com>; Stefan Blumentrath <stefan.blumentr...@nina.no>
Subject: Re: [GRASS-dev] [release planning] 7.4.0

(cc Žofie, Stefan)

On Tue, Nov 21, 2017 at 11:08 AM, Martin Landa <landa.mar...@gmail.com> wrote:
> Hi,
>
> 2017-11-21 9:31 GMT+01:00 Moritz Lennert <mlenn...@club.worldonline.be>:
>> AFAICT, the man page of g.gui.image2target is strictly identical to 
>> that of g.gui.gcp. Has this not been updated, yet ?
>
> there is probably some code duplication between g.gui.gcp and 
> g.gui.image2target. Does anyone tested the new GUI tools? Ma

Žofie, Stefan: did you use these tools in your i.ortho.photo experiments?

thanks,
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

(cc Žofie, Stefan)

On Tue, Nov 21, 2017 at 11:08 AM, Martin Landa  wrote:
> Hi,
>
> 2017-11-21 9:31 GMT+01:00 Moritz Lennert :
>> AFAICT, the man page of g.gui.image2target is strictly identical to that of
>> g.gui.gcp. Has this not been updated, yet ?
>
> there is probably some code duplication between g.gui.gcp and
> g.gui.image2target. Does anyone tested the new GUI tools? Ma

Žofie, Stefan: did you use these tools in your i.ortho.photo experiments?

thanks,
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2017-11-21 9:31 GMT+01:00 Moritz Lennert :
> AFAICT, the man page of g.gui.image2target is strictly identical to that of
> g.gui.gcp. Has this not been updated, yet ?

there is probably some code duplication between g.gui.gcp and
g.gui.image2target. Does anyone tested the new GUI tools? Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

On 18/11/17 21:40, Markus Neteler wrote:

On Fri, Nov 17, 2017 at 11:13 AM, Martin Landa  wrote:

Hi,

2017-11-17 8:53 GMT+01:00 Veronica Andreo :

TODO:  <<-- support needed!
https://trac.osgeo.org/grass/wiki/Grass7Planning#a7.4.0
  * i.ortho.photo: update documentation


... Vero just updated the docs based on the work of Zofie.



AFAICT, the man page of g.gui.image2target is strictly identical to that 
of g.gui.gcp. Has this not been updated, yet ?


diff -u g.gui.gcp.html ../image2target/g.gui.image2target.html
--- g.gui.gcp.html  2017-09-08 13:50:29.530320437 +0200
+++ ../image2target/g.gui.image2target.html	2017-11-13 
09:17:52.299348925 +0100

@@ -315,4 +315,4 @@
 Martin Landa, Czech Technical University in Prague, Czech Republic

 
-$Date: 2016-09-19 11:37:30 +0200 (lun 19 sep 2016) $
+$Date: 2017-11-03 18:21:39 +0100 (ven 03 nov 2017) $
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Maris Nartiss]

2017-11-20 15:03 GMT+02:00 Moritz Lennert :
> Thanks a lot, Maris !
>
> I think you can backport, so that it gets as much testing as possible
> in the 7.4 release branch before release.
Done in r71788

> Moritz
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

Le Sun, 19 Nov 2017 01:41:06 +0200,
Maris Nartiss  a écrit :

> 2017-11-12 19:50 GMT+02:00 Moritz Lennert
> :
> > MarkusM is the one who really knows, but AFAIU, the GEOS
> > implementation of buffering is the best we have (or the only one
> > without errors in specific cases). There is not function for
> > creating parallel lines in GEOS, so for that the functions in
> > buffer2.c are the best we have, but they are pretty bad.
> > Apparently, creating a parallel line is not as simple as it would
> > sound, and we are still looking for a correct implementation, or
> > rather to even see if such an implementation is possible.  
> I played around with native buffering (both versions) and they both
> look similarly bad :(
> Thus I made v.profile to hard depend on GEOS buffers (no native
> option) till we manage to fix problems with native buffering.
> Please test if trunk seems to be OK now (I added also a test case
> based on your example).
> r71769 will need a backport if there will be no objections

Thanks a lot, Maris !

I think you can backport, so that it gets as much testing as possible
in the 7.4 release branch before release.

Moritz 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Maris Nartiss]

2017-11-12 19:50 GMT+02:00 Moritz Lennert :
> MarkusM is the one who really knows, but AFAIU, the GEOS implementation
> of buffering is the best we have (or the only one without errors in
> specific cases). There is not function for creating parallel lines in
> GEOS, so for that the functions in buffer2.c are the best we have, but
> they are pretty bad. Apparently, creating a parallel line is not as
> simple as it would sound, and we are still looking for a correct
> implementation, or rather to even see if such an implementation is
> possible.
I played around with native buffering (both versions) and they both
look similarly bad :(
Thus I made v.profile to hard depend on GEOS buffers (no native
option) till we manage to fix problems with native buffering.
Please test if trunk seems to be OK now (I added also a test case
based on your example).
r71769 will need a backport if there will be no objections.

> Moritz
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Fri, Nov 17, 2017 at 11:13 AM, Martin Landa  wrote:
> Hi,
>
> 2017-11-17 8:53 GMT+01:00 Veronica Andreo :
>>> TODO:  <<-- support needed!
>>> https://trac.osgeo.org/grass/wiki/Grass7Planning#a7.4.0
>>>  * i.ortho.photo: update documentation

... Vero just updated the docs based on the work of Zofie.

> btw, in which shape are related GUI (image2target) tools? Do we want
> to ship them in 7.4.0? And are there any other tools which should be
> probably removed from upcoming release?

You mean to remove
g.gui.image2target
? Doesn't it work?

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2017-11-17 8:53 GMT+01:00 Veronica Andreo :
>> TODO:  <<-- support needed!
>> https://trac.osgeo.org/grass/wiki/Grass7Planning#a7.4.0
>>  * i.ortho.photo: update documentation

btw, in which shape are related GUI (image2target) tools? Do we want
to ship them in 7.4.0? And are there any other tools which should be
probably removed from upcoming release?

Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Veronica Andreo]

Hi,

2017-11-17 8:09 GMT+01:00 Markus Neteler :

> Hi,
>
> now GRASS 7.4.0 RC1 is tagged. Please test:
>
> https://grass.osgeo.org/grass74/source/
>
> and continue to update the release docs at:
>
> - https://trac.osgeo.org/grass/wiki/Release/7.4.0-News
> - https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures74
>   (more screenshots wanted!)
>

two of the Google Code-In tasks we are proposing are precisely these :) (I
hope we can collect some screenshots)

TODO:  <<-- support needed!
> https://trac.osgeo.org/grass/wiki/Grass7Planning#a7.4.0
>  * i.ortho.photo: update documentation
>

Zofie is doing that. Yesterday she sent me the html and pics, but I asked
to include figs as in [0]. I guess she'll send it back soon, so we can
update it. I'm on it.

cheers,
Vero

[0] https://trac.osgeo.org/grass/wiki/Submitting/Docs#Images
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Hi,

now GRASS 7.4.0 RC1 is tagged. Please test:

https://grass.osgeo.org/grass74/source/

and continue to update the release docs at:

- https://trac.osgeo.org/grass/wiki/Release/7.4.0-News
- https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures74
  (more screenshots wanted!)

TODO:  <<-- support needed!
https://trac.osgeo.org/grass/wiki/Grass7Planning#a7.4.0
 * i.ortho.photo: update documentation
 * Transifex sync

best,
markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2017-11-15 10:39 GMT+01:00 Helmut Kudrnovsky :
> Will this be propagated to OSGeo4W?

yes, now done, see [1,2]. Please test. Ma

[1] 
http://download.osgeo.org/osgeo4w/x86_64/release/grass/grass-daily/setup.hint
[2] http://download.osgeo.org/osgeo4w/x86/release/grass/grass-daily/setup.hint

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Metz]

On Thu, Nov 16, 2017 at 9:57 PM, Markus Neteler  wrote:
>
> On Thu, Nov 16, 2017 at 9:28 AM, Markus Metz
>  wrote:>
> > On Tue, Nov 14, 2017 at 10:24 PM, Martin Landa 
> >> 2017-11-13 8:23 GMT+01:00 Martin Landa :
> >> > please wait also for Windows daily binaries. It will take some time
to
> >> > set it up too. Ma
> >>
> >> wingrass builds consolidated:
> >>
> >> * no daily builds for G70, only addons for last version 7.0.5
> >> * daily builds for G72 still kept, addons compiled for all G72X
versions
> >> * new daily builds of G74 including addons
> >> * new daily builds of G75 including addons
> >>
> >> Enjoy, https://wingrass.fsv.cvut.cz/
> >
> > Latest wingrass x86 (r71735) is broken, failing in r.in.gdal.
> > Latest wingrass x86_64 (r71738) is fine.
> >
> > Once wingrass x86 has been updated to at least r71738, it should work
again.
>
> So I wait for that with RC1?

This, i.e. the broken wingrass x86, applies only to trunk. Once the patch
is confirmed working (which will take some time considering that the
WinGRASS server is currently down) I want to backport the patch to 7.4. The
planned patch is a minor patch compared to all the new features in 7.4.
Therefore 7.4 RC1 can be released right now.

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Thu, Nov 16, 2017 at 9:28 AM, Markus Metz
 wrote:>
> On Tue, Nov 14, 2017 at 10:24 PM, Martin Landa 
>> 2017-11-13 8:23 GMT+01:00 Martin Landa :
>> > please wait also for Windows daily binaries. It will take some time to
>> > set it up too. Ma
>>
>> wingrass builds consolidated:
>>
>> * no daily builds for G70, only addons for last version 7.0.5
>> * daily builds for G72 still kept, addons compiled for all G72X versions
>> * new daily builds of G74 including addons
>> * new daily builds of G75 including addons
>>
>> Enjoy, https://wingrass.fsv.cvut.cz/
>
> Latest wingrass x86 (r71735) is broken, failing in r.in.gdal.
> Latest wingrass x86_64 (r71738) is fine.
>
> Once wingrass x86 has been updated to at least r71738, it should work again.

So I wait for that with RC1?

markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Metz]

On Tue, Nov 14, 2017 at 10:24 PM, Martin Landa 
wrote:
>
> Hi,
>
> 2017-11-13 8:23 GMT+01:00 Martin Landa :
> > please wait also for Windows daily binaries. It will take some time to
> > set it up too. Ma
>
> wingrass builds consolidated:
>
> * no daily builds for G70, only addons for last version 7.0.5
> * daily builds for G72 still kept, addons compiled for all G72X versions
> * new daily builds of G74 including addons
> * new daily builds of G75 including addons
>
> Enjoy, https://wingrass.fsv.cvut.cz/

Latest wingrass x86 (r71735) is broken, failing in r.in.gdal.
Latest wingrass x86_64 (r71738) is fine.

Once wingrass x86 has been updated to at least r71738, it should work again.

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2017-11-15 11:53 GMT+01:00 Moritz Lennert :
> Martin, have you had a chance to look at #3429 [1] ? Would be nice to have
> this solved before the final release.

not yet, I will try to find time (for final release there are few weeks ;-) Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

On 15/11/17 11:17, Markus Neteler wrote:

Hi,

I'd like to get RC1 out.
Any objections yet?


None from me.

Martin, have you had a chance to look at #3429 [1] ? Would be nice to 
have this solved before the final release.


Moritz

[1] https://trac.osgeo.org/grass/ticket/3429


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Hi,

I'd like to get RC1 out.
Any objections yet?

Yet a to do: sync with transifex.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Helmut Kudrnovsky]

Martin Landa wrote
> Hi,
> 
> 2017-11-13 8:23 GMT+01:00 Martin Landa 

> landa.martin@

> :
>> please wait also for Windows daily binaries. It will take some time to
>> set it up too. Ma
> 
> wingrass builds consolidated:
> 
> * no daily builds for G70, only addons for last version 7.0.5
> * daily builds for G72 still kept, addons compiled for all G72X versions
> * new daily builds of G74 including addons
> * new daily builds of G75 including addons
> 
> Enjoy, https://wingrass.fsv.cvut.cz/
> 
> Ma
> 
> -- 
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> grass-dev mailing list

> grass-dev@.osgeo

> https://lists.osgeo.org/mailman/listinfo/grass-dev

Thanks for updating the building.

Will this be propagated to OSGeo4W?



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2017-11-13 8:23 GMT+01:00 Martin Landa :
> please wait also for Windows daily binaries. It will take some time to
> set it up too. Ma

wingrass builds consolidated:

* no daily builds for G70, only addons for last version 7.0.5
* daily builds for G72 still kept, addons compiled for all G72X versions
* new daily builds of G74 including addons
* new daily builds of G75 including addons

Enjoy, https://wingrass.fsv.cvut.cz/

Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2017-11-12 23:31 GMT+01:00 Markus Neteler :
> I'd postpone RC1 to tomorrow since I am still setting up things on
> grass.osgeo.org (cronjobs etc).

please wait also for Windows daily binaries. It will take some time to
set it up too. Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Sun, Nov 12, 2017 at 11:31 PM, Markus Neteler  wrote:
> On Sat, Nov 11, 2017 at 10:08 PM, Markus Neteler  wrote:
> I'd postpone RC1 to tomorrow since I am still setting up things on
> grass.osgeo.org (cronjobs etc).
>
> The source tarball snapshot is meanwhile ready:
> https://grass.osgeo.org/grass74/source/snapshot/

also ready now:
https://grass.osgeo.org/grass74/manuals/

markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Sat, Nov 11, 2017 at 10:08 PM, Markus Neteler  wrote:
> On Nov 11, 2017 9:03 PM, "Martin Landa"  wrote:
>>
>> Hi,
>>
>> 2017-11-11 20:12 GMT+01:00 Markus Neteler :
>> > we got quite some stuff done today at the sprint and if there are no
>> > objections we'll prepare the release 1 by tomorrow.
>>
>> cool, but what do you mean by release 1, RC1, beta1?
>
> RC1!
>
>> And what about creating a new branch?
>
> Sure, that I'll do tomorrow or later tonight.

I'd postpone RC1 to tomorrow since I am still setting up things on
grass.osgeo.org (cronjobs etc).

The source tarball snapshot is meanwhile ready:
https://grass.osgeo.org/grass74/source/snapshot/

Working on Linux weekly binaries.

cheers,
markusN

PS: Hint: to easily get a GRASS GIS 7.4.svn local source code copy:
Take a clean (--> make distclean) relbranch72 directory, then you can
create a copy of it and
svn switch https://svn.osgeo.org/grass/grass/branches/releasebranch_7_4

... to avoid huge downloads.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

Le Sun, 12 Nov 2017 19:36:36 +0200,
Maris Nartiss  a écrit :

> 2017-11-12 14:27 GMT+02:00 Moritz Lennert
> :
> > Another, intermediate option would be to use the functions in
> > buffer2.c, i.e. Vect_line_buffer2, which is what is used in
> > v.buffer if GEOS is not available. It has a slightly different API,
> > with some new outputs (holes), but shouldn't be too difficult to
> > use in v.profile.
> >
> > Do you think you have the time to work on v.profile these days ?  
> I spent some hours trying to understand how buffering works. It
> doesn't look good at the moment:
> #3439 #3438 and r71704
> 
> What is the current road map for buffering? Making GEOS a hard option?
> Fixing native version? Or should I try to mimic v.buffer and have both
> for 7.4.0 release (#3438 and #3439 doesn't affect v.profle use case)?

MarkusM is the one who really knows, but AFAIU, the GEOS implementation
of buffering is the best we have (or the only one without errors in
specific cases). There is not function for creating parallel lines in
GEOS, so for that the functions in buffer2.c are the best we have, but
they are pretty bad. Apparently, creating a parallel line is not as
simple as it would sound, and we are still looking for a correct
implementation, or rather to even see if such an implementation is
possible.

I would think that most GRASS installations today come with GEOS, but I
have no actual data on that. So, to be safe, the best would probably be
to mimic v.buffer.

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Maris Nartiss]

2017-11-12 14:27 GMT+02:00 Moritz Lennert :
> Another, intermediate option would be to use the functions in
> buffer2.c, i.e. Vect_line_buffer2, which is what is used in v.buffer if
> GEOS is not available. It has a slightly different API, with some new
> outputs (holes), but shouldn't be too difficult to use in v.profile.
>
> Do you think you have the time to work on v.profile these days ?
I spent some hours trying to understand how buffering works. It
doesn't look good at the moment:
#3439 #3438 and r71704

What is the current road map for buffering? Making GEOS a hard option?
Fixing native version? Or should I try to mimic v.buffer and have both
for 7.4.0 release (#3438 and #3439 doesn't affect v.profle use case)?

> Moritz
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

Le Sat, 11 Nov 2017 11:28:46 +0200,
Maris Nartiss  a écrit :

> 2017-11-10 19:39 GMT+02:00 Moritz Lennert
> :
> > Hi Maris,
> >
> > v.profile still uses the old buffering library methods which has
> > quite a lot of issues.  
> 
> The best question then is why we are still shipping library methods
> that are *known* to be broken? If they are so broke, they must be
> changed to fail all the time to prevent end-users from getting wrong
> results.

Agreed. We are now busy deprecating buffer.c completely. Sorry that you
got bit by it, but v.profile has been around for so long...

> 
> > As an example, I attach the output map of the following example:
> >
> > v.profile input=geonames_NC@PERMANENT output=- separator=comma dp=3
> > buffer=500 profile_map=roadsmajor@PERMANENT profile_where=cat=193
> > map_output=test_profile
> >
> > I also attach the equivalent v.buffer output:
> >
> > v.buffer -c roadsmajor where=cat=193 dist=500 out=buff500
> >
> > Would it be possible for you, Maris, to change to the GEOS method
> > used in v.buffer in order to get the same buffering output ?  
> 
> I can take a look at v.buffer to see how GEOS is used. Still I don't
> know how soon I'll have time for it :(

Another, intermediate option would be to use the functions in
buffer2.c, i.e. Vect_line_buffer2, which is what is used in v.buffer if
GEOS is not available. It has a slightly different API, with some new
outputs (holes), but shouldn't be too difficult to use in v.profile.

> I see. I would +1 for setting current GRASS buffer functions to call
> G_fatal_error till they get fixed or replaced by GEOS version. 

v.profile is the only module that still uses Vect_line_buffer. Some
modules are using Vect_line_parallel and we are busy rewriting them to
use Vect_line_parallel2.

>I also
> would +1 to block 7.4.0 release till a final action is made (fatal
> error or a fix). Quality (correctness) should be our priority.

+1

Do you think you have the time to work on v.profile these days ?

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2017-11-11 22:08 GMT+01:00 Markus Neteler :

>> cool, but what do you mean by release 1, RC1, beta1?
>
> RC1!
>
>> And what about creating a new branch?
>
> Sure, that I'll do tomorrow or later tonight.

OK, sounds reasonable. Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Nov 11, 2017 9:03 PM, "Martin Landa"  wrote:
>
> Hi,
>
> 2017-11-11 20:12 GMT+01:00 Markus Neteler :
> > we got quite some stuff done today at the sprint and if there are no
> > objections we'll prepare the release 1 by tomorrow.
>
> cool, but what do you mean by release 1, RC1, beta1?

RC1!

> And what about creating a new branch?

Sure, that I'll do tomorrow or later tonight.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2017-11-11 20:12 GMT+01:00 Markus Neteler :
> we got quite some stuff done today at the sprint and if there are no
> objections we'll prepare the release 1 by tomorrow.

cool, but what do you mean by release 1, RC1, beta1?

And what about creating a new branch?

Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Hi,

we got quite some stuff done today at the sprint and if there are no
objections we'll prepare the release 1 by tomorrow.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Maris Nartiss]

2017-11-10 19:39 GMT+02:00 Moritz Lennert :
> Hi Maris,
>
> v.profile still uses the old buffering library methods which has quite
> a lot of issues.

The best question then is why we are still shipping library methods
that are *known* to be broken? If they are so broke, they must be
changed to fail all the time to prevent end-users from getting wrong
results.

> As an example, I attach the output map of the following example:
>
> v.profile input=geonames_NC@PERMANENT output=- separator=comma dp=3
> buffer=500 profile_map=roadsmajor@PERMANENT profile_where=cat=193
> map_output=test_profile
>
> I also attach the equivalent v.buffer output:
>
> v.buffer -c roadsmajor where=cat=193 dist=500 out=buff500
>
> Would it be possible for you, Maris, to change to the GEOS method used
> in v.buffer in order to get the same buffering output ?

I can take a look at v.buffer to see how GEOS is used. Still I don't
know how soon I'll have time for it :(

> This is not only formal as you can see when you use the following
> vector points as input:
>
> v.in.ascii in=- out=test_points << EOF
> 626382.68026139|228917.44816672|1
> 626643.91393428|228738.2879083|2
> 626907.14939778|228529.10079092|3
> EOF
>
> v.profile then misses out on point 2, even though it is within 500m:
>
> v.profile input=test_points output=- separator=comma dp=3 buffer=500
> profile_map=roadsmajor@PERMANENT profile_where=cat=193
> Number,Distance,cat,dbl_1,dbl_2,int_1
> 1,2102.114,3,626907.14939778,228529.10079092,3
> 2,2960.822,1,626382.68026139,228917.44816672,1

I see. I would +1 for setting current GRASS buffer functions to call
G_fatal_error till they get fixed or replaced by GEOS version. I also
would +1 to block 7.4.0 release till a final action is made (fatal
error or a fix). Quality (correctness) should be our priority.

> Moritz

Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Nikos Alexandris]

* Veronica Andreo  [2017-09-11 18:54:00 +0200]:


Hi all :)

2017-09-02 17:57 GMT+02:00 Markus Neteler :


On Fri, Sep 1, 2017 at 9:56 PM, Martin Landa 
wrote:
> Please all devs try to remember all cool features you implemented for
> G74 and put notes about that on trac wiki page! It will help a lot
> (going through all logs and discover new features is a very hard and
> time consuming job).

Some help for this:
* 24 May 2016 Creation of the GRASS GIS 7.2 release branch (r68500)

To save you some time, I have diff'ed the 7.2.2svn and 7.4.svn



there's no 7.4.svn yet, right? Only trunk (grass73), no?

Changelogs and removed from the result obvious "trivial" changes. The

remainder is here:
https://data.neteler.org/tmp/ChangeLog74_filtered.txt

From browsing this file memories may come back :-)

Please add findings then to
https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures74



I started going through the document to add what I believe might be
relevant stuff to the NewFeatures74 page, but some things in that diff file
were already reported in NewFeatures72, eg: all d.* changes done by Adam
Laza in GSoC 2016... so, I'm (will be) double checking. I wonder however if
it is ok to diff against r68500 or should be a later version (eg.: the
stable version released in December 2016, for example)? No idea



(also screenshots would be great)



yes! As well as some extra description from devs for the new cool features
implemented or examples of use of new features (or important bug fixes)!
That would make it much easier to then write the announcements, promote
grass elsewhere and show off a bit ;-)

cheers,
Vero


Last 100+ lines of https://data.neteler.org/tmp/ChangeLog74_filtered.txt
checked. Majority of entries already included in
https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures72 and/or
https://trac.osgeo.org/grass/log/grass/branches/releasebranch_7_2/.

Few entries added in
https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures74.

Diff file between ChangeLog74_filtered.txt any my review attached.

Nikos

 * raster/r.lake/main.c: r.lake: more guisections* 
raster/r.lake/main.c: r.lake: more guisections
 * gui/wxpython/gmodeler/model.py: g.gui.gmodeler: substitute | [Exclude] * 
gui/wxpython/gmodeler/model.py: g.gui.gmodeler: s
 * vector/v.outlier/main.c: v.outlier: define parser rule for | [Exclude] * 
vector/v.outlier/main.c: v.outlier: define parser
 * include/iostream/mm.h, lib/iostream/mm.cpp: use exception  | [Exclude] * 
include/iostream/mm.h, lib/iostream/mm.cpp: use e
 * raster/r.terraflow/grass2str.h: r.terraflow: add space bet | [Exclude] * 
raster/r.terraflow/grass2str.h: r.terraflow: add 
 * lib/init/helptext.html: helptext.html: improved section ab | [Exclude] * 
lib/init/helptext.html: helptext.html: improved s
 * lib/init/helptext.html: helptext.html: add section about t | [Exclude] * 
lib/init/helptext.html: helptext.html: add sectio
 * lib/init/grass.py: init: fix typo in r68797; advise user a | [Exclude] * 
lib/init/grass.py: init: fix typo in r68797; advi
 * raster/r.topidx/r.topidx.html: r.topidx: Fixed a link  | [Exclude] * 
raster/r.topidx/r.topidx.html: r.topidx: Fixed a 
 * raster/r.topmodel/r.topmodel.html: r.topmodel: Fixed a lin | [Exclude] * 
raster/r.topmodel/r.topmodel.html: r.topmodel: Fi
 * lib/init/grass.py: init: advise user about --help and -c   | [Exclude] * 
lib/init/grass.py: init: advise user about --help
 * gui/wxpython/gui_core/gselect.py, gui/wxpython/modules/imp | [Exclude] * 
gui/wxpython/gui_core/gselect.py, gui/wxpython/mo
 * vector/v.overlay/main.c: v.overlay: avoid fatal error (lay | [Exclude] * 
vector/v.overlay/main.c: v.overlay: avoid fatal e
 * display/d.legend/d.legend.html: d.legend: typo in document | [Exclude] * 
display/d.legend/d.legend.html: d.legend: typo in
 * display/d.legend/d.legend.html, display/d.legend/d_legend_ | [Exclude] * 
display/d.legend/d.legend.html, display/d.legend/
 * display/d.legend/draw.c, display/d.legend/main.c: d.legend | [Exclude] * 
display/d.legend/draw.c, display/d.legend/main.c:
 * gui/wxpython/gui_core/dialogs.py, gui/wxpython/gui_core/fo | [Include][Font 
can be selected interactively in module dialog
 * lib/gis/colors.desc, lib/gis/colors/grass: add GRASS green | [Exclude] * 
lib/gis/colors.desc, lib/gis/colors/grass: add GR
 * gui/wxpython/gui_core/forms.py: wxGUI: fix escape button t | [Exclude] * 
gui/wxpython/gui_core/forms.py: wxGUI: fix escape
 * display/d.legend/draw.c, display/d.legend/local_proto.h, d | [???] * 
display/d.legend/draw.c, display/d.legend/local_p
 * raster/r.info/main.c: r.info: make category title the prim | [Exclude] * 
raster/r.info/main.c: r.info: make category title
 * raster/r.support/main.c: r.support: remove unused variable | [Exclude] * 
raster/r.support/main.c: r.support: remove unused
 * raster/r.support/main.c: r.support: write category title,  | [Exclude] * 
raster/r.support/main.c: 

Re: [GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

Hi Maris,

Le Sun, 29 Oct 2017 12:31:35 +0200,
Maris Nartiss  a écrit :

> I added simple tests for v.profile. [1]
> I also changed one of examples from documentation to use NC Basic
> dataset. [2]
> 
> If v.profile is moved to trunk, README file should be deleted.
> 
> As there seem to be a lot of +1's and the requirement of tests is
> fulfilled, this addon should be moved to trunk to gain some exposure
> before release (or wait till 7.4.1).

v.profile still uses the old buffering library methods which has quite
a lot of issues.

As an example, I attach the output map of the following example:

v.profile input=geonames_NC@PERMANENT output=- separator=comma dp=3
buffer=500 profile_map=roadsmajor@PERMANENT profile_where=cat=193
map_output=test_profile

I also attach the equivalent v.buffer output:

v.buffer -c roadsmajor where=cat=193 dist=500 out=buff500

Would it be possible for you, Maris, to change to the GEOS method used
in v.buffer in order to get the same buffering output ?

This is not only formal as you can see when you use the following
vector points as input:

v.in.ascii in=- out=test_points << EOF
626382.68026139|228917.44816672|1
626643.91393428|228738.2879083|2
626907.14939778|228529.10079092|3
EOF

v.profile then misses out on point 2, even though it is within 500m:

v.profile input=test_points output=- separator=comma dp=3 buffer=500
profile_map=roadsmajor@PERMANENT profile_where=cat=193
Number,Distance,cat,dbl_1,dbl_2,int_1
1,2102.114,3,626907.14939778,228529.10079092,3
2,2960.822,1,626382.68026139,228917.44816672,1

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

Le Fri, 3 Nov 2017 17:56:35 +0100,
Markus Neteler  a écrit :

> On Thu, Nov 2, 2017 at 4:18 PM, Luca Delucchi 
> wrote:
> > On 2 October 2017 at 23:35, Markus Neteler 
> > wrote: 
> >>
> >> ###
> >> v.clip: NC dataset
> >> https://grass.osgeo.org/grass72/manuals/addons/v.clip.html
> >>
> >> A clip test could be made by counting points falling into a
> >> polygon, similar to the example in the manual page.
> >>  
> >
> > added tests in r71627.  
> 
> thanks!
> 
> v.clip addon moved to trunk in r71634 for further testing.
> 


I just added tests to r.object.geometry. Another potential candidate
for trunk, but not sure if we still want to do this now, or maybe for a
7.4.1.

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev