sparc maintainer future

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Dave and Andreas.

Starting a new thread to get some visibility.

Arnd wrote:
> Regarding arch/sparc long-term, I think it would be good
> if Andreas Larsson could take over as (co-)maintainer,
> as he's currently maintaining out-of-tree support for
> leon3/4/5

> My impression from those patches is that they should
> pretty much all just get merged anyway. I would also
> suggest raising the minimum SPARC32 level to that of
> leon3 (SPARCv8e with CAS), which is what glibc requires
> anyway for futex().

Andreas wrote:
> Hi,
> 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. 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.

> Has someone reached out to Dave? I think discussions like these might
> be better served in a thread of its own.

See full thread here: 
https://lore.kernel.org/sparclinux/030e57e1-13a0-4c62-8302-2b0008c6e92e@xxxxxxxxxxx/T/#t

We are in the need of someone that can pick up the sparc patches that
floats around and push them towards Linus - they are often lingering
until Andrew or Arnd picks them, but having a more direct route would be
nice.

I am happy to assist with reviews for the areas I have some experience
with, as I still feel a bit love for the sparc stuff. But cannot commit
to more than that as this is all in my free time.

Thoughts?

	Sam




[Index of Archives]     [Kernel Development]     [DCCP]     [Linux ARM Development]     [Linux]     [Photo]     [Yosemite Help]     [Linux ARM Kernel]     [Linux SCSI]     [Linux x86_64]     [Linux Hams]

  Powered by Linux