Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

[Paolo Cavallini]

Good point, a blog post is most welcome. Jorge and the team behind the 
migration deserve this honour. Jorge, would you mind writing it? 
Ready to help if necessary.
Cheers.

Il 28 maggio 2019 01:06:59 CEST, Nyall Dawson  ha 
scritto:
>On Tue, 28 May 2019 at 07:45, Jorge Gustavo Rocha 
>wrote:
>>
>> Hi Alexis,
>>
>> There is no formal cleanup call, but in are in feature freeze until
>3.8
>> release on summer solstice (next June, 21th). That is why Nyall
>proposed
>> this move to GitHub right now, on this feature freeze period.
>>
>
>> In other words, we are already in this "round of cleanup"!
>>
>> So, let's go get them!
>
>On this note -- this could be a great chance for a blog post
>advertising the change and improved workflow/usability, and put
>forward a call for more volunteers to help us triage and clean up the
>queue?
>
>Nyall
>
>>
>> Regards,
>>
>> Jorge Gustavo
>>
>> Às 21:50 de 27/05/19, Alexis R.L. escreveu:
>> > Greetings,
>> >
>> > Out of curiosity, will there be a round of cleanup? Some issues are
>> > either quite old and possibly not reproducible while some other are
>the
>> > eternal crash when closing qgis.
>> >
>> >
>> > Alexis Roy-Lizotte
>> >
>> >
>> > Le lun. 27 mai 2019 à 05:35, Giovanni Manghi
>> > > a écrit :
>> >
>> > Hi,
>> >
>> >
>> >
>> > >
>> > > - "Database" label: should this be renamed "db manager", to
>> > > disambiguate from postgis/spatialite/etc issues, which
>instead belong
>> > > under "data providers"?
>> >
>> > agree
>> >
>> > >
>> > > - Can "CAD" be merged into "Digitising"? There's only a
>handful of
>> > > open issues, and I don't think it warrants a separate
>category. In
>> > > QGIS these two concepts are basically merged now anyway.
>> >
>> > not sure, maybe this was meant for the DXF/DWG import/export
>tools?
>> >
>> >
>> >
>> > > - "Editing": This label is very vague -- it's being used for
>> > > digitizing issues, project editing issues, copy/paste issues,
>and even
>> > > data provider issues. I'd argue we could drop this label and
>use other
>> > > existing, more specific labels instead
>> >
>> >
>> > on Redmine I always assumed that "editing" was to be used for
>issues
>> > regarding the edits of alphanumeric attributes while
>"digitizing" was
>> > to be used for issues about the geometry edits.
>> >
>> >
>> > -- G --
>> > ___
>> > QGIS-Developer mailing list
>> > QGIS-Developer@lists.osgeo.org
>
>> > List info:
>https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> > Unsubscribe:
>https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >
>> >
>> > ___
>> > QGIS-Developer mailing list
>> > QGIS-Developer@lists.osgeo.org
>> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> > Unsubscribe:
>https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >
>>
>> J. Gustavo
>> --
>> Jorge Gustavo Rocha
>> Departamento de Informática
>> Universidade do Minho
>> 4710-057 Braga
>> Tel: +351 253604480
>> Fax: +351 253604471
>> Móvel: +351 910333888
>> skype: nabocudnosor
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>___
>QGIS-Developer mailing list
>QGIS-Developer@lists.osgeo.org
>List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Sorry for being short___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

[Nyall Dawson]

On Mon, 27 May 2019 at 17:54, Régis Haubourg  wrote:
>
>> - How should we handle milestones now? We've been using them up till
>> now to tag PRs with their target version, and closing off milestones
>> as each release is made. Now we've got a whole lot of outdated
>> milestones (e.g. 2.14) because we have issues which were tagged to
>> these milestones from the old "affected version" property. I don't
>> think this is correct use of the milestone functionality, and would
>> like to see it used only for release management (i.e. if a bug has a
>> milestone, it's being targeted for fixing in that version*, so bug
>> reports should always have ONLY future version milestones, not past
>> versions). This would mean we'd need to change the affected version
>> handling to labels. Is everyone OK with this?
>>
>  milestone is a target, affected version is a descriptive information for a 
> bug. I don't see any milestone define in the repo. Did you already clean this 
> up? I'm not sure I get your point in fact, the affected version is only a 
> text comment in the issue body from what I see. Did I miss something?

Check https://github.com/qgis/QGIS/milestones

and e..g. tickets tagged with milestone 2.14:
https://github.com/qgis/QGIS/milestones/Version%202.14

