This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Setup PATCH] Eliminate next_dialog


Gary R. Van Sickle wrote:
>>> So, "thanks but no thanks"?
>>
>> Pretty much. Thanks for the detailed list of places requiring changes,
but
>> I've seperated the changes into next_dialog removal, and other cleanup.
>
> There was no "other cleanup" in the patch I submitted, was there?  I
> pinky-swore that there wouldn't be; I'd hate to have inadvertantly reneged
on
> such a sacred oath! ;-)

Oops. Seems I mis-remembered. It was the context refactoring that I stripped
out to minimalize the size of your patch. The other cleanup was things that
could be done that I noticed whilst understanding your patch.

> Can I at least get some changelog credit for the "detailed list"?

Of course.

>> Smaller patches = faster reviews.
>
> Soo, is there any point to me continuing big chooser development?  I
really
> have very little interest in going to a bunch of trouble getting a working
> patch together only to have it serve as a 'list of places' for somebody
else
> to reinvent the same wheels.

Of course!

There is a significant difference between adding functionality (big
chooser), and removing dead code (next_dialog). In the latter case, once I
understood what your patch did, it was trivial to come up with a slightly
different way to remove the dead code, with much less impact on the
surrounding code.

I've no intention of re-inventing big chooser.

It would be nice if you opted for slightly more modular concept patches, but
even if you do produce large multi-concept patches, I want that big chooser
too much to not help out seperating what you produce. It'll just take longer
to integrate.


Max.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]