Re: [PATCH] Remove support for score architecture

[Guenter Roeck]

On Tue, Sep 03, 2013 at 12:54:06PM +0800, Liqin Chen wrote:
> 2013/9/3 Guenter Roeck <linux@xxxxxxxxxxxx>
> 
> > On 09/02/2013 08:18 AM, Lennox Wu wrote:
> >
> >> Before we start the development of the S+core, Sunplus had licensed
> >> ARM and MIPS. We develop S+core for other reason such as the price.
> >> Some products on the web of Sunplus adopt S+core , for example
> >> the SPV7050.(http://w3.sunplus.**com/products/spv7050.asp<http://w3.sunplus.com/products/spv7050.asp>)
> >> These products
> >> could still be bought from the market. Some high-end products adopt
> >> ARM or MIPS. So, there is no conflict for a company adopts multiple
> >> architectures.
> >>
> >> As I said, we recognize that we rarely update because of the limited
> >> applications and rare requests from customers. Maybe we donât
> >> understand the culture enough; we think that it is unnecessary if we
> >> have no new bugs or new functions, the thought seems wrong. We can
> >> commit some patches in the near future.
> >>
> >>
> > The point is not about submitting patches, it is about maintaining the
> > code.
> > Even if you don't add functionality, one would expect that you ensure that
> > new kernel versions compile and run on your hardware.
> >
> > Since January 2012, 68 patches have been applied to arch/score, pretty
> > much all of them addressing kernel API changes or global cleanup.
> > Only two of them got an Ack by one of the score maintainers.
> > This strongly suggests that you don't keep track of what is going on,
> > and at the very least raises the question if you do compile and test
> > new kernel versions on a regular basis. Even if you do, no one knows
> > about it, because ....
> >
> > As part of this process, I would expect the architecture maintainer to
> > accept incoming patches, test the same, and send pull requests to Linus.
> > The last time this happened was early 2011; since then all score patches
> > were sent to Linus through Andrew and a few other maintainers.
> > Actually, I don't see many signoffs from a score maintainer at all,
> > even from the very beginning.
> >
> > As pointed out, the MAINTAINERS entry for score points to a
> > non-existing domain, as does the e-mail address of one of the
> > maintainers.
> >
> > I would not call that "maintained".
> >
> 
> 
> Hi Al Viro, Guenter Roeck, Arnd Bergmann and all,
> 
> I still supports the S+core team to maintain their codes, although I
> left sunplus co. in 2011.
> 
> I keep reading the mailing list and testing these patches for S+core,
> I think the main problems are they have not echoed to any comments on
> score's questions. Maybe they think the current situation is good
> enough for their customers, and they donât understand the rules of the
> group enough. Even so, they should update score code to the latest
> status, include my mail address.
> 
Updating your e-mail address, sending Ack or Nack replies to patches
for the architecture, and possibly sending pull requests to Linus
would be entirely up to you.

With neither you nor Suncore showing any activity, how is the kernel
community supposed to know if anyone maintains the architecture ?
Your e-mail pointing to a domain which no longer exists doesn't really
show much engagement.

Similar, if you _don't_ maintain the architecture anymore, it would be
prudent to let the community know by submitting a patch removing yourself
as maintainer.

> We will discuss how to maintain the code of S+core. However, if all of
> you and Linus also think the S+core should be removed from the
> upstream, we will do it.
> 
The main concern is that the architecture appears to be un-maintained in
practice. We don't know if the code even compiles, much less if it works
on any target hardware. We'll see if that situation changes.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/