I've closed off all the old milestones with no tickets, but I'm unsure
how to deal with the ones with open tickets. We really should only
have 3.8.0 / 3.4.9 / 3.10 and the "future" milestones open.

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

[Nyall Dawson]

On Mon, 27 May 2019 at 19:35, Giovanni Manghi  wrote:
>
> Hi,
>
> > - "Editing": This label is very vague -- it's being used for
> > digitizing issues, project editing issues, copy/paste issues, and even
> > data provider issues. I'd argue we could drop this label and use other
> > existing, more specific labels instead
>
>
> on Redmine I always assumed that "editing" was to be used for issues
> regarding the edits of alphanumeric attributes while "digitizing" was
> to be used for issues about the geometry edits.

We've also got labels for both Attribute Table and Forms too. I'd
think issues relating to editing attributes in the table/editor
widgets/forms could better belong in those categories instead? (But
happy to take your lead)

Nyall



>
>
> -- G --
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

[Nyall Dawson]

On Mon, 27 May 2019 at 09:06, Nyall Dawson  wrote:
>
> Hi all,
>
> Once again, many many thanks to the individuals behind the the recent
> issues migration. Fantastic job all round!
>
> I'd like to do some post-migration cleanups, but would like wider
> opinions on how to handle these:
>
> - We have two labels "bug" and "bug fix" which apply to issues and
> pull requests respectively. Can we combine these, and just use "bug"
> for bug fixing PRs? (There's a LOT of labels now)

Done

>
> - "Database" label: should this be renamed "db manager", to
> disambiguate from postgis/spatialite/etc issues, which instead belong
> under "data providers"?

Done

>
> - Can "CAD" be merged into "Digitising"? There's only a handful of
> open issues, and I don't think it warrants a separate category. In
> QGIS these two concepts are basically merged now anyway.

Based on discussion, I've renamed this to DXF/DWG for clarification

> - "Easy fix". Does anyone actually use this? Many of these are not
> "easy fixes" -- e.g. I've been chipping away at
> https://github.com/qgis/QGIS/issues/28195 since last year... it's
> probably about the hardest fix I've ever done in QGIS. No idea how
> this one gained the label!

Ok, seems there's a strong argument to leave this in place!

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

[Nyall Dawson]

On Tue, 28 May 2019 at 07:45, Jorge Gustavo Rocha  wrote:
>
> Hi Alexis,
>
> There is no formal cleanup call, but in are in feature freeze until 3.8
> release on summer solstice (next June, 21th). That is why Nyall proposed
> this move to GitHub right now, on this feature freeze period.
>

> In other words, we are already in this "round of cleanup"!
>
> So, let's go get them!

On this note -- this could be a great chance for a blog post
advertising the change and improved workflow/usability, and put
forward a call for more volunteers to help us triage and clean up the
queue?

Nyall

>
> Regards,
>
> Jorge Gustavo
>
> Às 21:50 de 27/05/19, Alexis R.L. escreveu:
> > Greetings,
> >
> > Out of curiosity, will there be a round of cleanup? Some issues are
> > either quite old and possibly not reproducible while some other are the
> > eternal crash when closing qgis.
> >
> >
> > Alexis Roy-Lizotte
> >
> >
> > Le lun. 27 mai 2019 à 05:35, Giovanni Manghi  > > a écrit :
> >
> > Hi,
> >
> >
> >
> > >
> > > - "Database" label: should this be renamed "db manager", to
> > > disambiguate from postgis/spatialite/etc issues, which instead belong
> > > under "data providers"?
> >
> > agree
> >
> > >
> > > - Can "CAD" be merged into "Digitising"? There's only a handful of
> > > open issues, and I don't think it warrants a separate category. In
> > > QGIS these two concepts are basically merged now anyway.
> >
> > not sure, maybe this was meant for the DXF/DWG import/export tools?
> >
> >
> >
> > > - "Editing": This label is very vague -- it's being used for
> > > digitizing issues, project editing issues, copy/paste issues, and even
> > > data provider issues. I'd argue we could drop this label and use other
> > > existing, more specific labels instead
> >
> >
> > on Redmine I always assumed that "editing" was to be used for issues
> > regarding the edits of alphanumeric attributes while "digitizing" was
> > to be used for issues about the geometry edits.
> >
> >
> > -- G --
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org 
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> >
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
>
> J. Gustavo
> --
> Jorge Gustavo Rocha
> Departamento de Informática
> Universidade do Minho
> 4710-057 Braga
> Tel: +351 253604480
> Fax: +351 253604471
> Móvel: +351 910333888
> skype: nabocudnosor
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

[Jorge Gustavo Rocha]

Hi Alexis,

There is no formal cleanup call, but in are in feature freeze until 3.8
release on summer solstice (next June, 21th). That is why Nyall proposed
this move to GitHub right now, on this feature freeze period.

In other words, we are already in this "round of cleanup"!

So, let's go get them!

Regards,

Jorge Gustavo

Às 21:50 de 27/05/19, Alexis R.L. escreveu:
> Greetings,
> 
> Out of curiosity, will there be a round of cleanup? Some issues are
> either quite old and possibly not reproducible while some other are the
> eternal crash when closing qgis.
> 
> 
> Alexis Roy-Lizotte
> 
> 
> Le lun. 27 mai 2019 à 05:35, Giovanni Manghi  > a écrit :
> 
> Hi,
> 
> 
> 
> >
> > - "Database" label: should this be renamed "db manager", to
> > disambiguate from postgis/spatialite/etc issues, which instead belong
> > under "data providers"?
> 
> agree
> 
> >
> > - Can "CAD" be merged into "Digitising"? There's only a handful of
> > open issues, and I don't think it warrants a separate category. In
> > QGIS these two concepts are basically merged now anyway.
> 
> not sure, maybe this was meant for the DXF/DWG import/export tools?
> 
> 
> 
> > - "Editing": This label is very vague -- it's being used for
> > digitizing issues, project editing issues, copy/paste issues, and even
> > data provider issues. I'd argue we could drop this label and use other
> > existing, more specific labels instead
> 
> 
> on Redmine I always assumed that "editing" was to be used for issues
> regarding the edits of alphanumeric attributes while "digitizing" was
> to be used for issues about the geometry edits.
> 
> 
> -- G --
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org 
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

J. Gustavo
-- 
Jorge Gustavo Rocha
Departamento de Informática
Universidade do Minho
4710-057 Braga
Tel: +351 253604480
Fax: +351 253604471
Móvel: +351 910333888
skype: nabocudnosor
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

[Alexis R.L.]

Greetings,

Out of curiosity, will there be a round of cleanup? Some issues are either
quite old and possibly not reproducible while some other are the eternal
crash when closing qgis.


Alexis Roy-Lizotte


Le lun. 27 mai 2019 à 05:35, Giovanni Manghi  a
écrit :

> Hi,
>
>
>
> >
> > - "Database" label: should this be renamed "db manager", to
> > disambiguate from postgis/spatialite/etc issues, which instead belong
> > under "data providers"?
>
> agree
>
> >
> > - Can "CAD" be merged into "Digitising"? There's only a handful of
> > open issues, and I don't think it warrants a separate category. In
> > QGIS these two concepts are basically merged now anyway.
>
> not sure, maybe this was meant for the DXF/DWG import/export tools?
>
>
>
> > - "Editing": This label is very vague -- it's being used for
> > digitizing issues, project editing issues, copy/paste issues, and even
> > data provider issues. I'd argue we could drop this label and use other
> > existing, more specific labels instead
>
>
> on Redmine I always assumed that "editing" was to be used for issues
> regarding the edits of alphanumeric attributes while "digitizing" was
> to be used for issues about the geometry edits.
>
>
> -- G --
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [1095] AnnotationManager approval notification.

[noreply]

Plugin AnnotationManager approval by pcav.
The plugin version "[1095] AnnotationManager 0.5" is now approved
Link: http://plugins.qgis.org/plugins/annotationManager/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] saving a layer with the world_map.shp

[Raymond Nijssen]

I know it was introduced as an easter egg, but I'm very happy with the 
built in world map in qgis. I'm using it in a plugin to automatically 
add a layer for the overview map in my layout. This layer points to a 
shapefile in my qgis install directory:


/home/raymond/programs/qgis-master/share/qgis/resources/data/world_map.shp

Now, when saving my project and somebody else opening it, the layer is 
invalid (of course). Is there a way to make the project point to the 
right file, using some kind of variable pointing to the qgis 
installation path?


like this:
{QGIS_RESOURCE_PATH}/data/world_map.shp

or I could copy the world.shp into my plugin and do this:

{QGIS_PLUGIN_PATH}/my-plugin/data/world_map.shp

These paths should then be saved including the variable in the project file.



Another option would be to save the shp-file in the .qgz somehow but I'm 
not too sure if that is the way to go..




This is the way I create the path now:

worldShp = os.path.join(QgsApplication.pkgDataPath(), 'resources', 
'data', 'world_map.shp')




To make the question more general, is it possible to add resources to a 
plugin in a way that projects point to these resources and make that 
work for other users too?



Hope anyone can help!

Kind regards,
Raymond


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-community-team] [Qgis-user] Redmine migration plan: friday 24 may 8:00 CET

