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

[Jorge Gustavo Rocha]

Hi all,

Tim's proposal seems a interesting compromise.

We keeping the redmine active to support 2.x version and we start a new
development workflow for 3.x. based on git[hub|lab].
As Paolo, Nyall and other pointed out, we will have some noise regarding
duplication of issues, out of sync issues (closed for 3.x but not for
2.x), etc, but after a while, issues will became much more integrated
and traceable on top of a git based platform. We must remember that
redmine issues are working well because there are developers taking care
of the issues, tagging, etc. There is a lot of human effort on top of
redmine issues.

Another nice thing in Tim's proposal is to avoid (more than one)
disruptive changes. I would prefer to move to gitlab. But to keep the
process less disruptive, we can continue in github for now. Regarding
Paolo concern about lock in, we can switch from github to gitlab more
easily if necessary.

After this discussion about the development workflow, I would prefer to
start another "disruptive" change and move from Transifex to Weblate.
End users are blaming about translations. Free version of Transifex does
not allow translators to use more sophisticated tools to support the
process, as Alexandre and others said recently. That's a major issue
bothering both end users and translators we need to solve.

As Heraclitus said (a former developer from Ancient Greece Inc.) "The
Only Thing That Is Constant Is Change". That’s what we have in QGIS :-)

See you all in Madeira, within a month!

On 18-01-2018 09:39, Paolo Cavallini wrote:
> Hi all,
> 
> Il 18/01/2018 00:07, Nyall Dawson ha scritto:
>> On 18 January 2018 at 08:06, Tim Sutton <tim at kartoza.com> wrote:
>>
>>> 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.
>>
>> I'm a bit unclear where 2.18 fits in - would Redmine be open for new
>> 2.18 bugs? Or would they be reported on github?
> 
> to clarify:
> * I'm not neutral: I'm in favour of any system user find useful,
> *provided* we don't miss the history; this is a blocker for me
> * I would prefer a 100% free solution, and to to get stuck with a
> proprietary one; this is not a blocker for me, but I wuold advise having
> a reasonably way out, to avoid being locked in; this is a strategic, not
> an ethical reason
> * I'm not 100% sure "normal" people will find GH much easier than
> redmine. we obviously have a bieased, non representative opinion on
> this; perhaps better asking among regular user; I'm doing this in
> qgis-it, I suggest to do the same for other QUGs
> * I find interesting the idea of leaving Redmine for the 2 series, and
> starting afresh with GH for 3; however, I'm really worried that this
> will cause a lot of entropy, with users being confused on what to do,
> duplicated tickets in both systems, etc.; e.g. an old ticket, from 2, is
> fixed in 3, but not 2: should we leave it open in Redmine? I can see a
> number of such puzzling cases.
> All the best.
> 

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