This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [maint] Obsolete ARM et.al.
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Richard dot Earnshaw at arm dot com
- Cc: Andrew Cagney <ac131313 at redhat dot com>,Fernando Nasser <fnasser at redhat dot com>,Scott Bambrough <sbambrough at zimismobile dot com>, gdb at sources dot redhat dot com,kwalker at arm dot com, drusling at arm dot com
- Date: Wed, 30 Jan 2002 19:13:03 -0500
- Subject: Re: [maint] Obsolete ARM et.al.
- References: <200201300947.JAA09704@cam-mail2.cambridge.arm.com>
> 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