[Paolo Cavallini]

Thanks, a big effort to solve a long standing deadlock.
All the best.

Il 27 maggio 2019 11:01:09 CEST, Tim Sutton  ha scritto:
>Thank you so much everyone involved!
>
>Regards
>
>Tim
>
>> On 26 May 2019, at 09:42, Régis Haubourg 
>wrote:
>> 
>> Oh yeah! 
>> Great work guys 
>> 
>> Le dim. 26 mai 2019 à 00:55, Richard Duivenvoorde
>mailto:rdmaili...@duif.net>> a écrit :
>> Update from migration team:
>> 
>> Migration of all Redmine issue is DONE !
>> 
>> https://github.com/qgis/QGIS/issues/
>
>> 
>> The interaction limitation has ended and you can start working on
>(your)
>> issues on GitHub.
>> 
>> Go, fix, enjoy and happy QGISsing on github!
>> 
>> Regards,
>> 
>> Richard Duivenvoorde
>> 
>> ps according to Jorge (aka 'migration team'), there is some minor
>> housekeeping to be done, but users and dev can... GO :-)
>> 
>> 
>> 
>> On 25/05/2019 14.56, Richard Duivenvoorde wrote:
>> > Update from mirgration team:
>> > 
>> > Hi @all,
>> > 
>> > The issue migration from Redmine to GitHub is going on smoothly
>(but slow).
>> > 
>> > The first phase (moving the issues) is finished. All 19845 issues
>are
>> > now on GitHub :-)
>> > 
>> > Since the issue ids have changed, we started a second run to
>replace
>> > old ids with the new ones. This second phase is faster than the
>> > first one. It will take about 9 to 10 hours (we are able to update
>> > +-2200 issues per hour and we have almost 20k issues).
>> > 
>> > To prevent people for changing or comment issues, we will keep the
>> > interaction limited to developers with push access, until the
>migration
>> > is complete. Developers with push access can do PR and MR (but can
>also
>> > enjoy the weekend ;-).
>> > 
>> > So, we expected to have the migration finished today by 22:00
>(GMT+1)
>> > (London time).
>> > 
>> > Thanks for your comprehension!
>> > 
>> > 
>> > On 22/05/2019 14.06, Richard Duivenvoorde wrote:
>> >> Hi All (lists),
>> >>
>> >> We propose to do the Redmine -> Github migration next friday 24th
>of may
>> >> at 8:00 CET (+2).
>> >>
>> >> More or less following this Migration plan:
>> >>
>> >>
>https://github.com/qgis/QGIS-Enhancement-Proposals/issues/141#issuecomment-478296818
>
>> >>
>> >> To be clear: this means http://issues.qgis.org
> cannot be used on friday,
>> >> untill the migration is finished and checked.
>> >>
>> >> If anybody has knowledge of an easy way to make Redmine readonly,
>please
>> >> let us know. Some googling to me only revealed changing the
>database
>> >> user or fiddling with the users in the db itself.
>> >>
>> >> Jorge will be in the lead for the Migration team
>> >> I (among others) will be around for QGIS Infra
>> >> Any help or encouragement is appreciated :-)
>> >>
>> >> Let's meet on IRC on friday morning, we can further decide on
>> >> communication if needed/wanted.
>> >>
>> >> If I miss something, please let us know.
>> >>
>> >> Regards,
>> >>
>> >> Richard Duivenvoorde
>> >> ___
>> >> QGIS-Developer mailing list
>> >> QGIS-Developer@lists.osgeo.org
>
>> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>> >> Unsubscribe:
>https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>> >>
>> > 
>> > ___
>> > Qgis-user mailing list
>> > qgis-u...@lists.osgeo.org 
>> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
>
>> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>
>> > 
>> 
>> ___
>> Qgis-community-team mailing list for organizing community resources
>such as documentation, translation etc..
>> qgis-community-t...@lists.osgeo.org
>
>> https://lists.osgeo.org/mailman/listinfo/qgis-community-team
>___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>—
>
>
>
>
>
>
>
>
>
>Tim Sutton
>
>Co-founder: Kartoza
>Ex Project chair: QGIS.org
>
>Visit http://kartoza.com  to find out about open
>source:
>
>Desktop GIS programming services
>Geospatial web development
>GIS Training
>Consulting Services
>
>Skype: timlinux 

