Re: [QGIS-Developer] Post github issues migration clean ups - some proposals
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 a écrit : > Hi all, > > May I also suggest to create a "wontfix" label? > > Le dim. 26 mai 2019 à 21:46, Denis Rouzaud a > écrit : > >> >> >> Le dim. 26 mai 2019 à 21:38, Nyall Dawson a >> écrit : >> >>> On Mon, 27 May 2019 at 11:43, Denis Rouzaud >>> 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 >>> >> 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 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
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 ___ 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
Hi all, May I also suggest to create a "wontfix" label? Le dim. 26 mai 2019 à 21:46, Denis Rouzaud a écrit : > > > Le dim. 26 mai 2019 à 21:38, Nyall Dawson a > écrit : > >> On Mon, 27 May 2019 at 11:43, Denis Rouzaud >> 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 >> >> 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
Le dim. 26 mai 2019 à 21:38, Nyall Dawson a écrit : > On Mon, 27 May 2019 at 11:43, Denis Rouzaud > 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 > >> 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
On Mon, 27 May 2019 at 11:43, Denis Rouzaud 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 >> 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
Hi Nyall, I generally completely agree with all the points you raised, some comments below Le dim. 26 mai 2019 à 18: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! > > 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 > 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] qgis_editor_widget_styles table, what is it ? How to create it?
On Sun, 26 May 2019 at 01:48, Régis Haubourg wrote: > > Hi, Thanks Nyall for the hints. > > I'm considering switching to this query instead. > SELECT * FROM pg_class WHERE relname='qgis_editor_widget_styles' > > In my setup it access only to one table and uses internal indexes, when the > information_schema.tables is a view that involve a materialized query here > when using explain. > I don't see a significant difference on my local setup, I'll test it on our > customer setup before starting my (first) PR! I think this could be potentially further optimised (e.g. with a "LIMIT 1"), but I'd see how this goes on the troublesome setup first... no point over-optimising if your query fixes the issue. Nyall > > Cheers > Régis > > Le sam. 25 mai 2019 à 05:33, Nyall Dawson a écrit : >> >> On Fri, 24 May 2019 at 18:25, Régis Haubourg >> wrote: >> > >> > Hi all, >> > I'm facing very slow opening of project files for a customer here in QGIS >> > 3.4.5. Something like 7 minutes, against 30 s in QGIS 2.18. >> > >> > We are still investigating to narrow it down, but I faced a first query in >> > the logs that I fail to understand. >> > >> > QGIS emits this at a point: >> >> > >> > And this query is long in our context, 1.7s, because of a very high number >> > of tables and schemas in that production DB. >> > >> > I found at [0] in the postgres provider where it comes from, I found the >> > associated PR [1], but I fail to understand in what workflow this table is >> > created using QGIS, and what it is used for. >> > >> > Can someone put some light here ? >> >> There's a unit test at >> >> https://github.com/qgis/QGIS/pull/3439/files#diff-99b101819133a316786604243f3abf6eR318 >> >> and >> >> https://github.com/qgis/QGIS/pull/3439/files#diff-03e6d7f6f76fb4bcab508984d0fd05f6R443 >> >> which partially explains this -- it looks like it's a way to specify a >> default editor widget configuration for a table, which is used >> whenever that table is loaded into QGIS. >> >> > >> > select count(*) >> > >> > from information_schema.tables >> > >> > where table_name = 'qgis_editor_widget_styles' ; >> > >> >> Looks like that query could be substantially improved -- it's only >> testing for existence of the table, so calculating the count is >> inefficient and requiring a whole table scan. >> >> 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
[QGIS-Developer] Post github issues migration clean ups - some proposals
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 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] Call for Grant Proposals 2019
Dear devs, This is a reminder that there is only one week left to this year's proposal deadline. Regards, Anita On Mon, May 6, 2019 at 9:22 PM Anita Graser wrote: > Dear QGIS Community > > Our first three rounds of Grant Proposals were a great success. We are > very pleased to announce the fourth round of grants is now available to > QGIS contributors. > > Please read the QGIS.ORG blog post for details: > > http://blog.qgis.org/2019/05/06/qgis-grants-4-call-for-grant-proposals-2019/ > > Regards, > Anita Graser > ___ 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] [GSoC 2019 - QGIS 3D Improvement] Community Bonding Period Report
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 * [4] https://lists.osgeo.org/pipermail/soc/2019-May/004241.html * [5] https://learnopengl.com/ * [6] https://github.com/ismailsunni/qt3d-hello-world * [7] https://doc.qt.io/archives/qt-4.8/qdial.html * [8] https://github.com/ismailsunni/QGIS/issues/1 * [9] https://github.com/ismailsunni/QGIS/wiki/GSoC-2019---QGIS-3D-Improvement -- Ismail Sunni ismailsunni.wordpress.com ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info:
Re: [QGIS-Developer] github tickets authorship
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 -- 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] github tickets authorship
Hi Sandro, On Sun, 26. May 2019 at 15:11:18 +0200, Sandro Santilli wrote: > That's not good. So I reverted to query the read-only Redmine, to find > any open ticket in my name. I found https://issues.qgis.org/issues/17934 > but if I wanted to close it now I'd have to do it in github, but > there's no link from readmine to github in each ticket... Yes, not yet. But you can search for "Original Redmine Issue: 17934" in github for now, but a back link to original ticket is there. 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 Nordenhttps://www.norbit.de signature.asc Description: PGP signature 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 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
On Sun, May 26, 2019 at 02:47:34PM +0200, Jürgen E. Fischer wrote: > Hi Sandro, > > On Sun, 26. May 2019 at 14:27:56 +0200, Sandro Santilli wrote: > > 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 ? > > I think the migration could not impersonate authors. > > But you can look for "Author Name: Sandro Santilli", but that will also > show tickets you authored comments for. That's not good. So I reverted to query the read-only Redmine, to find any open ticket in my name. I found https://issues.qgis.org/issues/17934 but if I wanted to close it now I'd have to do it in github, but there's no link from readmine to github in each ticket... --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
Re: [QGIS-Developer] github tickets authorship
Hi Sandro,
On Sun, 26. May 2019 at 14:27:56 +0200, Sandro Santilli wrote:
> 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 ?
I think the migration could not impersonate authors.
But you can look for "Author Name: Sandro Santilli", but that will also
show tickets you authored comments for.
Apparently you cannot search for substrings either ("widget.value" or
"self.widget" will not find tickets with "self.widget.value" in them).
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 Nordenhttps://www.norbit.de
signature.asc
Description: PGP signature
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
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] github tickets authorship
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
Re: [QGIS-Developer] [Qgis-community-team] [Qgis-user] Redmine migration plan: friday 24 may 8:00 CET
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
