Re: kernel.org tooling update

[Jani Nikula <jani.nikula@intel.com>]

On Tue, 16 Dec 2025, Mario Limonciello <superm1@kernel.org> wrote:
> On 12/16/25 2:33 PM, Jeff Johnson wrote:
>> On 12/16/2025 8:21 AM, Lukas Wunner wrote:
>>> [cc += Bjorn, start of thread is here:
>>> https://lore.kernel.org/ksummit/20251209-roaring-hidden-alligator-068eea@lemur/
>>> ]
>>>
>>> On Tue, Dec 09, 2025 at 11:48:24PM -0500, Konstantin Ryabitsev wrote:
>>>> ### Bugzilla
>>>>
>>>> It may be time to kill bugzilla:
>>>>
>>>>      - despite periodic "we're not dead yet" emails, it doesn't appear very
>>>>        active
>>>>      - the upgrade path to 6.0 is broken for us due to bugzilla abandoning the
>>>>        5.2 development branch and continuing with 5.1
>>>>      - question remains with what to replace bugzilla, but it's a longer
>>>>        discussion topic that I don't want to raise here; it may be a job for
>>>>        the bugspray bot that can extend the two-way bridge functionality to
>>>>        multiple bug tracker frameworks
>>>
>>> The PCI subsystem relies heavily on bugzilla to track issues,
>>> collect dmesg/lspci output from reporters and furnish them with
>>> debug or test patches.
>>>
>>> The SOP when issues are reported on the mailing list without
>>> sufficient information is to ask the reporter to open a bugzilla
>>> issue and attach full dmesg and lspci -vvv output for analysis.
>>>
>>> If bugzilla is deprecated, we'll need at least a way to exchange
>>> files with reporters.  Preferably on kernel.org infrastructure
>>> to be independent from 3rd parties.  A way to communicate with
>>> reporters outside the mailing list is also useful to prevent
>>> spamming linux-pci@vger.kernel.org with messages relevant only
>>> to a single issue or system.
>>>
>>> All the information now recorded in bugzilla should continue
>>> to be available indefinitely so that Link: tags in commits
>>> continue to work.  It's not uncommon to have to dig in old
>>> bugzilla entries in order to understand the motivation for
>>> a particular code section that was introduced years earlier.
>> 
>> At least some of the wireless maintainers also use bugzilla.
>> The ath11k & ath12k drivers have guidance in the wireless wiki:
>> https://wireless.docs.kernel.org/en/latest/en/users/drivers/ath11k/bugreport.html
>> https://wireless.docs.kernel.org/en/latest/en/users/drivers/ath12k/bugreport.html
>> 
>> So we would also want this or a similar service to be maintained.
>> 
>> /jeff
>
> I know that there was a mention of "external" Gitlab instances earlier 
> in the thread.  How about standing up an LF Gitlab instance?

FWIW, I've been rather discouraged about the free tier GitLab issues
experience. Feature wise, it's a step down from Bugzilla, even if the UI
is more modern. The best stuff is always going into the paid tier. For
this reason alone, I'm partial to something completely community driven
like Forgejo. There's at least the possibility of getting the new
features.


BR,
Jani.


>
> Subsystems that want to use it for issue tracking can have projects 
> there specifically for that.
>
> For example we could have a gitlab.kernel.org and then a project PCI for 
> all PCI subsystem related issues.
>
> This also "potentially" opens up the possibility of subsystems that want 
> to engage in a forge PR/MR workflow with contributors to do so.
>

-- 
Jani Nikula, Intel