On Aug 2, 2006, at 5:38 AM, Diego Biurrun wrote: > ?!? Not precisely - your turnaround on most patches is 24 hours, so the general assumption *I'd* make would be that a patch got lost in the overall noise > > May I remind you that reviewing is unpaid, unceremonious and - as this > mail exchange proves - extremely underappreciated work. Look at > how few > people do it. I'd say the ratio of committers to reviewers is > about 10 > to 1. Relax. I've reviewed patches for another project, it's generally not fun and not rewarding. > >... When I have a patch that would deliver theoretically desirable functionality, I am frequently tempted to just rewrite it myself, but I lack time for that, so usually I'll make a brief description of why the patch is rejected and include a general idea of what could be done to fix that if so requested (when I asked how something should be done here, I was told to "write a patch, submit it, and if it's not what we want it'll be rejected.) All of this is neither here nor there at this point, because I have the description of why the patch below is not wanted, and it should be fairly easily fixed. > >>>> >> >> Usually the comments boil down to "this is ugly" or something similar >> with no feedback on what could make the patch "pretty" enough to be >> accepted. As an example, taken from < >> trunk/ffmpeg-svn-mactel.patch>: >> - ".balign 16 \n\t" >> + BALIGN_16 >> and >> +#if defined(__APPLE__) >> +# define BALIGN_8 ".align 3 \n\t" >> +# define BALIGN_16 ".align 4 \n\t" >> +#else >> +# define BALIGN_8 ".balign 8 \n\t" >> +# define BALIGN_16 ".balign 16 \n\t" >> +#endif >> >> Is this really so ugly as to be a scar upon the codebase? If not, >> then what in the linked patch is truly so objectionable? > > I think Rich did a good job of explaining this. > > It's a great pity IMO that most people seem to be content with > coming up > with a hack that makes their machines work but seem unwilling to > work on > a more general solution ... The more general solution was never previously explained in a way that was clear to me. As it is now, I understand the problem with the patch and should be able to put time into cleaning it up properly. Thanks, Augie > > Diego > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel at mplayerhq.hu >