Re: [QGIS-Developer] [Qgis-community-team] [Qgis-user] Redmine migration plan: friday 24 may 8:00 CET

[Tim Sutton]

Thank you so much everyone involved!

Regards

Tim

> On 26 May 2019, at 09:42, Régis Haubourg  wrote:
> 
> Oh yeah! 
> Great work guys 
> 
> Le dim. 26 mai 2019 à 00:55, Richard Duivenvoorde  > a écrit :
> Update from migration team:
> 
> Migration of all Redmine issue is DONE !
> 
> https://github.com/qgis/QGIS/issues/ 
> 
> The interaction limitation has ended and you can start working on (your)
> issues on GitHub.
> 
> Go, fix, enjoy and happy QGISsing on github!
> 
> Regards,
> 
> Richard Duivenvoorde
> 
> ps according to Jorge (aka 'migration team'), there is some minor
> housekeeping to be done, but users and dev can... GO :-)
> 
> 
> 
> On 25/05/2019 14.56, Richard Duivenvoorde wrote:
> > Update from mirgration team:
> > 
> > Hi @all,
> > 
> > The issue migration from Redmine to GitHub is going on smoothly (but slow).
> > 
> > The first phase (moving the issues) is finished. All 19845 issues are
> > now on GitHub :-)
> > 
> > Since the issue ids have changed, we started a second run to replace
> > old ids with the new ones. This second phase is faster than the
> > first one. It will take about 9 to 10 hours (we are able to update
> > +-2200 issues per hour and we have almost 20k issues).
> > 
> > To prevent people for changing or comment issues, we will keep the
> > interaction limited to developers with push access, until the migration
> > is complete. Developers with push access can do PR and MR (but can also
> > enjoy the weekend ;-).
> > 
> > So, we expected to have the migration finished today by 22:00 (GMT+1)
> > (London time).
> > 
> > Thanks for your comprehension!
> > 
> > 
> > On 22/05/2019 14.06, Richard Duivenvoorde wrote:
> >> Hi All (lists),
> >>
> >> We propose to do the Redmine -> Github migration next friday 24th of may
> >> at 8:00 CET (+2).
> >>
> >> More or less following this Migration plan:
> >>
> >> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/141#issuecomment-478296818
> >>  
> >> 
> >>
> >> To be clear: this means http://issues.qgis.org  
> >> cannot be used on friday,
> >> untill the migration is finished and checked.
> >>
> >> If anybody has knowledge of an easy way to make Redmine readonly, please
> >> let us know. Some googling to me only revealed changing the database
> >> user or fiddling with the users in the db itself.
> >>
> >> Jorge will be in the lead for the Migration team
> >> I (among others) will be around for QGIS Infra
> >> Any help or encouragement is appreciated :-)
> >>
> >> Let's meet on IRC on friday morning, we can further decide on
> >> communication if needed/wanted.
> >>
> >> If I miss something, please let us know.
> >>
> >> Regards,
> >>
> >> Richard Duivenvoorde
> >> ___
> >> QGIS-Developer mailing list
> >> QGIS-Developer@lists.osgeo.org 
> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
> >> 
> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
> >> 
> >>
> > 
> > ___
> > Qgis-user mailing list
> > qgis-u...@lists.osgeo.org 
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user 
> > 
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user 
> > 
> > 
> 
> ___
> Qgis-community-team mailing list for organizing community resources such as 
> documentation, translation etc..
> qgis-community-t...@lists.osgeo.org 
> 
> https://lists.osgeo.org/mailman/listinfo/qgis-community-team 
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org 
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
> 
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
> 
—









Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

