… and closed about a bazillion bugs I filed over the years in the process without (apparently) migrating them, too.
… though I am pretty sure they left the bugs in the source intact.
… though I am pretty sure they left the bugs in the source intact.
(Do keep in mind that GNOME, unlike corporate projects, is largely volunteer based and time, resources, and contributors are limited)
As the email said, you just needed to ACK a comment on the bug to keep it alive and ensure its migration.
Given the nearly 900,000 bugs filed in the life-span of bugzilla, I think that was an acceptable trade-off given the very small workforce.
Hopefully, the gitlab tooling will allow us to track things going forward much better.
Personally, I think a lot of bugs in Bugzilla were just left open instead of closed due to a difference of opinion/vision but different maintainers have different triage styles.
A quite safe value from there is
network.http.referer.XOriginPolicy = 1
I prefer to just not go. If he doesn't want the likes of me there then I'm happy not to waste effort trying to pay attention to whatever it is he is saying.
What's the relationship between the existence of a bug in the codebase and the propensity of the bug reporter to respond to an email?
> Personally, I think a lot of bugs in Bugzilla were just left open instead of closed due to a difference of opinion/vision but different maintainers have different triage styles.
How does Gitlab prevent those same maintainers from creating that same problem again?
It's not clear to me the question here, can you be more specific? Many bugs filed are not necessarily bugs in the codebase.
I do wish we treated bugs and user support separately. I rather prefer the terseness of an engineering journal for what it is, but that tends to anger those expecting user support.
> How does Gitlab prevent those same maintainers from creating that same problem again?
In Bugzilla, the only real option we had was "Closed: WONTFIX/NOTABUG" which almost always resulted in hurt feelings on the part of the bug reporter.
I think the gitlab tooling allows us to be more diplomatic in closing bugs that are out-of-scope or not aligned with the goals of the project at large.
Right. So your goal is to separate reports about bona fide bugs in the codebase from reports that either a) are no longer bugs in the codebase or b) are issues outside the scope of the codebase. That's a laudable goal.
Filtering out years of bugs based on the lack of timely response from a submitter (or others) doesn't seem like a sound way to achieve that goal. There's no clear relationship between a lack of response and the relevant bug's existence/non-existence.
The correlation between bugs that matter a great deal to me and bugs I don’t respond to is much greater than zero.
If you delete all the bugs that caused people to abandon your platform then you are cutting off your own nose.
Can’t reproduce is a better metric but only if it’s other users rather than the maintainers. I find that a lot of people who write buggy code also are bad at reproducing issues (which I think is why they have bugs in the first place. Lack of imagination or rigor or both).
> I think the gitlab tooling allows us to be more diplomatic in closing bugs that are out-of-scope or not aligned with the goals of the project at large.
Can you give more details about this? Closing is closing and Bugzilla allows you to name your statuses whatever you want, so I don't understand how GitLab would change anything.
My experience is that GitLab (and GitHub) is worse in tracking bugs compared to Bugzilla (I've triaged about 10k reports).
I also think having the cut-off at 1 year is a bit drastic. I would have gone for 5 years.
Why not have a buck tracking system where only contributors have write access and a second system where users can submit their reports?
In the face of that reality, a separated internal and external bug trabkin system might be a viable solution.
The only notice I received was after-the-fact. Sorry.
Learning of GNOME'S cavalier attitude toward user reports and eventual product direction was exactly why I moved off the platform in the intervening years. I had high hopes when I was young and naive.
I realize GNOME is volunteer-based with a pillar of corporate backing from Red Hat and similar, but it strikes me as botched that if enough will existed to migrate to GitLab, an endeavor that requires serious engineering hours of research and planning and execution, that nobody could have said: let's query and build a list of unique email addresses from bug reporters and personally email them once with a quick letter, letting them know what they need to do. Compared to the actual migration, that is drops in a bathtub. Simple due diligence for user-facing goodwill.
I want to be sympathetic — really.
JWZ's CADT supposition has a lot of explanatory power here combined with the opportunity to "scrub a lot of bugs quickly".
(edit: I didn't see it was already posted below)
If it's closed for "inactivity" while I'm actively waiting for a response from the developer, that's going to annoy me.
There's a quick and easy way to tell if someone is actively waiting: respond to them.
All the more reason not to undo the work of its contributors.
> There are no issues to show.
With the sole exception of one e-mail from legacy Bugzilla:
> This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
That one that HAS been migrated appears as follows:
> You can subscribe and participate further through the new bug through this link to our GitLab instance: …
Back then, I managed to get approval from all our contributors/issue authors so that their individual bugs and comments would show up as their individual bugs and comments, as well as retaining issue numbers.
This is the code for it, if anyone is interested, but as I said the whole thing is unsupported now: https://github.com/jleclanche/bugzilla-to-github
https://gist.github.com/jonmagic/5282384165e0f86ef105
But it doesn't let you change ownership of issues or comments; everything appears as created by the importing user.
Also, you can impersonate commits freely.
I don't think allowing full import would be a big deal, especially if the UI made it clear that the comments were imported.
https://www.jwz.org/doc/cadt.html
Makes me wish I had seen JWZ's writeup before spending so much of my time filing the damned things.
What would be even better is if the HN referrer would create a temporary blacklist for that IP.
Then when you paste a jwz URL into a new tab, he could send a response, "And don't try using a different browser, either!"
So the only conclusion you can really draw from "one bug was 11 years old" is that they had been using that issue tracker for at least 11 years.
No, it does't. The bug tracker might list over 40 pages of reports that were filed over 11 years ago, but that doesn't mean each entry represents a an actual bug.