Hi Jim, On 20 Oct 2011, at 23:44, Jim Meyering wrote: > Gary V. Vaughan wrote: >> On 19 Oct 2011, at 20:13, Jim Meyering wrote: >>> Gary V. Vaughan wrote: >>>>> Jim, please consider pulling it into coreutils master as a better fix than >>>>> twidding Makefiles after the fact in bootstrap.conf. >>>>> >>>>>> This -Iintl option will disappear with gettext version 0.19 - because >>>>>> then "gettextize --intl" will not work any more; it's already deprecated. >>>>> >>>>> And then, when coreutils moves to gettext-0.19, it's easy to remove the >>>>> diff file at the same time. >>> >>> Your change got me past that bump. >>> That's definitely a better way to work around the problem. >>> >>>> Ping. >>> >>> I haven't forgotten. >> >> Okay, thanks. >> >>> It's taking so long because this task has >>> priority lower than almost everything else -- it's primarily >>> an optimization, after all. >> >> Bummer. Being at the back of the queue is no fun, especially when all the >> folks >> that arrive after you get served first. > > Hi Gary, > > Your suggestion of unfair treatment is unjustified.
I don't feel and didn't intend to imply it is unfair by any means, and I'm sorry if I gave that impression. I was merely commenting that it is definitely a bummer for me to be at the back of the review queue... no slight on your good self or gnulib implied or intended. > Are you trying to demotivate me/us? Absolutely not. I even put a winky-smiley on the end to let you know that I am not being mean or serious. > No review request of a 1000-line rewrite -- or even a 100-line rewrite -- > has taken precedence over yours. Well, I don't think a full in-depth review of a 3000 line module is really the best approach anyway... and that something more empirical (such as just trying it out, and trying to break it) is more appropriate, and more manageable, which is why I've expressed my gratitude to you for agreeing to try my rewrite out in one or more of your projects. > If you had proposed incremental changes, as requested, > the review barrier would not be so high. If by "incremental" you mean transforming the old script into the new script, then I'm not refusing, only saying that it's not possible because it wasn't done incrementally: I wrote the thing from scratch, and where I got stuck resolving with emails to and from this list or reference to one of the bootstrap or bootstrap.conf scripts in the projects I want to help upgrade. On the other hand, if by "incremental" you really mean chunking my rewrite into patches that add a function here and there, and disable bits of the old script when they are no longer called, then I could be persuaded to do that. How big should the chunks be to make reviewing them managable? >> Maybe a return to plan A is better after all: Where I ask if anyone has a >> reasonable objection to my committing the saner bootstrap to gnulib (which of > > Please try to adopt a more accommodating tone. > Already you have refused the suggestion to present incremental > changes. Now, when review of your monolith doesn't happen as > quickly as you'd like, you propose to oust the preexisting, > more-widely-used script. Doesn't that seem premature, or even > impetuous to you? Not in the least, but I don't mean to offend by any means. If I'm still waiting and pinging periodically next year, is it really so terribly unreasonable to propose that I ask for objections to upgrading the gnulib bootstrap unilaterally, and only apply some weeks later if no objections come up? > So far, gnulib development has been remarkably cordial and professional. > Let's try to keep it that way. Apologies again to yourself and anyone else that took offense, or felt I was being uncordial or unprofessional. Email is a tricky thing compared to face- to-face, or even telephone conversations, and I perfectly understand that it's very easy to misread something in a different tone to how it was written. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