I'd love to connect. Here's my calendar link  to 
make finding time easy.

___
QGIS-Developer mailing list

Re: [QGIS-Developer] [GSoC 2019 - QGIS 3D Improvement] Community Bonding Period Report

[Tim Sutton]

Thanks for sharing Sunni!

T

> On 26 May 2019, at 18:47, Ismail Sunni  wrote:
> 
> Dear QGIS Developers,
> 
> Here is my update from the GSoC community bonding. You can also find it in 
> https://github.com/ismailsunni/QGIS/wiki/Community-Bonding-Period 
> 
> 
> Community Bonding Period
> 
> Overview
> The community bonding period started from 6 May 2019 until 26 May 2019. In 
> this community bonding period, my mentor, Martin Dobias, helps me to start 
> the introduction [1] to the mailing list. I introduce myself and the project 
> that I will work on [2]. I have already explained the project and asked for 
> feedback before the proposal submission to the developer mailing list [3]. I 
> also sent a similar email to the SOC [4].
> 
> With my mentors (Martin and Peter), we have met twice virtually via video 
> call during the community bonding. For some quick questions, we also use a 
> messaging platform. For the coding period, we agree to meet twice a week. 
> Additionally, I have met with both of my mentors offline before the community 
> bonding/GSoC announcement.
> 
> In term of the QGIS project, I have already set up my developer environment 
> (and build frequently). I have been quite familiar with the development 
> process (repository, pull request, issue tracker, documentation, QEP, 
> communication, the organization, etc).
> 
> For the technical aspect, my main task in the project is learning about 3D 
> programming and fresh my Qt C++. For this, my mentor suggested me to learn 
> from LearnOpenGL [5]. I also did some coding with Qt 3D with C++. The code 
> can be checked in my Github Repository [6]. Perhaps can be useful for others 
> since I couldn't find a good Qt 3D C++ tutorial out there.
> 
> Additionally, I tried to go to the QGIS 3D codebase and do some research 
> about the implementation (e.g. QDial for the on-screen navigation [7])
> 
> Regarding the project, I also made a Github issue to track my progress for my 
> first improvement (On-Screen Navigation)[8]. I made a mockup for it also.
> 
> Lastly, on the GSoC itself, I have made a Wiki to put everything related to 
> my project [9]. I will update it regularly (or weekly).
> 
> Checklist
> Here some checklist that I have done in the community bonding period:
> - [x]  _Request writing access to the OSGeo wiki, you need it to edit all 
> info related to your project_   
> - [x] _Get to know your mentors, establish with them a way of communication, 
> that can be video call, chat, email, etc. You are supposed to communicate 
> regularly and often with your mentors._
> - [x] Familiarize with the community practices and processes: how does the 
> community communicate? Where is the source code published? How does the bug 
> tracker work? 
> - [x] Introduce yourself and your project in SOC mailing list as well as the 
> mailing list used by your software community, and start a public dialogue to 
> gather feedback and refine your project accordingly.
> - [x] Redefine your project with more detailed weekly milestones, with the 
> help of your mentors and the feedback of the community, embedding the 3 
> evaluation periods in your timetable, adding more details, figuring out 
> potential issues, etc.
> - [x] Become familiar with the developer manuals
> - [x] Study material relevant for your project
> - [x] Install the developer environment and get ready to start coding
> - [ ] Participate in Mailing Lists / IRC / etc, try and help users
>   > I was trying to do it (reading the mailing list often), but 
> unfortunately, I couldn't answer the questions that came up
> - [ ] Start coding for bug fixes NOT necessarily related to your project: it 
> is a good exercise to become familiar with the code base. Include these bug 
> fixes into your report due at the end of bonding period.
>   > No. My mentors suggested me to learn the 3D code base instead.
> - [x] Set up your repository and wiki page for your project. You are free to 
> blog/tweet about it too, if you wish. Don’t forget to include these info in 
> the report due at the end of the bonding period.
> - [x] Ask your mentors for guidance on how to commit to the project 
> repository. Bear in mind that you should commit often, not just at evaluation 
> periods. However, depending on the policy given by your mentors, you might be 
> requested to commit in your own repository and make a PR only when the code 
> is mature to be included in the main repo. Discuss the details with your 
> mentors.
> 
> Best Regards
> 
> * [1] https://lists.osgeo.org/pipermail/qgis-developer/2019-May/057206.html 
> 
> * [2] https://lists.osgeo.org/pipermail/qgis-developer/2019-May/057218.html 
> 
> * [3] https://lists.osgeo.org/pipermail/qgis-developer/2019-April/056851.html 
> 

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

