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

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Nyall Dawson
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)

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

- 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.

- "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!

- "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

- "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.

- 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?

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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Post github issues migration clean ups - some proposals

3nids
Hi Nyall,

I generally completely agree with all the points you raised, some comments below

Le dim. 26 mai 2019 à 18:06, Nyall Dawson <[hidden email]> a écrit :
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)

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

- 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. 

- "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!

I'm +0 here. I liked the idea of easy fixes for new comers. On the other hand, it's a bit weird to keep "easy" fixed issues. 

- "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

- "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.

- 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?

+1. But, we should indeed have a strict definition of when adding the milestone (someone is taking care of the fix or every time it's just considered as important). I'd rather keep milestones for PRs and maybe bring back the idea of "blocker" tag. 

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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Post github issues migration clean ups - some proposals

Nyall Dawson
On Mon, 27 May 2019 at 11:43, Denis Rouzaud <[hidden email]> wrote:

> +1. But, we should indeed have a strict definition of when adding the milestone (someone is taking care of the fix or every time it's just considered as important). I'd rather keep milestones for PRs and maybe bring back the idea of "blocker" tag.

I think it should only be defined by someone actually assigned to the
bug. E.g. if I self-assign a bunch of bugs I'm actively working on,
I'd like to be able to use milestones to self-manage these...

Nyall


>>
>>
>> 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
>> [hidden email]
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Post github issues migration clean ups - some proposals

3nids


Le dim. 26 mai 2019 à 21:38, Nyall Dawson <[hidden email]> a écrit :
On Mon, 27 May 2019 at 11:43, Denis Rouzaud <[hidden email]> wrote:

> +1. But, we should indeed have a strict definition of when adding the milestone (someone is taking care of the fix or every time it's just considered as important). I'd rather keep milestones for PRs and maybe bring back the idea of "blocker" tag.

I think it should only be defined by someone actually assigned to the
bug. E.g. if I self-assign a bunch of bugs I'm actively working on,
I'd like to be able to use milestones to self-manage these...

I see, I'm just afraid to see too many issues left-open with a past milestone.
But we can give it a try I guess.
 

Nyall


>>
>>
>> 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
>> [hidden email]
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Post github issues migration clean ups - some proposals

3nids
Hi all,

May I also suggest to create a "wontfix" label?

Le dim. 26 mai 2019 à 21:46, Denis Rouzaud <[hidden email]> a écrit :


Le dim. 26 mai 2019 à 21:38, Nyall Dawson <[hidden email]> a écrit :
On Mon, 27 May 2019 at 11:43, Denis Rouzaud <[hidden email]> wrote:

> +1. But, we should indeed have a strict definition of when adding the milestone (someone is taking care of the fix or every time it's just considered as important). I'd rather keep milestones for PRs and maybe bring back the idea of "blocker" tag.

I think it should only be defined by someone actually assigned to the
bug. E.g. if I self-assign a bunch of bugs I'm actively working on,
I'd like to be able to use milestones to self-manage these...

I see, I'm just afraid to see too many issues left-open with a past milestone.
But we can give it a try I guess.
 

Nyall


>>
>>
>> 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
>> [hidden email]
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Post github issues migration clean ups - some proposals

DelazJ
Hi

"Easy fix" is what introduced me to the QGIS code (and maybe to GH). It makes things less intimidating, particularly when you are not a developer (not all the issues require to be a master in coding) and this is what i from time to time use to check in redmine. And TBH, this is the first filter I applied to the new list in GH. The issue is that in Redmine, the easy status was often decided by the reporter and I'm not sure they always knew the internals of the code before tagging (though i might admit that it's not simple to identify what is easy for others).

About the weirdness to keep bugs that are easy to fix, yes it's weird but it's the price to pay to attract new contributors. And there are issues that don't really hurt the project if kept unfixed. In docs we have an easy label that we spend as much time to label and add guidance than we'd spend to fix the issue but from time to time (unfortunately not as frequent that i wish) there's a new contributor who picks one and fix it. And at that moment, you see the benefit.
One thing we can do, or maybe did I miss it for the recent releases, is to make a real call when we move to feature freeze. I did not see a call for this one and got the information in irc; not all potential contributors follow the countdown at qgis.org. Without a clear call inviting testers, extending bug fixes time would not have more benefit. But other than testers, we can add a focus on the "easy fix" label inviting people that want to contribute to give them a shot. And if a week before the release there still are "easy fix" issues, core devs can clean them if they want.

just my 2cts
Harrissou (a non dev that is often happy to fix code and want the process to be easy for him)

Le lun. 27 mai 2019 à 06:30, Denis Rouzaud <[hidden email]> a écrit :
Hi all,

May I also suggest to create a "wontfix" label?

Le dim. 26 mai 2019 à 21:46, Denis Rouzaud <[hidden email]> a écrit :


Le dim. 26 mai 2019 à 21:38, Nyall Dawson <[hidden email]> a écrit :
On Mon, 27 May 2019 at 11:43, Denis Rouzaud <[hidden email]> wrote:

> +1. But, we should indeed have a strict definition of when adding the milestone (someone is taking care of the fix or every time it's just considered as important). I'd rather keep milestones for PRs and maybe bring back the idea of "blocker" tag.

I think it should only be defined by someone actually assigned to the
bug. E.g. if I self-assign a bunch of bugs I'm actively working on,
I'd like to be able to use milestones to self-manage these...

I see, I'm just afraid to see too many issues left-open with a past milestone.
But we can give it a try I guess.
 

Nyall


>>
>>
>> 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
>> [hidden email]
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Post github issues migration clean ups - some proposals

Régis Haubourg
In reply to this post by Nyall Dawson
Hi,

Le lun. 27 mai 2019 à 01:06, Nyall Dawson <[hidden email]> 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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Post github issues migration clean ups - some proposals

Giovanni Manghi
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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]
> <mailto:[hidden email]>> 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
>     [hidden email] <mailto:[hidden email]>
>     List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>     Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> _______________________________________________
> QGIS-Developer mailing list
> [hidden email]
> 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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Post github issues migration clean ups - some proposals

Nyall Dawson
On Tue, 28 May 2019 at 07:45, Jorge Gustavo Rocha <[hidden email]> 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 <[hidden email]
> > <mailto:[hidden email]>> 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
> >     [hidden email] <mailto:[hidden email]>
> >     List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >     Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> >
> > _______________________________________________
> > QGIS-Developer mailing list
> > [hidden email]
> > 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
> [hidden email]
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Post github issues migration clean ups - some proposals

Nyall Dawson
In reply to this post by Nyall Dawson
On Mon, 27 May 2019 at 09:06, Nyall Dawson <[hidden email]> 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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Post github issues migration clean ups - some proposals

Nyall Dawson
In reply to this post by Giovanni Manghi
On Mon, 27 May 2019 at 19:35, Giovanni Manghi <[hidden email]> 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
> [hidden email]
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Post github issues migration clean ups - some proposals

Nyall Dawson
In reply to this post by Régis Haubourg
On Mon, 27 May 2019 at 17:54, Régis Haubourg <[hidden email]> 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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Post github issues migration clean ups - some proposals

pcav
In reply to this post by Nyall Dawson
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 <[hidden email]> ha scritto:
On Tue, 28 May 2019 at 07:45, Jorge Gustavo Rocha <[hidden email]> 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 <[hidden email]
<mailto:[hidden email]>> 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
[hidden email] <mailto:[hidden email]>
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
QGIS-Developer mailing list
[hidden email]
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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

QGIS-Developer mailing list
[hidden email]
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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

[QGIS-Developer] Issues ID mapping (was: Post github issues migration clean ups - some proposals)

Sandro Santilli-4
In reply to this post by Nyall Dawson
I was thinking that after migration it would be useful to be able
to still follow a link from a commit log to its corresponding issue.

My understanding is that there's no 1:1 mapping between a Redmine
issue number and a GitHub issue number other than using a lookup
table (not included in QGIS source tree). Is that right ?

Is there any other way to tell which issue number refers to each
tracker ? Like... is there a "biggest issue number" that we could
use to distinguish between the two ?

The use case for this would be to set up a redirect from
issues.qgis.org so that whoever asks for a bigger issue number
is sent to github. This would also simplify mapping of issue refs
in commit logs from something like the Gitea mirror of QGIS, see
this page for example:

  https://git.osgeo.org/gitea/qgis/QGIS/commit/3f9a07e7

You can see the commit log references #30003 issue number.
Gitea was configured to transform that into a link to issues.qgis.org,
but such link is a "not found" page:

  https://issues.qgis.org/issues/30003

An older commit, like this (not too old):

  https://git.osgeo.org/gitea/qgis/QGIS/commit/f9810a453

Also references an issue number (#14885) but in this case
the link goes to an existing page:

  https://issues.qgis.org/issues/14885

The solution I'd see for this would be setting up a redirect
on issues.qgis.org to do the second hop to GitHub when needed,
is that possible to do at the moment ?

PS: needless to say, if/when in the future QGIS issues will move
    again we'll have NO CHANCE of setting up such redirects...

--strk;
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Issues ID mapping (was: Post github issues migration clean ups - some proposals)

Jorge Gustavo Rocha
Hi Sandro,

Às 08:36 de 30/05/19, Sandro Santilli escreveu:
> I was thinking that after migration it would be useful to be able
> to still follow a link from a commit log to its corresponding issue.
> > My understanding is that there's no 1:1 mapping between a Redmine
> issue number and a GitHub issue number other than using a lookup
> table (not included in QGIS source tree). Is that right ?
>

The mapping table (m: red x gh) is available at:
https://github.com/qgis/QGIS-Enhancement-Proposals/issues/141#issuecomment-496006337

I think we need that table and the commit date. Commits before 20190526
should point to GitHub issue m(red); after 20190526 should point to
GitHub issue gh.

It that possible?

> Is there any other way to tell which issue number refers to each
> tracker ? Like... is there a "biggest issue number" that we could
> use to distinguish between the two ?
>
> The use case for this would be to set up a redirect from
> issues.qgis.org so that whoever asks for a bigger issue number
> is sent to github. This would also simplify mapping of issue refs
> in commit logs from something like the Gitea mirror of QGIS, see
> this page for example:
>
>   https://git.osgeo.org/gitea/qgis/QGIS/commit/3f9a07e7
>
> You can see the commit log references #30003 issue number.
> Gitea was configured to transform that into a link to issues.qgis.org,
> but such link is a "not found" page:
>
>   https://issues.qgis.org/issues/30003
>
> An older commit, like this (not too old):
>
>   https://git.osgeo.org/gitea/qgis/QGIS/commit/f9810a453
>
> Also references an issue number (#14885) but in this case
> the link goes to an existing page:
>
>   https://issues.qgis.org/issues/14885
>
> The solution I'd see for this would be setting up a redirect
> on issues.qgis.org to do the second hop to GitHub when needed,
> is that possible to do at the moment ?
>
> PS: needless to say, if/when in the future QGIS issues will move
>     again we'll have NO CHANCE of setting up such redirects...

I'm trying to find old Redmine issue references and replace then by the
new ones, so everything points to the new ones. Commits messages are not
easy to change, since the message itself is part of the commit.

I've just made https://github.com/qgis/QGIS/pull/30014 to have all
comments in code (and in tests) pointing only to GitHub.

Regards,

Jorge Gustavo

>
> --strk;
> _______________________________________________
> QGIS-Developer mailing list
> [hidden email]
> 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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Issues ID mapping (was: Post github issues migration clean ups - some proposals)

Sandro Santilli-4
On Thu, May 30, 2019 at 09:04:30AM +0100, Jorge Gustavo Rocha wrote:

> Hi Sandro,
>
> Às 08:36 de 30/05/19, Sandro Santilli escreveu:
> > I was thinking that after migration it would be useful to be able
> > to still follow a link from a commit log to its corresponding issue.
> > > My understanding is that there's no 1:1 mapping between a Redmine
> > issue number and a GitHub issue number other than using a lookup
> > table (not included in QGIS source tree). Is that right ?
> >
>
> The mapping table (m: red x gh) is available at:
> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/141#issuecomment-496006337
>
> I think we need that table and the commit date. Commits before 20190526
> should point to GitHub issue m(red); after 20190526 should point to
> GitHub issue gh.
>
> It that possible?

With free software everything is possible,
but needs to be implemented ...

At the moment Gitea web UI does NOT let you express such filters.
Apache filters would be more powerful but would not have access
to commit date.

Implementing this in Gitea has a cost. Would such cost be worth
the history-recover ? Again: remember this will be NOT POSSIBLE
in the future, when moving _out_ of github.

> > PS: needless to say, if/when in the future QGIS issues will move
> >     again we'll have NO CHANCE of setting up such redirects...
>
> I'm trying to find old Redmine issue references and replace then by the
> new ones, so everything points to the new ones. Commits messages are not
> easy to change, since the message itself is part of the commit.

Right, that'd be history-rewriting. History rewriting would always
be possible, although destructive. Problem would be being able
to review/approve such a big change.

--strk;
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Issues ID mapping (was: Post github issues migration clean ups - some proposals)

Jürgen E. Fischer
In reply to this post by Jorge Gustavo Rocha
Hi Jorge,

On Thu, 30. May 2019 at 09:04:30 +0100, Jorge Gustavo Rocha wrote:
> I'm trying to find old Redmine issue references and replace then by the
> new ones, so everything points to the new ones. Commits messages are not
> easy to change, since the message itself is part of the commit.

> I've just made https://github.com/qgis/QGIS/pull/30014 to have all
> comments in code (and in tests) pointing only to GitHub.

I thought you were also going to investigate how to add a github comment to the
commits with a issue reference.  So visiting the commit on github would also
give you a pointer to the github without a history change.

BTW redmine now redirects commit links to the corresponding github page.
 

Jürgen

--
Jürgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
Dipl.-Inf. (FH)             Rheinstraße 13          Fax. +49-4931-918175-50
Software Engineer           D-26506 Norden            https://www.norbit.de
QGIS release manager (PSC)  Germany                    IRC: jef on FreeNode

norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Juergen Fischer, Nils Kutscher HR: Amtsgericht Aurich HRB 100827
Datenschutzerklaerung: https://www.norbit.de/83/

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

signature.asc (844 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issues ID mapping (was: Post github issues migration clean ups - some proposals)

Jürgen E. Fischer
In reply to this post by Sandro Santilli-4
Hi Sandro,

On Thu, 30. May 2019 at 09:36:52 +0200, Sandro Santilli wrote:
> You can see the commit log references #30003 issue number.
> Gitea was configured to transform that into a link to issues.qgis.org,
> but such link is a "not found" page:
>
>   https://issues.qgis.org/issues/30003

You can use https://issues.qgis.org/github/30003 now - that will take you to
the corresponding github ticket if there is a match or otherwise just the
github ticket with that number.


Jürgen

--
Jürgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
Dipl.-Inf. (FH)             Rheinstraße 13          Fax. +49-4931-918175-50
Software Engineer           D-26506 Norden            https://www.norbit.de
QGIS release manager (PSC)  Germany                    IRC: jef on FreeNode

norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Juergen Fischer, Nils Kutscher HR: Amtsgericht Aurich HRB 100827
Datenschutzerklaerung: https://www.norbit.de/83/

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

signature.asc (844 bytes) Download Attachment
12