Date: prev next · Thread: first prev next last
2020 Archives by date, by thread · List index


William Gathoye (LibreOffice) kirjoitti 23.1.2020 klo 11.53:
On 23/01/2020 09:03, Ilmari Lauhakangas wrote:
Of course we are worried about Bugzilla, but there are steps being taken
to address the Mozilla/upstream fracture.

Yep, but if I was the one who decides, using a project that hasn't much
maintenance like it used to be is risky IMHO. We are a bit in a
situation like what we had with Pootle and we have now with AskBot, but
that's another topic. :)

It isn't lack of maintenance. This is a very specific case, where upstream and downstream diverged and are now being brought together. Of course everyone should take great care that this never happens again.

I believe GNOME's decision to drop Bugzilla was misinformed, same as
freedesktop.org's.

Discussing with some GNOME devs at last FOSDEM, they said to me they saw
a bunch of new contributions since the GitLab migration. I cannot
confirm, but I wouldn't be surprised either with all the feedback I
received about the BZ slowness and UX not friendliness, this is a
problem reported by "new-gen" contributors used to use GitHub, Jira and
all. :/

GNOME adopted GitLab as a solution for multiple different things. They could have kept Bugzilla while integrating it with GL, just like we do with Gerrit + BZ.

Overall I am rather puzzled by the inability of big FOSS projects to
collaborate on helping improve a crucial piece of infra they rely on and
instead dropping it for some shiny open core thing that ships something
kind of similar.

I'm joining your POV if there weren't alternative available *if missing
features are implemented*. :)

I don't want to see change and churn for its own sake.

At the last FOSDEM I also discussed with some GitLab guys, and they
would even be willing to put some people to help, like they did with
Debian and GNOME. KDE is in the evaluation process to migrating away
from Phabricator to GitLab as well[1].

KDE will not drop Bugzilla, though.

Some quotes from a recent discussion where KDE contributors weighed in:

https://news.ycombinator.com/item?id=21113175

"Gitlab's issues feature just isn't powerful enough to be more than a developer's task list. Since it's completely label based, it's hell to use when you've got bug reports coming in from non-contributors. Even classifying issues by OS needs to be done through labels..." (Krita lead dev)

"This is my problem currently with the move from Phabricator to Gitlab, we are losing tons of features: review approval, meta project (documentation, visual design group, promo, website, ...), mockups, meta tasks and more. And those features exist but only in the enterprise edition, that is not open source." (KDE dev & design contributor)

That's up to TDF to take decision knowing that in all changes you'll get
rejections. For these cases, two ways pipelining between BZ and GitLab
issue tracker is possible IMHO. And for what is worth mentioning the
experience can be started by replacing Redmine? :)

In my view, with the future Bugzilla update we could replace Redmine with Bugzilla.

I ask you to remain calm and wait for some time while we figure out this BZ situation. If you come to FOSDEM, I can tell you more on what I am doing to try and solve it.

Ilmari

--
To unsubscribe e-mail to: website+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.