Re: Fwd: Let's move on our bug tracking system and git repository

Hi again!

On Tue, Oct 25, 2016 at 4:09 PM, Abel <akronix5 gmail com> wrote:

At this point, I think I should enumerate mi personal frustrations with
bugzilla, as a very occasional contributor:

It's slow and tedious to search for bugs by products. I'd be easy if every
product had it's own folder or something like I could go to"something"


There's no online preview of patches.

What? Maybe that's why you don't like bugzilla, if you don't know its
features. :P
No idea how you miss this one though, since the *default* view
(clicking a patch from the message, giving a diff side-by-side view
with colors) of patches is an online preview!

Now don't get me wrong: gitlab and github have a nicer preview, and
much better review GUI (commenting individual lines of code, etc.).
But saying that bugzilla has none is not true.

The web site don't support diff between commits and branches.

cgit can show commit diffs and this is integrated in bugzilla (when
you write a commit hash in bugzilla, it links there directly). Now
maybe this diff has less features (I don't think you can diff against
any random branch, only against its own parent).

Interface is ugly and not intuitive. There's too much information and

A matter of taste, but bugzilla is old-school, yes. This said, as
Tobias said earlier, trend change fast on the web. What is a cool web
2.0 (or 3.0 or whatever!) GUI now may not be in a year.
This can still be a good reason. Appearing cool and fashionable is not
bad. But this should not be the principal reason for change (when this
change is deep and changes also the workflow at its core like here. Of
course, if it just gets a shiny new UI, this can be a very good reason
for change).

content in the bug page that standard contributors don't care about. There's
no colors to clearer show tags, status, milestones, etc.

Well bugzilla has all these and that's all very clear to me, just not
in a cool fashionable UI.

Not support for markdown or flavoured text.

There is actually some syntax support, but not as good as it could be.

There's a big barrier for newcomer contributors. I don't find easy and clear
the workflow to submit a patch and get it added to trunk. Many people
haven't ever used bugzilla and the interface don't help too much to get them
quickly started. I remember that someone (phisically) taught me how to get
to it.

Well that's where we disagree. The workflow is 1000x better on
bugzilla IMO. Now a lot of newer developers use github (once again
because it is the trend and because you hear stupid stuff as the fact
that a developer *must* have a github account as a public portfolio).
So they are used to this and think that this is how all workflows are
supposed to be.

Well as I said, the github workflow is terrible. Trying to reproduce
this just because some developers don't know better is a race to the
bottom. And I certainly don't want this. Our tools and workflows are
far from perfect either (even crappy in a lot of places) and I am all
in favor of improving them. But in the right direction.

In the end, this is all about the fact that some people are used to
something (and we to another). And I believe that even though some
parts of their tools are definitely an improvement, some others are

New features and integrations that bugzilla doesn't seem to ever have. For
instance: webhooks, mobile clients,... think of all the third party services
have integration with github, gitlab and so.

Bugzilla has an API, and therefore desktop clients, but also mobile
clients (never thought about this since I don't see the point of
editing bugzilla with my phone. But I just searched and found at least
5 mobile clients!). The best "clients" though are not GUI, but direct
git integration for instance with the git-bz tool.

I don't think Bugzilla has webhooks by default, but if we wanted to
give some users (maintainers of a project) such an ability, that
feature should be quite straightforward to code as a plugin. Most
things are much better done with git hooks (rather than plugging with
the bug tracker).

Separated git codebase from bug system, and from any other things that
concerns to gnome contributors (docs, bugzilla user, etc.)

All in one tools are good and bad in the same time. It makes us quite
dependent and is a problem when we want to use another tool (like
should we use the integrated gitlab wiki instead of the current one?
Do we really want to concentrate every usage into this single tool
even if features are missing compared to separate tools?).

And I think that more can be adding by people with more experience
developing in GNOME.

People with experience all have a lot more experience using various
tools (be it bugzilla and other bug trackers) and have no problems
switching from a tool to another.

I see that more and more open source development is happening on github and
people are more actively contributing. On the other hand, people get scared
when they want to collaborate with other open source projects like GNOME and
they see this git + bugzilla + patches system that they don't understand at
all. If not, why are there github mirrors for many gnome products and people
get and participate to them before to go to bugzilla? I've even heard that a
gnome maintainer requested that patches must be uploaded as a Pull Request
to the github mirror.

Personally I'd prefer these mirrors gone. We have no power on them
anyway so they are quite useless to us anyway.

It doesn't have to be gitlab, but I'd rather look for something visually
better, specially for people to easy get involved and improve GNOME. I've
heard good words of phabricator, for example.

I think the real problem is what you point at: yes bugzilla is an old
tool, not that visually-appealing. This is to be taken into
consideration but not at a feature-loss and workflow-loss.

Ok, yes, I recognize that it requires some effort to move to something
different, specially to move bugs and bind integrations. But we have to
assume that some effort will have to be putted into this at some point or
we're gonna be stuck on bugzilla until the end of the days?

I'm all for moving forward to something modern and appealing!

I'd just prefer it is not a github clone. At least not on the
particular parts which makes the workflow (all the fork crap).
Better code viewing and reviewing, and all this stuff, yes, 100x
times. Forks and pull requests for every contribution? No!

This said, I likely won't be the one to make the migration work, so I
am only giving an opinion here and will have to agree with whoever
does the actual work here. I would accept to work with a gitlab UI of
course and that would not stop me from contributing. I still want to
say that I would not like it. :P

Anyway sorry for the noise.


Because I feel If we want that GNOME would be a more participative and
active project, we have to ever change this. And if so, the sooner we do it,
the better.



ZeMarmot open animation film

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]