Re: kernel.org tooling update

On 12/18/25 7:37 AM, Jani Nikula wrote:
> On Tue, 16 Dec 2025, Mario Limonciello <[email protected]> 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 [email protected] 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.

Sure - totally.

> 
> 
> 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.
>>
>