On Thu, Dec 7, 2023, at 17:49, Andreas Larsson wrote:
> On 2023-12-06 10:31, John Paul Adrian Glaubitz wrote:
>> On Tue, 2023-12-05 at 21:26 +0100, Sam Ravnborg wrote:
>>
>> No objection this time. But maybe we could sort out the maintainer question
>> first, then start with new patches.
>>
>> I like Arnd's suggestion that Andreas Larsson takes up (co-)maintainership.
>>
>> Can someone reach out to him?
>
> I feel honored to be suggested for such a responsibility. I could in the
> long term be available for a role as some kind of SPARC (co-)maintainer,
> with backing from my organization.
Sorry for my late reply, thanks a lot for offering to help out here.
> My SPARC experience is mainly with
> SPARC32 rather than SPARC64, so discussing a co-maintainership with a
> SPARC32 focus would feel natural as a start. I do not have much in terms
> of SPARC64 or non-LEON SPARC32 hardware available for testing.
I think that's all we need at the moment. The lack of an active
maintainer does get in the way of cross-architecture work,
especially when touching the oldest parts of the code.
The most important bit here would be someone with the authority
or Ack or Nak a patch going into another git tree. Even if you
are sometimes wrong, that is still much better than no reply.
On top of that it would be good if you can set up a git tree
for collecting patches to forward to Linus and get included
in linux-next, in place of Dave's orphaned sparc.git.
Once you have an entry in the MAINTAINERS file, you can ask
for an account to host this on git.kernel.org, but other
locations are also fine if you already have something we can
put in the MAINTAINERS entry.
Do you have a preferred place to host a tree?
> Has someone reached out to Dave? I think discussions like these might
> be better served in a thread of its own.
As far as I can tell, Dave has focused mainly on networking and
bpf development rather than sparc for a few years now.
I would suggest that I send him a proposed update to the MAINTAINERS
file with both of you listed as maintainers and ideally your git
tree location replacing his.
Dave can then reply if he has any other preferences (e.g. having
separate sparc32 and sparc64 maintainers, or becoming reviewer
instead of maintainer).
Arnd
