No read-only archives and search functionality for bugzilla.gnome.org?

Community
,
1

I would like to access the archives of the gedit bugs and feature requests on bugzilla.gnome.org.

Where is the read-only archive? How can I get the list of all gedit tickets? Browsing them by category, searching them, etc.

When I go to bugzilla.gnome.org, there is no links to the different products, the search feature is gone, it’s almost an empty page.

When migrating to GitLab, we were told that the bugzilla would be still available in read-only mode. That isn’t really true.

What currently works is if you have a URL to a specific ticket. The read-only page is there. But the use-cases I described above don’t work.

I discuss this here because I’m a bit worried about the impact that it has. It means that when doing migrations for the community, some promises are done and then several years later community members see that it was just words in the air.

This contributes to the churn rate for long-time contributors like me.

2

The site was converted to static HTML pages. I take it so that bugzilla could be decommissioned.

The site can be searched with internet search engines, using a query like this to only show results from bugzilla: site:https://bugzilla.gnome.org gedit. Add some search terms to find relevant bugs.

If that doesn’t do it for you I guess you could clone the static HTML repository and search it locally or build an index of relevant bugs.

2 Likes
3

In defense of the devops team, keeping old infrastructure around in a not-really-decommissioned state is a huge pain. Think of Bugzilla…

  • needs a Perl installation.
  • needs its own database.
  • It was the version of Bugzilla available back then. Do you want to keep old network-facing software up?

We cannot just accrete everything that was available in the past; at some point one needs to clean house and discard old stuff. We did go through a careful process of writing our own importer from Bugzilla to GitLab, which worked much better than whatever was available at the time.

2 Likes
4

Actually that works quite well, the <body> HTML tag for each ticket looks like this:

<body class="bugzilla-gnome-org bz_bug bz_status_RESOLVED bz_product_gedit bz_component_general [...]">

So a command like git grep -l bz_product_gedit gives me the list.

Thanks for the link!

5

I understand.

Migrations like this will still happen in the future for other stuff, so the same kind of problems will arise, tradeoffs will need to be chosen. Good communication and what the community can expect is key.

With a lot of community members, some people will understand things differently. “read-only archive” can mean many things. I don’t remember exactly what was said about bugzilla being archived, but apparently I had a different expectation.

It’s a lot of data, so I expected it to be still searchable and browsable. But with the git repo linked above, it’s still somewhat doable.

6

IMPORTANT: Mass migration to GitLab update early 2018 announced switching to read-only, meaning closing bugzilla to new bug reports not running the whole site read-only as existing bugs could still be interacted with:

Bugzilla will keep the original plan and will be switched to read-only on 1st July. You can switch your project to “read only” in the meantime if desired. Remember this is about new bugs, not about bugs already present, those can still be interacted with.

Wrapping up Bugzilla migration 3 years ago announced to convert the site to static HTML pages and decommission the infrastructure, after the bulk migrations of open bugs to GitLab was finishing up.

7

It was part of the GitLab migration plan in 2018:

  • Bugzilla will be phased out and much likely converted into a static website by February 2020 (the proposed date may vary as we’re still evaluating all the possible solutions to make sure all the bugs will remain available in read-only mode after Bugzilla’s service decommission).

Which is exactly what happened: Bugzilla was converted into a static website.

8

I probably thought that the static website would include browse pages: a list of products, and for each product a table with the tickets and their properties (title, status, severity, priority, category, dates, etc).

Ideally with a different status for tickets that have been migrated to GitLab.

Anyway, a bit too late now.

If someone really wishes, I suppose the sysadmins have kept a backup of the DB, so someone could in theory run bugzilla again with the data.

An alternative is to write scripts that parse the bugs pages and re-create some index pages.

As I already said, it’s because it’s a lot of data, and some people might be interested in it. Sometimes researchers like looking at this kind of data.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.