Re: [Libusb-devel] libusb-stuge.git broke cygwin compilation

[Segher B. <se...@ke...>]

> I'm not talking about a single commit, but dealing with whitespaces and
> quotation could really be done in a single commit, especially when
> there's more to process.

Sure, but is there a problem with it being more commits?

> configure.ac is just a recepy, and none of the changes we're discussing
> here are changing even a single bit of the final libusb binary. single
> or multiple lines? not one bit. using an alias for nfds_t? not a sinle
> bit.

Interesting examples you give there!  You had separate problems with
both these commits, remember?  :-)

> How's that crucial to 1.0.9? Why could it not wait for 1.0.10 or 1.0.11
> when there's more than enough patch submissions to keep us busy without
> even wanting to overhaul configure.ac?

That's a different problem.  1.0.9 is taking way too long, I certainly
agree with that.

But rolling everything into one mega-patch will not help; quite the
opposite.

> People are not waiting for us to
> release libusb with an overhauled configure.ac. They're waiting for
> hotplug,

Won't be there, nothing has been written yet!

> timestamped logging,

Minor if you ask me; should be easy to merge, sure.

> libusb-win32

Do you have that ready to merge?  In an acceptable state?

> and all the good features we
> know we have to do, but that are ever delayed because we're chosing to
> waste out time on this "oh, but it will make things so much better if we
> do it now - just wait and see" crap.

I don't know what is taking Peter so long, but this really isn't it.

>> One change = one commit.
>
> OK. I guess I'm going to start producing one commit for every option I
> change in the MS project files. Linux and OS-X people should be thrilled
> the day we have 9 commits in a row just for MS project files.

They will see just one merge commit, so they really won't care much.
Most people wouldn't care anyway.  There isn't any problem like this
in *much* bigger projects, why would there be here?  Just don't look
at patches you're not interested in (but do test stuff on your platform,
you're platform maintainer (if I understand that correctly) -- a thankless
job, for sure.  If stuff breaks, git bisect is your friend, whether there
are a thousand patches or just ten).


Segher