Re: [Qemu-devel] [PATCH] MIPS: Correct FCR0 initialization

[Maciej W. Rozycki]

Andreas,

> >> Actually there were better patches for the same bug by Meador, including
> >> git-style rather than SVN patches and adding a helper to initialize it
> >> consistently at all call sites.

 I find quilt patches easier to manage when I need to reorder them, 
revert, manually edit the diffs (that I routinely do), etc.  Perhaps I'm 
just outdated, but that's the workflow I've found most efficient for me 
while not disturbing anyone else.  I've used quilt patches with the Linux 
kernel including upstream submission successfully as well, for many years 
now, and I don't remember anyone complaining about their formatting.  
Also automatic patch retriever/tester scripts that some mailing lists have 
watching process them correctly.

 Let's therefore please focus on the technical value of these changes 
rather than their envelope.

> >> There's also DSP, Octeon, mips64 and signal handling patches around that
> >> someone needs to volunteer to update, test, clean up and queue.
> >> That a patch is on the list doesn't imply that it "just" needs to be
> >> applied though. So please be careful which patches you ping.
> > 
> > Yes, hence my suggestion to look for patches which got reviewed.
> > 
> > (Although speaking as somebody who has in the past submitted patches
> > which got neither reviewed nor rejected, I have some sympathy for the
> > idea that if nobody among us cares enough to look at a patch at all the
> > default should be to apply it.)
> 
> From my memory Maciej himself retracted his patches in reaction to a
> reply from his colleague Meador. That might not show up when looking at
> just one unthreaded reply-less patch, so in general ack but needs to
> look at context, too.

 I don't recollect retracting any of my patches although I'll be making 
the adjustments previously requested and produce more.  Any patches that 
may have overlapped with an earlier submission come from the same tree, 
except I regenerated them and retested against the then current top of the 
tree; I may have updated them too to address any problems spotted while 
processing them.

> Doing follow-ups based on this one or, in worst case, reverting is
> certainly possible but the decision-making would best be done by someone
> who actually uses mips - not that there's no users, just no volunteer
> for a staging tree yet.

 I'm willing to provide assistance as time permits, in particular to move 
forward with any changes I have proposed either myself or on behalf of 
someone else, although owing to other commitments regrettably I can't 
commit to regular testing/mainentance.

  Maciej