[Régis Haubourg]

Hi,

Le lun. 27 mai 2019 à 01:06, Nyall Dawson  a écrit :

> Hi all,
>
> Once again, many many thanks to the individuals behind the the recent
> issues migration. Fantastic job all round!
>
+1 !

>
> I'd like to do some post-migration cleanups, but would like wider
> opinions on how to handle these:
>
> - We have two labels "bug" and "bug fix" which apply to issues and
> pull requests respectively. Can we combine these, and just use "bug"
> for bug fixing PRs? (There's a LOT of labels now)
>
+1

>
> - "Database" label: should this be renamed "db manager", to
> disambiguate from postgis/spatialite/etc issues, which instead belong
> under "data providers"?
>
+1

>
> - Can "CAD" be merged into "Digitising"? There's only a handful of
> open issues, and I don't think it warrants a separate category. In
> QGIS these two concepts are basically merged now anyway.
>
+1

>
> - "Easy fix". Does anyone actually use this? Many of these are not
> "easy fixes" -- e.g. I've been chipping away at
> https://github.com/qgis/QGIS/issues/28195 since last year... it's
> probably about the hardest fix I've ever done in QGIS. No idea how
> this one gained the label!
>
Let's keep the label as an attempt to help new contributors to board in.
Core dev's shouldn't be shy about removing the "Easy fix" tag when they
know it's not easy :)

>
> - "Editing": This label is very vague -- it's being used for
> digitizing issues, project editing issues, copy/paste issues, and even
> data provider issues. I'd argue we could drop this label and use other
> existing, more specific labels instead
>
+1

>
> - "Feature request" / "Feature": I'm not sure how we'd go about
> merging these two categories, but it seems strange to have the two
> separate.
>
+1 . the label list was discussed only using the redmine candidates and we
forgot to check duplicates already in the QGIS github repo.. Let's solve
this.

>
> - How should we handle milestones now? We've been using them up till
> now to tag PRs with their target version, and closing off milestones
> as each release is made. Now we've got a whole lot of outdated
> milestones (e.g. 2.14) because we have issues which were tagged to
> these milestones from the old "affected version" property. I don't
> think this is correct use of the milestone functionality, and would
> like to see it used only for release management (i.e. if a bug has a
> milestone, it's being targeted for fixing in that version*, so bug
> reports should always have ONLY future version milestones, not past
> versions). This would mean we'd need to change the affected version
> handling to labels. Is everyone OK with this?
>
>  milestone is a target, affected version is a descriptive information for
a bug. I don't see any milestone define in the repo. Did you already clean
this up? I'm not sure I get your point in fact, the affected version is
only a text comment in the issue body from what I see. Did I miss something?


> Nyall
>
> * Ideally, we'd block non-core-contributors from setting milestones
> for issues, to avoid reporters just tagging their issue with an
> upcoming milestone as a rude way of saying "fix my stuff for me"
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Trouble compiling QGIS mapserver only

[Asger Sigurd Skovbo Petersen]

For future reference:

Issue 21382 (Fails to build with SERVER_PLUGINS disabled) is fixed in master.

/Asger

> On 22 May 2019, at 11.25, Asger Sigurd Skovbo Petersen 
>  wrote:
> 
> Inspired by bitner's mapserver AWS Lambda layer [0] I wanted to try and 
> compile a QGIS mapserver for AWS Lambda. Keeping the build to an absolute 
> minimum is important for several reasons
> 1) Amazon Linux having basically no package support means compiling all 
> dependencies from scratch
> 2) Lambda has a 250MB limit on deployment package size [1]
> 3) Minimizing complexity
> 
> Initially I tried compiling qgis mapserver without gui and python support at 
> all. INSTALL document [2] states fastcgi as the only dependency, but I am hit 
> by issue 21382 [3] which means qgis mapserver cannot compile with 
> SERVER_PLUGINS disabled.
> 
> Enabling SERVER_PLUGINS seems to require enabling BINDINGS. As mentioned I 
> would prefer not having python support at all, but if I make with 
> WITH_SERVER_PLUGINS=ON, WITH_BINDINGS=ON and WITH_STAGED_PLUGINS=OFF then 
> `make install` fails when installing db_manager (!):
> 
> CMake Error at python/plugins/db_manager/cmake_install.cmake:41 (file):
>   file INSTALL cannot find
>   "/build/qgis/python/plugins/db_manager/resources_rc.py".
> Call Stack (most recent call first):
>   python/plugins/cmake_install.cmake:42 (include)
>   python/cmake_install.cmake:144 (include)
>   cmake_install.cmake:63 (include)
> 
> My dockerfile resulting in the above error can be seen at [4]. It is quite 
> messy as a result of many trial and error iterations.
> 
> Shouldnt it be possible to build QGIS mapserver without all the other stuff? 
> Is it at all possible to build QGIS mapserver as a server application without 
> all the gui related stuff and preferable without python?
> 
> Any advice on how to proceed is extremely welcome!
> 
> Thanks in advance
> Asger
> 
> [0] https://github.com/bitner/mapserverless-layer
> [1] https://dashbird.io/blog/exploring-lambda-limitations/
> [2] 
> https://github.com/qgis/QGIS/blob/152a556887fe4c762ef03411a5825d0c120488dd/INSTALL#L123
> [3] https://issues.qgis.org/issues/21382
> [4] 
> https://gist.github.com/AsgerPetersen/3b98b02461d745813dda92a10185b22a#file-dockerfile

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] github tickets authorship

