[maint] Obsolete ARM et.al.

[Andrew Cagney]

> People tend to assume that an RFC only gets comment if needed.  If no 
>> one yells within a reasonable period of time (few days to a week) it 
>> gets to go in.
>> 
>> For instance I removed IEEE_FLOAT.  I did it as an RFC (left it on the 
>> table for a week) before committing.
> 
> 
> Hmm, this IMO is bad.  It means that trivial patches end up taking ages to 
> get through on the "no-one has objected rule", and makes development 
> tediously slow.
> 
> With this approach multi-arching a back-end is going to take approximately 
> forever, with
> 
> 10mins-1hour to make a change (most of the changes tend towards the 
> trivial)


Once the arm is multi-arch, you're in for a pleasant suprize. Rebuild 
time drops to < one minute!


> 1-2 hours to run the testsuite (probably more at the moment with all the 
> timeouts I'm getting)
> 
> 1-2 weeks to get the patch committed.
> 
> Since I can't really start developing the next change until the first has 
> gone in (to do otherwise would require multiple source trees, which leads 
> to confusion which leads to mistakes) it means I'm developing on GDB with 
> less than 1% efficiency.


It shouldn't be that bad.  The multi-arch process is:

	make change
	test change
	post change
	commit change
	repeat

No approval or rfc needed.  This is because each patch is small and 
fairly obvious.  While this does bend the ``obvious fix'' rule a bit, 
the patches are small and incremental so any breakage is easy to track 
down and can be quickly reverted.  If you're not sure about a change, 
table it for a few days (give the world a chance to go round a few 
times) and then just commit it.

IEEE_FLOAT was probably a bad example since I did leave it tabled for so 
long.  Normally things go in ``in a day or so''.  I sat on IEEE_FLAOT 
and the other related patches since they, while small, were fairly 
significant (yes even ignoring me breaking the Arm :-/).

enjoy,
Andrew