Everyone on the CC list for each bugzilla bug was notified 6 months ago that any bug without action in over a year would be frozen instead of migrated.
(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.
I wish it was that simple, but I never received a single notice of the migration or my need to do anything at all as a bug reporter. (Just ran a liberal grep on my inbox right now.)
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".
True, but on the other hand bugs can go unfixed for years, with developers ignoring them or prioritizing them super ultra low. I know I've opened enough bug reports over the years that I can't go back and check on all of them, but I'm still hoping they'll get fixed some day.
If it's closed for "inactivity" while I'm actively waiting for a response from the developer, that's going to annoy me.
As opposed to having forgotten about it. As in, if the developer responded, Github would send me an email and I would jump back into the conversation. As in I can't do anything more until the developer responds, but once they do I'm ready to help.
There's a quick and easy way to tell if someone is actively waiting: respond to them.
The reports may still be relevant. If the problem is easily reproducible or even just well described, a bug report should be useful independent of the activity or further engagement of the reporter.
Why would you "check in" in the presence of e-mail notifications of new developments? Most projects also don't like it if you post "bug still exists" every few months.
The parent explicitly mentioned that they did not get the e-mail notification they were supposed to get, suggesting they were subscribed to the issues. So if waiting for e-mail counts your criticism doesn't seem to apply.
> Everyone on the CC list for each bugzilla bug was notified 6 months ago that any bug without action in over a year would be frozen instead of migrated.
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?
> 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?
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.
> 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.
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.
> It's not clear to me the question here, can you be more specific? Many bugs filed are not necessarily bugs in the codebase.
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.
I know that I for one steer people away from projects where serious bugs go unfixed for a long time. I have very little incentive to follow up on them once I’ve switched tools.
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).
A "WONTFIX/NOTABUG" closure at least gives confidence that a bug was investigated. Do we know how many bugs were still pending investigation here, prior to being closed due to this migration?
This would cement an alternate reality, where the growing of the QA team would become more difficult. Trust me, I am talking from experience of recruiting and onboarding hundreds of volunteers into FOSS teams (with varying levels of success and involvement). Recruiting volunteers to FOSS is insanely difficult and any addition of complexity will just result in more headaches.
> jwz has some nasty opinion about hn visitors - so the first link omits the referer
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.
(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.