[Paolo Cavallini]

Hi Jorge,
thanks for the tip. I believe it should be included in the instructions
to use the new bugtracking system (or can we add a shortcut?).
Cheers.

On 26/05/19 17:21, Jorge Gustavo Rocha wrote:
> Hi Sandro,
> 
> The information about the author is there, but the issues were created
> by the bot. You can not search previous issues by: author:strk.
> 
> But since your name was mapped to your GH account, you don't need to
> search by your name (as a text string). You can search:
> 
> is:open mentions:strk
> or
> is:open assignee:strk
> 
> Regards,
> 
> Jorge Gustavo
> 
> Às 13:27 de 26/05/19, Sandro Santilli escreveu:
>> I was looking at the migrated tickets and found that no tickets
>> are known as being reported by myself. Searching for "own tickets"
>> is something I'm used to do, periodically, to see if there's any
>> problem that I reported that can be closed (I'm probably in the
>> best position to test my own tickets).
>>
>> Was authorship information lost in the migration or is there a plan
>> to recover ?
>>
>> --strk;
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
> 
> J. Gustavo
> 

-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] issues when building QGIS in Docker with Qt 5.10+, help from Docker experts

[Daniele Viganò]

Just an update: it looks like that statx() is now availbale in 18.04
out-of-the-box:
https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1755250

