Re: [Libusb-devel] >=autoconf-2.63 no grok multiline AC_CONFIG_FILES?

[Peter S. <pe...@st...>]

Pete Batard wrote:
> when we know precisely how to fix an issue that we suspect many users 
> will potentially encounter, and it's a 10 seconds low impact fix
..
> not doing it really makes us look like a bunch of pompous developers.

The point is that it is a workaround for a problem elsewhere, and I
would rather understand the problem than settle for a workaround that
allows the same problem in the future.


> Some people like the stability of dot releases. Others like to be at
> the very edge.

Why I think snapshots are important, and something we sorely miss,
especially since there is a lot of work going on and no release for
a while.


> there's nothing in the LPGL that tells you to either not use
> specific flavours of git or pay the consequences.

No - that's just common sense.


> Open source gives you NO RIGHT to constrain how people can
> contribute to a project.

Creating any work gives both you and me the right to constrain others.

It's about tools; if the tools are used well, then contribution
becomes very easy with git both for contributors and the project.


> If someone new to git and libusb experiences a bug in the Windows
> backend, I'd much rather they try to propose a patch than send a
> mail with "it doesn't work".

Me too! But it's not common, and I don't believe the reason is that
git is a hurdle.


> Heck I'll even help them find their way with git,

Which is a great initiative! I think it makes a lot of sense to
gather some git knowledge that we find useful on
http://libusb.org/wiki/Development


> I'm really starting to have a problem about how exclusive and
> elitist you seem to be willing to turn libusb into.

I think you misinterpret my intentions and assume the worst.


> In my book, everybody who want to contribute to libusb is more than
> welcome, no matter the background.

Yes and no, because handholding can take a lot of time. But I
certainly think that it is a good idea to have a reference for things
that are relevant to those who use libusb and may want to help by
sending code improvements. Anyone who feels like working on that kind
of documentation, or any other kind of documentation, and does not
yet have access to the wiki to do so please let me know and I will
arrange access immediately.


> What's more, given our rate of releases, we're hardly in a 
> position to place an entry level hurdles on libusb contributors.

Because much is pending it is especially difficult to find resourcee
for training new developers.


>> -crlf is a backwards compatibility flag that means -text. I want to
>> understand why some of your git tools ignore text+eol=lf before
>> applying a -text workaround.
>
> If you have time to waste with git (I don't),

A very difficult situation if you want to contribute but do not
really care for learning the tools.


> my git/config for libusb is attached.

Hm. You set safecrlf explicitly. My git config --help doesn't say
what the default is, but I don't think safecrlf=false can ever be
harmful. But I think autocrlf=true explains why you need -text in
your repo.

I think whitespace=cr-at-eol is plain incorrect when working with
libusb. It suggests that we would want CR in the repository, which
isn't the case. Instead, we should use the tools, and git can handle
CRLF conversion. Possibly we need to give it more accurate
information (e.g. in .gitattributes) for it to work well, but -text
is obviously not great for text files.


> As for the underlying msysgit it's 1.7.1.msysgit.0.

This is pretty recent so -crlf is only backwards compatibility also
there.


> Again, if you're rejecting a *working* fix,

-text is a workaround, not a fix.


> then do propose something better that you have tested.

Normally I make it a point to do just that, but I can't really test a
fix when I can't reproduce the problem. I have no Windows system.
This is why I was hoping that you would investigate.


> The project will not gain much from your becoming a git master, 
> or reaching git enlightenment, if patches stay on the sidelines.

The project will gain in efficiency if all project members are git
masters, as I think we should aspire to be, to the relevant extent
for us each. Does that make sense at all?


>> The tools should not behave like that.
>
> Yes it shouldn't. But it's not like people are not already aware that 
> there's git's CRLF handling has issues [1].

I think this link fell off? I'd be interested in reading it.


> I don't trust git one bit to handle CRLFs

So far I do, because it has been reliable for me, so I still think
it's important to find out what it causing the problem that you see.


> if we switch to SVN tomorrow or another VCS, all the time spent
> figuring out that issue will be worthless.

I actually don't believe there is another tool as good as git right
now and there's no point in switching to something worse.


> I think we should establish a rule for libusb development. If
> you're spending too much time on pure git matters, as we've been
> doing way too much lately, then you're wasting everybody else's,

I don't think learning is ever a bad thing.


> less time consuming than the alternative

Of course learning takes time, and if time is of the essence then
learning is actually dangerous in the short term. But I believe that
learning starts paying off pretty quickly, and certainly is a net win
in the long run.


//Peter