Re: GitLab update: Moving to the next step

[Carlos Soriano <csoriano gnome org>]

Hey Michael,

On Thu, Dec 7, 2017 at 9:04 PM, Michael Catanzaro <mcatanzaro gnome org> wrote:

I've been rewriting this email again and again to try not to be too impolitic... and I don't think I've succeeded, but I want to try to express the importance to me of some of the missing issue tracker features.

I'm pretty sure you succeed, appreciated you spent the time to not be over the top.

 

On 12/07/2017 12:07 PM, Carlos Soriano wrote:

Said that, add your comments about specific improvements to issue #8
too in a new comment so we can track them.

It looks like everything I care about is actually already tracked there in issue #8. (Except that the quote button needs to work like 'r'... good to know about the 'r' shortcut, I can live with that.) Looking over #8, I think duplicate issues, canned replies, and dependencies between issues should all be considered blockers to issue tracker migration. 

I assume I don't need to explain why tracking duplicate issues is important. Just look at the state of the closed issues in gnome-calendar's issue tracker right now.

I understand the importance of this, and we discussed them in the past. We have discussed also with the people trying GitLab, and the balance keep being positive. I agree better UI experience for duplicates is something we should see in the near future, but I think the general consensus is that we can move forward without it and eventually have a better experience.

 

I use a long canned reply to close probably half the bugs I receive ("here is how you report a WebKit bug..."), and bug management would be extremely frustrating without it. I could keep it in a text file and copy/paste for a couple months, as long as upstream has promised the feature is on the way. But I really would rather stay on Bugzilla forever rather than give up canned replies forever. I am going to be thinking "I hate GitLab" every other time I close a bug... we don't want that.

Like everything, it's a balance. I hope you see as you hate GitLab there are others that hate Bugzilla, including most of new contributors. It's impossible to make everyone happy with such a change, but I hope you trust me when I say that I didn't take any steps on this lightly, and that I tried to take a representation of the whole community. In no moment I though about myself when taking these decisions, and I went far beyond the possible to try to make sure we are taking the best decision for GNOME and that our community agrees with that decision.

 

And I would also insist on a schedule for open sourcing dependencies between issues. That such an important feature is being kept closed source indicates we are going to have further problems collaborating with upstream down the road. We should be prepared to stay with Bugzilla indefinitely if GitLab remains unwilling to open source basic issue tracker functionality.

We cannot rely on that, and to be honest, with the UI and markdown of GitLab I didn't miss it so far. Probably others can chime in, but even if it will be preferred to have, we can do fine without.

Note that I also explained few times this and it's written in our transition wiki: We evaluated the current state and we defined our blockers based on that. To be honest I'm more than happy if over time half of the issues we have in that list are improved/fixed, and some of them have people working on them already.

 

The big picture that I see is that GitLab has some cool features, and some people really want merge requests... I don't really care either way, but OK, fine by me. But I spend a *lot* of time working with Bugzilla, and losing basic issue tracking features is going to make my job as a GNOME maintainer harder. So when it comes time for all the remaining projects to move to GitLab, if the above deficiencies are not resolved, then I hope that we'll be allowed to turn off GitLab's issue tracker and stick with Bugzilla. Maybe it would be better to make that the default transition, in fact.

Again, it's very difficult to make everyone happy, and of course there are always trade offs that we have taken into account on the whole path until today. But I hope you understand, eventually we will have to move forward, we cannot indefinitely stay with two issue trackers, and it's also going to be quite impractical even for you.

What I can do here is trying to push for some changes to make your utter unhappiness to "it's okaish", because I believe it will be hard for you to be happy with GitLab, at least until you get used to it. In the same way lot of us feel with Bugzilla or any other tool that we could have evaluated.