Daniele

On Mon, May 27, 2019 at 7:49 AM Daniele Viganò  wrote:

> Hi Denis,
>
> we had the same issue with our QGIS Server Docker containers (see
> https://github.com/gem/oq-qgis-server/issues/1). Fedora based containers
> use Qt 5.11 thus they need statx().
> I did not found a 'final' solution: to be able to use statx() you need, on
> the host, Docker 18.04+ _and_ libseccomp2_2.3.1+ which are available when
> using a recent Fedora host but not, for example, Ubuntu < 18.10. I know
> that Marco Benasocchi was able to use libseccomp2_2.3.1 deb package from
> 18.10 on 18.04, but I don't know if that works fine on 16.04 (Xenial) which
> runs on Travis.
>
> The 'official' answer that I got from the Qt guys is that Qt is smart and
> discovers automatically the availability of statx() at compile time (and
> there's also a flag to forcefully disable support for it), but the problem
> here is that Qt has been compiled on a system that supports statx() so Qt
> expects it availability; instead in the runntime environment (Docker) all
> the conditions to use statx() are satisfied, but then the request is
> blocked by seecomp policies.
>
> Daniele
>
> On Mon, May 27, 2019 at 6:47 AM Denis Rouzaud 
> wrote:
>
>> Hi all,
>>
>> I am trying to update the base Docker image from Cosmic to Disco to get a
>> more recent SIP version.
>>
>> Before Cosmic Docker was building fine on Travis with Trusty.
>> I updated the Docker image to Disco and hit a timeout when building sip
>> files for QGIS.
>> So, I tried to update the Travis dist to Xenial, and now I get this issue:
>> clang: error: no such file or directory: 'src/native/moc_qgsnative.cpp'
>>
>> This seems to be a known issue in Qt 5.10+ which requires statx calls:
>>
>> From the Qt release notes (
>> https://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.10.0#n502):
>>
>> Qt uses the statx(2) system call for obtaining file information on
>>kernels 4.12 and later. Some older container systems install system call
>>protection rules that do not include this system call. If you experience
>>problems running Qt applications inside containers (such as the report of
>>a file not existing when it does), ensure the statx(2) is allowed in the
>>container configuration.
>>
>>
>> I found some information saying that this could be solved by using the
>> privileged mode when doing docker run.
>> But in our case, the QGIS build is made within the Docker build (and not
>> docker run).
>> From the Docker docs, it seems that building has full capabilities.
>>
>> I don't really know what to look for. If anyone has a hint, it is more
>> than welcome.
>>
>> Cheers,
>> Denis
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> *Daniele Viganò*
> http://daniele.vigano.me
>


-- 
*Daniele Viganò*
http://daniele.vigano.me
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer