[PATCH 1/2] [ARM] mach-types: Re-add apf9328

[Russell King - ARM Linux]

On Thu, Oct 13, 2011 at 11:06:09AM +0200, Uwe Kleine-König wrote:
> On Sat, Oct 08, 2011 at 11:07:22PM +0100, Russell King - ARM Linux wrote:
> > On Sat, Oct 08, 2011 at 09:26:21PM +0200, Wolfram Sang wrote:
> > > On Sat, Oct 08, 2011 at 05:19:48PM +0200, Gwenhael Goavec-Merou wrote:
> > > > 
> > > > Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou at armadeus.com>
> > > 
> > > I think this file is maintained by Russell, yet I want to ack that the entry
> > > below is missing for building mx1_defconfig. Found that, too.
> > 
> > The thing is - read the comments at the top of the file.  There's hints
> > there as to what will happen if you patch the file.  The hint is
> > 'automatically generated'.  So when I next update the file, any patches
> > done to the file will be wiped out.
> Currently the id is still missing in your for-next branch and it is
> marked as "mainlined" on http://www.arm.linux.org.uk/developer/machines/
> (906).
> 
> That means that the next update should include the id, right? Maybe it's
> worth to add it already earlier with the patch Gwenhael proposed as
> without it mx1_defconfig is broken. After f32609c5a035 it even breaks
> imx_v4_v5_defconfig.
> 
> BTW is there a way to see the mach-types file as it would land in
> linux.git if it were updated now?

http://www.arm.linux.org.uk/developer/machines/download.php?q=1

will be the exact file if I were to update it right now (that's the
URL it's retrieved from.)

One of the problems we now have is that I no longer have visibility
of platforms going into mainline (I only find out after they've been
merged into mainline), so I've no way to update the database with
that information before I do an update - my information will be up
to three months out of date.  This in turn means that the 12 month
grace period can expire and the entries deleted from the merged file
_after_ they've been merged and queued up elsewhere.

As I've already said, this has now become one very big unmanagable
problem.  It needs someone to spend a lot of time at each update
manually verifying every addition and removal (and kicking those
people who botch their entries up - which given my interpretation of
the data protection act means it can only be me).

I haven't committed an update since August, and at this point in the
cycle, I'm not going to before this merge window - the risks of breaking
something already merged or queued up are just too great to consider
doing so now.

Longer term, I don't have an answer to this problem - I don't think
there is a workable answer to a distributed development model with
a centralized ID database with a grace period on 'unused' entries.