Re: Invent/gitlab, issues and bugzilla
On 07/03/19 07:31, Jean-Baptiste Mardelle wrote: Having used gitlab issues quiet a lot in the last months for Kdenlive, I think it would be sad to completely disable them. Making them accessible to project members/developers only seems like a good compromise. I like to use them as a development coordination tool, and for us it's a good replacement for phabricator's boards. I also find them more intuitive to use than phabricator, referencing an issue in a commit is as simple as putting #issue_number, while I never manage to reference or close phabricator tasks/diffs from commit messages despite checking the online doc (but that's probably my fault so not a real argument)... Do our hook recognize a keyword to automatically close github issues? It would be nice if developers used a standard notation that is parsable by our scripts for automated change logs. -- Christoph Feck KDE Bug Triaging Team
Re: Invent/gitlab, issues and bugzilla
On Tue, Jul 02, 2019 at 11:09:41PM +0200, Albert Astals Cid wrote: > That makes no sense, we incubated projects before we were on gitlab, saying > "oh no, if people can't use gitlab issues the incubation will collapse" is a > bit alarmist IMGO Not my point at all, I am not saying Gitlab issues would be cause which makes the incubation fail. I am saying that if we continue with such twisted policy which denies access to service A already present because service B is used by rest of community is what will make incubation fail. To expand, What I am saying is, - KDE Incubates a project - We have a two differet things for some thing, let's take example of build.kde.org and Gitlab CI. - We introduce a rule that people can't use Gitlab CI despite being there and force them to use build.kde.org That kind of rules are not getting us anywhere. If it was case of someone using Travis CI instead of build.kde.org, we can ask them to not use it or enforce it. But if both services are hosted on KDE infrastructure, requires no further maintainence or other KDE contributors are able to access the service, just because one piece of software is broken or requires change (drkonqi) denying projects use of Gitlab Issues is not a good idea. Projects come to KDE because they find our community attractive, in hope that they get more contributors, but if we want to stick with some old infrastructure, and actively deny them usage of something new, then they better be on infrastructre outside of KDE. Thanks -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Invent/gitlab, issues and bugzilla
On woensdag 3 juli 2019 20:23:41 CEST Nate Graham wrote: > On 7/3/19 11:53 AM, Albert Astals Cid wrote: > > If the new is much better than the old, let's just remove the old. > > > > As said, having two things that do the same is just confusing for everyone. > > I would tend to agree, and having two is super confusing. But are they the same things? I need both user reports and developer tasks/projects. The only task-like system github offers is the issues system, isn't it? > In general, > people who have reported bugs on both Bugzilla and GitHub or GitLab seem > to agree that Bugzilla's UX is inferior. However I don't believe we've > officially trialed GitLab Issues and investigated what missing features > need to be added before we can migrate to it. Maybe the time to do that > is now, as a part of the general GitLab evaluation and migration period. Besides, it's already too easy to make a bug report. Getting more bug reports is not a priority for me; at this I would prefer to have less interaction between developers and users than more, because we're going crazy right now. We did try out the ask.krita.org site to mitigate the flood of user support requests, but that software didn't have the tools to handle user support properly (being more like a stackoverflow clone), so we canned that. > Personally I find GitLab Issues to offer a vastly superior UX for bug > reporting compared to Bugzilla. However the UX for bug management and > triaging is not as granular. And that's the important thing. Bugzilla is a developer tool, not a user tool. We must have easy tools to triage, query, sort, modify sets of reports. Bugzilla isn't perfect for that either, but the options gitlab gives for handling issues are so limited. > For example I still haven't figured out a > way to create a saved search for "all Issues opened in the last 24 hours > across all projects". And it would be nice to have some kind of overview > similar to https://bugs.kde.org/weekly-bug-summary.cgi. Actually, weekly-bug-summary is currently my main management tool :-) -- https://www.krita.org signature.asc Description: This is a digitally signed message part.
Re: Invent/gitlab, issues and bugzilla
Boudewijn Rempt ha scritto: > On woensdag 3 juli 2019 20:23:41 CEST Nate Graham wrote: >> On 7/3/19 11:53 AM, Albert Astals Cid wrote: >>> If the new is much better than the old, let's just remove the old. >>> >>> As said, having two things that do the same is just confusing for everyone. >> >> I would tend to agree, and having two is super confusing. > > But are they the same things? I need both user reports and developer > tasks/projects. The only task-like system github offers is the issues system, > isn't it? Yes, but my point is that gitlab issues have been used also for bugs so far. -- Luigi
Re: Invent/gitlab, issues and bugzilla
On 7/3/19 9:05 PM, Luigi Toscano wrote: > Boudewijn Rempt ha scritto: >> On woensdag 3 juli 2019 20:23:41 CEST Nate Graham wrote: >>> On 7/3/19 11:53 AM, Albert Astals Cid wrote: If the new is much better than the old, let's just remove the old. As said, having two things that do the same is just confusing for everyone. >>> >>> I would tend to agree, and having two is super confusing. >> >> But are they the same things? I need both user reports and developer >> tasks/projects. The only task-like system github offers is the issues >> system, isn't it? > > Yes, but my point is that gitlab issues have been used also for bugs so far. It seems like we all agree on the problem (different KDE projects using different tools for bug reporting by users), but not on your proposed solution (disabling issues in GitLab completely) since that would affect our use of GitLab Issues for internal issue / task tracking. So, proposed alternative solution: We make sure that all projects that want a public-facing bug tracker have a product on bugzilla, and that they communicate that as the only bug tracker to users for the time being. Then we can still use GitLab Issues for internal purposes. And evaluating whether we want to switch over to GitLab Issues for public-facing bug tracking eventually would be an independent discussion. Would that work? Cheers, Thomas
Re: Invent/gitlab, issues and bugzilla
> So, proposed alternative solution: We make sure that all projects that > want a public-facing bug tracker have a product on bugzilla, and that > they communicate that as the only bug tracker to users for the time being. > Would that work? Probably not. 1. As Nate points out, the bugzilla UX isn't very friendly to *users*, but is superior for *maintainers*. The concept of "bug" isn't a thing to most people. It is a thing only to older software developers and older users. People have "problems", "issues", "ideas" or "opinions". *They*, as humans, (hopefully), don't have bugs. 2. As Bhushan points out, it is important for incubation of new projects. I disagree with Albert on this. "New" developers consider a well integrated VCS + CI + Issue + Patch (or and pull requests) system to be the bare minimum of a "good practice" software development process. Bugzilla+Jenkins+Phab+Git/SVN+Mailing_lists are loosely integrated. From an Unix point of view, they are different things that do one thing and do it well. However, from a continuous delivery pipeline point of view, this is a problem. Tracking a change from its request (bug report / issue) to its presence on users systems (store.kde.org / Plasma discover / Neon) and then the feedbacks (telemetry, drkonqi) should be unified and "bot/tools friendly". With enough effort, we could find a way to better integrate them. However "find a way" is currently "complain Ben and wait". I think he has enough on his shoulder already, so I assume if we never found the resource to better integrate our components over the year, it wont magically become a reality tomorrow, or ever. Phab had some integration, but not much compared to mature (with dev processes) projects on GitHub or GitLab. 3. This should also not require external tools. As Boudewijn points out in the "Tipping the apple cart?" thread, new users don't install Arcanist and it isn't even part of many distributions (or they are scarred of installing PHP, or they don't know about it). This goes against the onboarding goals since it makes development experience for new users inferior to power users by a large margin. Plus, people who learn software development *now* learn the Agile and GitHub workflow as the "good practice" and in the same way the older generation learnt OOP+MVC+SVN or SOA as they "modern way". The worst case is currently Ubuntu, where, at least recently, it wasn't possible to report a bug without using Ubuntu (the OS) because the buttons were removed from Launchpad. So an Ubuntu server or some user "technical friend" could literally not report problems. This is user and new-developer hostile. Bugzilla doesn't require external tools per se, but requires to interact with different systems. 4. Again as Boudewijn points out, a bug tracker is often the wrong tool. Many users genuinely don't see a difference between interrogations about how to use a software, a problem with the software and a review. As the product becomes more popular with the "general crowd" rather than "geeks", the problem is amplified to the point Bugzilla becomes a liability. Given those 4 points, I think it is clear that Bugzilla as an endpoint for all problems, bugs and project management is clearly an horrible idea going forward. * It isn't good for non technical users because well, it isn't for them. * It isn't good for projects who wish to become part of KDE because they see this as an outdated workflow lacking tight pipeline integration. * It doesn't scale to more popular projects because what they need is a ticket system in front of the "real" issues to avoid large volume or non-bug "spam" shadowing the real bugs. * It doesn't work (well) for potential new contributors who have a patch for their bug because they need to go though 2 different systems and they wont. * It is not bad with bots, but it is definitely harder to integrate bots with 5 different project rather than 1 with a real API "just for that". * DrKonqi not being able to talk to GitLab is a technological issue on our side that favors bugzilla for legacy reasons. Something like a Cannonical Apport middleware would help. GitLab isn't perfect and is too large to be under control. It may die, sold or go into directions we cannot accept. In 5 years it may be a problem and blah, blah blah. This was discussed before and a decision was made. However the idea of rejecting half of what makes GitLab good in order to unify everything under the Bugzilla umbrella is in my opinion short signed and classical resistance to changes. Sorry if this feels a bit harsh. I agree that we need to discuss this here and now rather than as a separate discussion "in the future". On Wed, 3 Jul 2019 at 16:46, Thomas Pfeiffer wrote: > > On 7/3/19 9:05 PM, Luigi Toscano wrote: > > Boudewijn Rempt ha scritto: > >> On woensdag 3 juli 2019 20:23:41 CEST Nate Graham wrote: > >>> On 7/3/19 11:53 AM, Albert Astals Cid wrote: > If the new is much better than the old, let's just remove the
Re: Invent/gitlab, issues and bugzilla
Nate Graham kirjoitti 3.7.2019 klo 21.23: On 7/3/19 11:53 AM, Albert Astals Cid wrote: If the new is much better than the old, let's just remove the old. As said, having two things that do the same is just confusing for everyone. I would tend to agree, and having two is super confusing. In general, people who have reported bugs on both Bugzilla and GitHub or GitLab seem to agree that Bugzilla's UX is inferior. However I don't believe we've officially trialed GitLab Issues and investigated what missing features need to be added before we can migrate to it. Maybe the time to do that is now, as a part of the general GitLab evaluation and migration period. Personally I find GitLab Issues to offer a vastly superior UX for bug reporting compared to Bugzilla. However the UX for bug management and triaging is not as granular. For example I still haven't figured out a way to create a saved search for "all Issues opened in the last 24 hours across all projects". And it would be nice to have some kind of overview similar to https://bugs.kde.org/weekly-bug-summary.cgi. The upcoming Bugzilla version 6 will have a vastly superior UX to BZ 5: https://github.com/bugzilla/bugzilla-ux/wiki/Bugzilla-6-Roadmap With support from the BZ team, Kohei Yoshino has essentially solved BZ UX (this includes drafting plans for the future) and I am immensely grateful to him. The underlying functionality will remain superior to GitLabs and hubs as it has been for years. Ilmari
