[QGIS-Developer] Last call for switching to github issue tracker

[Tim Sutton]

Hi



> On 17 Jan 2018, at 19:35, chris marx <chrismarx at gmail.com> wrote:
> 
> Another vote to move to git*, people may want to defend redmine, but it's just not friendly for new users to come in and get engaged. And I realize that QGIS may not want this, but I think it's a big user satisfaction win if we could upvote issues-

I cant speak for everyone, but I can guess that most people don't really care about Redmine specifically, they just care about the information it contains.

More below….


> 
> On Wed, Jan 17, 2018 at 8:34 AM, Denis Rouzaud <denis.rouzaud at gmail.com <mailto:denis.rouzaud at gmail.com>> wrote:
> Hi all,
> 
> I'd like to move on a bit the discussion.
> 
> I'll try to summarize (and to be fair and honest):
> 
> * The desire to switch to Github is strong
> 1 against: Sandro
> 5 neutral (or did not pronounce): Jürgen, Andreas, Richard, Paolo, Nyall
> 9 for: Borys, Matthias, Tom, Jorge, Régis, Bernard (says Redmine sucks), Loic, Tisharm and myself

Is that Tom or Tim? For the record in an ideal world I would like to be on GitHub too….

> 
> * But among those who spoke. I was hoping for a broader response.
> 
> * I think we shouldn't mix switching to github (for technical reason) with switching to gitlab or so (for ethical reason). My original call was mainly for technical reasons and I believe, the end-users should decide on this.
> 
> * As stated, ethical reason should rely on the PSC. Feel free to call for it.
> 
> * I believe that we should first decide on what to do and next find the technical (and financial) solutions. And not the other way around.
> 
> * Jorge volunteered to work on the topic.
> 
> Additional **personal** notes:
> 
> * I would be against moving all issues to github. That doesn't mean losing our history: let's just keep redmine online but locked. This has to be discussed and decided after deciding to move to github.
> 
> * Another upcoming issue we HAVE to take care of: soon the PR number in GH will catch up with the issue number in Redmine....so bugfix commits will link to an unrelated PR... Keeping things untouched by fear of losing history is a suicide!
> 
> 
> Can we make a decision, and in this order:
> 1. decide to move (but to be applied if following questions are made possible)
> 2. what/when to move (empty list or everything or open issues, before the release, etc.)
> 3. how to move (volunteer, grant proposal, etc)
> 
> And if we realize the decision is not feasible: we start again the procedure by stating we cannot do it. 
> It would be useless to spend hours on trying to migrate the issues if we decide to start with an empty list -- just to illustrate.
> 
> What is next?
> A loomio vote for this?

So I would suggest raising a vote on the motion:

“We should adopt GitHub issues for reporting issues in 3.0 and restrict Redmine for the management of issues in QGIS 2.x”.

After there are no more active 2.x releases, we make the Redmine tracker read only and keep it around as an archive. We could put into the GitHub issue template: “Only use this tracker for 3.x related issues” and similar message on Redmine indicating that it should only be used for 2.x issues. It will unfortunately leave us in the position where you need to check to issue trackers for your issue which is going to suck a bit.

Regards

Tim
—







Tim Sutton

Co-founder: Kartoza
Project chair: QGIS.org

Visit http://kartoza.com <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20180118/0456bbc2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KartozaNewLogoThumbnail.jpg
Type: image/jpeg
Size: 6122 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20180118/0456bbc2/attachment-0001.jpg>