Re: Unmaintained board removal spree

[Paul M. <le...@li...>]

On Wed, Jul 25, 2007 at 12:44:04PM +0900, Magnus Damm wrote:
> On 7/25/07, David McCullough <Dav...@se...> wrote:
> >Jivin Paul Mundt lays it down ...
> >> On Wed, Jul 25, 2007 at 09:51:22AM +0900, Paul Mundt wrote:
> >> Since we're in the purging mood, perhaps it's also worth looking at some
> >> others:
> >>
> >>       - snapgear boards are also unlikely to be revitalized, so that's
> >>         probably another good candidate.
> >
> >How bad is it ?  I am running 2.6.22 here on the snapgear boards and
> >it seems ok.  I can send you some diffs if you want ?
> 
> As of 2.6.23-rc1:
> 
> The snapgear_defconfig seems to be out of sync with the rest of the
> Kconfig - both SH7751 and SH7751R are defined in the defconfig - this
> leads to that only SH7751 is selected which in turn leads to that
> CONFIG_SH_SECUREEDGE5410 never gets set. So the defconfig doesn't
> select the right board. I sent patches fixing a similar issue on r2d
> this a while ago.
> 
> If the right board is selected using menuconfig, then
> arch/sh/boards/snapgear/setup.c doesn't compile...
> 
> So patches for defconfig and board support are more than welcome. =)
> 
The defconfig parts are my fault, due to a lot of reordering for the
machvec tidying. So people do need to make sure there are no surprises (a
simple make oldconfig on -rc1 will leave quite a few boards in a not
entirely expected state).

> Also, the cpu-specific interrupt code has been rewritten for
> 2.6.23-rc1. The new code seems to work just fine on the r2d board, but
> it wouldn't hurt with some testing on other 7750-ish boards.
> 
Yes, it's basically just the board bits and some other stuff that are out
of sync. The rtc stubs have been broken for some time, and there hasn't
been any feedback on this, either. If folks are actually using this board
in recent kernels, then patches bringing it back in sync are certainly
welcome ;-)

I'd also like to add defacto board maintainers to MAINTAINERS so it's
more obvious who to hassle when the board stops working. Stuff that's
actively being used, we can roll in to the nightly builds so we can watch
out for regressions and keep folks notified as to the status of their
board in current git kernels.