On Thu, Dec 7, 2017 at 2:36 PM Carlos Soriano <csori...@gnome.org> wrote:
> Hey Michael,
>
> On Thu, Dec 7, 2017 at 9:04 PM, Michael Catanzaro <mcatanz...@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 admire Carlos' restraint here but I'm going to say it more bluntly: in my
opinion, it is unfair to expect that any individual person's opinion on
their preferred must-haves should be able to block the migration from
moving forward. This is part of the monumental job Carlos has been doing:
gathering everyone's requirements, evaluating them, checking the
feasibility with GitLab, and deciding which ones are blockers for GNOME _as
a whole_ before we move the migration forward. By demanding that your
personal blockers take precedence, you are undermining Carlos' hard work
and the balancing act he has to perform to get this to happen at all. It's
impossible for him to make everyone happy and I think he's done a fine job
of representing different perspectives, I dare say even ones that he
doesn't agree with. We need to trust that he is including all the factors
and making the right decision.
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.
>
I have to think "I hate Bugzilla" every time I use Bugzilla, but that
didn't seem to bother anybody. I became a GNOME maintainer 395 days ago and
have had to deal with Bugzilla for most of those days, so let's say 500
times I SMHd including patches that I filed before I became a maintainer. I
even _used Google Chrome as my primary browser_ because it was the only
browser that had an extension that would turn Bugzilla bugs into Trello
cards which I found easier to deal with. Michael, I don't mean to single
you out, this is just an example, but If you think "I hate GitLab" every
other time you close a bug, then you will have to close 1000 bugs before
you approach my level of Bugzilla-rage.
Coming from GitHub, Bugzilla was like regressing to the stone age. If I
were to insist that my opinion take precedence in the same way that has
happened multiple times on this thread, I'd demand that all activity on
Bugzilla cease immediately. I don't think that would be very fair for me to
do either.
>
>>
>> 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.
>
I said earlier in this thread that I am already getting more contributors
to GJS just _showing up and doing stuff_ since it's been on GitLab. Even
since I wrote that, another one just showed up out of the blue and
volunteered to overhaul the wiki. Maybe a coincidence... or maybe anecdotal
evidence of my theory that Bugzilla is scaring away potential contributors
every day :-) Surely one can highlight some text and press 'R', or copy and
paste a canned response a few times, in order to allow the contributors to
flood in?
Regards,
Philip C
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
