#1

Things like missing stuff. For example I opened this:
https://pagure.io/fedora-workstation/issue/80

That im quite sure it is the wrong place to open it. Then i found this:
https://pagure.io/fedora-silverblue/issues

But it looks like dead

#2

You can open issue at https://pagure.io/teamsilverblue/issues

1 Like
#3

Sorry, that’s my doing - I opened fedora-silverblue just a few weeks ago in the hopes of using that as issue tracker but it would need an announcement and I’d need to move over all the issues as renaming on Pagure isn’t possible. So yes, what @pnemade said. I didn’t want to move things over in case we decided on something else overall.

I’ll leave both in there now until the discussion whether we’re migrating to Gitlab is completed, for reference see https://twitter.com/BabyWogue/status/1049239495525195777 and all subsequent replies in that thread. We should bring this up at the next IRC meeting. If we don’t move to Gitlab, I suggest one of the biggest points should be to make it possible to file issues directly from desktop (as mentioned on the Twitter thread).

1 Like
#4

Who’s the “we” in the discussion of “we’re migrating to GitLab?” And what is the migration - to the public GitLab.com or to a Fedora / Red Hat hosted enterprise instance?

#5

The “we” means we’ll take up the discussion on IRC at the next Silverblue meeting and the current people within the Twitter thread - can also continue it here. We’ll definitely address it on IRC.

At the same time, there are some merits to keeping it on Pagure as discussed on Twitter. In any case, being able to file issues directly from the desktop seems a safe bet. We’d just have to discuss how to file them - anonymous? By providing a FAS login?

#6

I’m curious why Silverblue chose to have a separate issue tracker from the Red Hat Bugzilla site that everything else in the Red Hat / Fedora family. I’m used to finding Fedora bugs, searching Bugzilla for them, opening new ones, troubleshooting, etc. Wouldn’t it be simpler for everyone to just add Silverblue as a product to Bugzilla?

#7

I’m not affiliated with Fedora, but IMO Bugzilla is a bit of a disaster from a usability standpoint. I know that even GitHub has a better layout and search system (not sure about Pragure in particular).

Also, many other projects are moving off Bugzilla (freedesktop.org and GNOME moved to GitLab, systemd moved to GitHub, etc).

1 Like
#8

Nice! I love GitLab!

3 Likes
#9

I tried most of the tools and also liked GitLab most (event set it up for a client). But in the end, it depends on what do “we” :slight_smile: want and do we have time to switch to another tool at this point when there is a lot of other probably more important issues to be dealt with.

  • if automatic bug posting is on the roadmap for SB, how important is the tool used?
2 Likes
#10

Personally, I’d prefer Gitlab as well (the hosted one). It’s open source and they make money with it, so it’s improved steadily with way more resources than Fedora can put into improving Pagure.

Plus, I believe the networks effect will come and there are some big projects on it already.

2 Likes
#11

pagure.io is used extensively for issue tracking for the Fedora project - infrastructure, release engineering, documentation, etc. The only thing that’s really in Bugzilla at this point is bug reports about packages (which is of course, not a small thing!) The ability to just create a project in pagure.io and start tracking issues there is likely one big reason for this, but the experience is also better - better performance, easier browsing, rich formatting, etc.

I’m personally not in favor of using gitlab for Silverblue - yes, gitlab is probably better in various ways, but as an occasional user of the GNOME instance of gitlab, and a fairly heavy user of github, pagure.io seems to largely be good enough - I don’t usually get annoyed by it. And issues that are truly Silverblue-specific issues at the engineering or infrastructure level are going to be few and far between - cooperation with the rest of Fedora is essential.

1 Like
#12

Hello Owen,
If someone will use SB and I hope/believe many will in the short feature, they will open issues on SB bug trackers, even if it is something that affects Fedora or even RPM-OSTree and OSTree. So I don’t feel that "truly Silverblue-specific issues" is very relevant, at least for users like my self, and more

Since Github isn’t a choice, between Pagure and Gitlab I will go with Gitlab, first because it has more features and a better interface, and also because Gitlab is something with good chances someone is using already for other projects (familiarity factor), where that’s hardly the case with Pagure outside Fedora community. It reminds me a bit Canonical LP, which is like “what is that?”

#13

My perspective is as a user / tester. I file bugs and if I know enough to troubleshoot / fix them, I’ll hack on things a bit and gather info. So it doesn’t matter to me whether I file in Bugzilla, Pagure or GitLab. What does matter is whether or not I can get connected with the person who can figure out what’s broken, hopefully with my help.

From that point of view, there are serious problems with Bugzilla due to the size of its database and the number of products it covers. It’s kind of a flawed roach motel - the bugs go in but instead of dying of starvation, they sit there for many releases. They’re sometimes upstream, which may never get acknowledged. They’re often duplicates, the package that demonstrates the symptom may not be the package that’s actually broken, etc.

Given that I’m only minimally interested in Fedora outside of Silverblue, having a separate bug tracker for Silverblue seems like a win, and bonus points for it being easier to use than Bugzilla. On the other hand, maybe I’m hopelessly optimistic, but this strikes me as an opportunity for an artificial intelligence tool that we wouldn’t have if Silverblue had it’s own bug tracker outside of Bugzilla, since nearly all of its components are covered by Bugzilla. There’s a reason people search Google when they get an error message. :wink:

#14

Going on Gitlab will just make this project a bigger mess. Someone should try to reduce entropy rather than increasing it.

1 Like
#15

Yeah - either stay where we are or bite the bullet and jump head first into Red Hat Bugzilla. :wink:

#16

Well, RH bugzilla is what the security team use too, and they do have scripts they are likely not keen on rewriting to add 1 single exception, for example. What is the plan for that ? (and if the answer is “we would still be using bugzilla for report for packages”, well, surprise, that mean that we would be using bugzilla and something else, so get the worst of both world…)