LWN: Comments on "Development process issues"

Development process issues

mcortese — Thu, 17 Nov 2016 21:49:17 +0000

He suggested that one reason for the size of the 4.9 development cycle is the pre-announcement by Greg Kroah-Hartman that it would be a long-term-support release.

I though 4.10 was the one supposed to get the long-term support. At least, that's what I had understood from this LWN article:

The Debian "Stretch" release isn't expected for more than a year, but it just has been pushed back a couple of months, with the full freeze now scheduled for February 5 of next year. The reason is to be able to ship with the first kernel of the year (expected to be 4.10) that, by current plans, should be a long-term support release.

Bugzilla

bronson — Mon, 07 Nov 2016 22:28:28 +0000

Thanks! I haven't used Bugzilla much in the past 8 years (so I feel a little sheepish even taking part in this discussion) but I'll remember that.

Looks like typeahead completion would be a great feature there.

Bugzilla

bronson — Mon, 07 Nov 2016 22:23:08 +0000

I like it. But there's a difference... If you already wrote the patch, creating a ticket for it shouldn't take more than an hour of writing (and probably a lot less). Doesn't seem like too a big a deal for the stable kernel series.

Isolating, checking for dupes, and filing new issues requires quite a bit more effort.

Filing an issue on the Kernel Bugzilla is probably even more likely to be ignored than on Bugzilla's Bugzilla. There's some irony or mild hypocrisy there too! But I think the Bugzilla teams can take care of it.

Bugzilla

pizza — Mon, 07 Nov 2016 21:15:24 +0000

> Why not file bug reports you ask? Because that takes effort and often results in yet-another-ignored-bug. For some projects, it just isn't a good use of time.

That's a particularly ironic statement to make in a discussion about possibly requiring the creation of tickets in order to submit patches to Linux.

Just saying...

Bugzilla

excors — Mon, 07 Nov 2016 20:49:46 +0000

> Why is it that producing useful results always seems to require filling out a giant HTML form with absurdly large select lists?

Have you seen the quicksearch feature (https://bugzilla.mozilla.org/page.cgi?id=quicksearch.html)? It took me years to discover that existed, but it seems a lot less painful than the advanced search form - you can type in stuff like "ALL product:bugzilla summary:email creation_ts>=-1y" and do reasonably complicated queries.

Bugzilla

bronson — Mon, 07 Nov 2016 20:34:18 +0000

Did you see "the [Kernel] Bugzilla used to have better email integration, but that was lost in an upgrade"? That seems like a great place to start!

Why not file bug reports you ask? Because that takes effort and often results in yet-another-ignored-bug. For some projects, it just isn't a good use of time. I don't know how responsive the Bugzilla team is now but I sure felt that way back in the mid-2000s.

Also, I must say, trying to browse https://bugzilla.mozilla.org for Bugzilla issues is just exhausting. Why is it always forgetting the product I'm interested in, even if I just click a tab? Why is it that producing useful results always seems to require filling out a giant HTML form with absurdly large select lists? Why is it that the results never seem to be ordered by relevancy so I'm always scrolling and paging?

Sorry, that got a little long. Hope it helps answer the question though?

Bugzilla

gerv — Mon, 07 Nov 2016 17:24:11 +0000

But no-one said "Hey, if we have these problems, why not file bug reports, or ask the authors of the software about them"?

Bugzilla

corbet — Mon, 07 Nov 2016 17:13:38 +0000

It would have been kind of hard to invite the Bugzilla developers to an unplanned discussion that came up spontaneously.

Development process issues

gerv — Mon, 07 Nov 2016 14:51:49 +0000

It's kind of depressing that they work through an entire conversation about the supposed shortcomings of Bugzilla without, you know, inviting the Bugzilla developers to join the discussion.

Bugzilla *does* have email integration out of the box, in that it sends out email about changes and, if you set it up, you can email back your responses and additional changes. There is no need for additional security patches - or, if there is, we'd like to know about them!

Bugzilla supports the concept of extensions, which would allow changes like the proposed ones to be made without significantly complicating the upgrading process. Although I note that the kernel Bugzilla is still running 4.4.6, which is six point releases behind the latest 4.4 release (4.4.12), released in May. So it seems like the plan to make upgrades easy by not changing the software at all doesn't actually lead to them happening in a timely fashion. Still, an upgrade to 5.0 is planned, so that's good.

The Bugzilla team are easy to find (https://www.mozilla.org/about/forums/#support-bugzilla) and are happy to help with any questions the maintainers have.

Gerv

Development process issues

jani — Fri, 04 Nov 2016 11:54:20 +0000

Clearly one size doesn't fit all here. I think subsystems/drivers should be free to use whichever method to track bugs they feel suits them best. That's just fine. I'm suggesting (akpm picked the patch up, maybe it sticks) to add a new "B:" tag to MAINTAINERS to identify the preferred method of filing bugs, so the bug reporters at least have a chance to get it right.

Development process issues

viro — Fri, 04 Nov 2016 00:53:53 +0000

A bit of clarification/context: what I said was that I won't use kernel bugzilla, that I'm not paid for using that thing and frankly, can't imagine being possibly paid enough for that.

Dealing with RH instance of bugzilla is unpleasant enough, but using that for upstream work as well? Hell, no. email can be comfortably used offline; that thing, on top of a generally atrocious interface, cannot.

Development process issues

egrumbach — Thu, 03 Nov 2016 17:17:15 +0000

As iwlwifi maintainer, I use bugzilla.kernel.org a lot. We often ask people on the mailing list to open a bug for better tracking. This allows to have all the related logs in one place etc...
Having bugs in bugzilla allowed me to track and list the bugs which is crucial to convince management to allocate time for bugs that come from the community.
I really try to avoid working on OSV's bug tracker because it consumes a lot of times and mostly because I can't control the release process there. To us, it would be sad to see bugzilla.kernel.org going...

Development process issues

jani — Thu, 03 Nov 2016 14:05:28 +0000

> An alternative would be to replace it with a set of subsystem-specific trackers for
> the subsystems that are interested. The problem there, though, is that the relevant
> subsystem often changes as a bug is understood; moving an entry between separate
> trackers would be painful.

In the drm subsystem, bugs get reassigned between kernel and user space more often than between kernel components. Thus we prefer bug reports at https://bugs.freedesktop.org/ over https://bugzilla.kernel.org/ to avoid moving between trackers.