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

[Pete B. <pb...@gm...>]

On 2010.12.03 14:45, Peter Stuge wrote:
> Open source is actually the other way around. Check the license.

"AS IS" doesn't mean deliberately annoying to build for our users.

The core of the (L)GPL is a minimal requirement ensuring that ANY user 
of the software have the ability to rebuild and run a modified version, 
and carry on the same rights for the next user. It's about providing 
them the complete freedom to do so. Now of course, developers can stop 
there - nobody is forcing them to go the extra mile. For instance,  case 
they can produce something akin to the Nokia hotplug patch: "Here's a 
tgz of our modified source - we've filled the LGPL requirements, see ya".

But as you yourself pointed out, going with the license minima is not a 
sane approach and this is now the kind of behaviour we want to 
encourage. Now, if you really want to stick to the Open Source license 
to the letter, as you seem to be willing to do here, then what right did 
you have to tell Nokia how they should have engaged with us, since they 
did fully comply with the license obligations?

Well, the situation is very similar here. We can tell our users (I'll 
come to git users being 100% part of our user base) "if you want to 
build, just upgrade your tools, or sort out your default configuration", 
and we'll have filled our LGPL requirements, without the need to go a 
millimeter further, let alone a mile.

But 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 
(because, right, the possibility that someone might modify the 
.ac/.am/.sh in a DOS editor if we use -crlf and inadvertently 
reintroduces some CR/LFs should really take precedence over everything 
else - who cares about annoying TortoiseGit users now when we can ensure 
that no potential future developer will ever reintroduce a small issue, 
which we will either catch up during review, or at worst, fix in 30 
seconds if reported), not doing it really makes us look like a bunch of 
pompous developers.

The (L)GPL only sets the miminum requirements that ensure software 
freedom is respected by all the parties. If you start to see them as a 
target, you might as well switch to writing proprietary software IMO.

> It's unfortunate that you continue to consider someone using git to
> be a user. (Currently they have no choice, but that must change with
> snapshots.)

As I already pointed out last time you asked about this very item, as 
long a we have a a *public* git tree, then our users are *free* to use 
whichever method they want to retrieve the source. Some people like the 
stability of dot releases. Others like to be at the very edge. Now if 
you want to dismiss the latter category as developers who are not worthy 
of our consideration, because they're not approaching software 
development the same way as you do, better make that statement feature 
prominently on the libusb homepage, because this is a freedom 
restriction that they need to be aware of.

Until then, I'm afraid this is open source. If you want to use our 
software, there's nothing in the LPGL that tells you to either not use 
specific flavours of git or pay the consequences.

> Someone new to both libusb and git have a lot to learn before they
> will be effective code contributors in the project, and as a general
> rule no we should not optimize for them if it comes at a cost.

10 seconds patch != full fledged optimization.

And once again: Open source gives you NO RIGHT to constrain how people 
can contribute to a 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". Heck I'll even 
help them find their way with git, as I've done no later than yesterday 
with someone who wanted to test the hp branch. That's also how you 
ensure that everybody in your target audience has a positive experience 
with your software, and that the software is successful.

Again, I'm really starting to have a problem about how exclusive and 
elitist you seem to be willing to turn libusb into. In my book, 
everybody who want to contribute to libusb is more than welcome, no 
matter the background. What's more, given our rate of releases, we're 
hardly in a position to place an entry level hurdles on libusb contributors.

> TortoiseGit is not what I would recommend to Windows users because
> it has been useless for me in other ways.

And I'm going to tell you that, as far as I'm concerned, I found that 
TortoiseGit made my development more productive. You had a bad 
experience, I've had a good one (for almost a year now), and what's 
more, I'm proposing a fix to ensure that, if people still have a bad 
experience with TGit, it doesn't come from something that libusb could 
avoid. But sure, nobody should seriously be using TGit because you said so.

> -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), my git/config for libusb 
is attached. I had the same issue with libwdi (but libwdi initially 
branched of libusb), and I think I reinstalled Tgit/Msys-git from 
scratch at least once (probably twice) and the issue persisted.
Currently, I'm using 1.5.2.0 (because it's been stable alright, and I 
haven't found the need to upgrade, I'll switch to 1.5.8.0 when I have 
nothing better to do). As for the underlying msysgit it's 1.7.1.msysgit.0.

Again, if you're rejecting a *working* fix, then do propose something 
better that you have tested. If not, you should have enough flexibility 
as a maintainer to accept the fix, especially when maintenance 
operations are way behind schedule. But that's just my view of how I 
would approach it in your shoes. The project will not gain much from 
your becoming a git master, or reaching git enlightenment, if patches 
stay on the sidelines.

> 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].
After I searched this further (yesterday) and found the bit linked, I 
got even more convinced that the last thing I want to trust git to 
handle CRLFs, hence my push for us to have full control by applying 
-crlf, be done with it, and move on to something a lot more productive.

> It does not match my understanding of git config --help and
> I hope you can investigate further since you're the only one seeing the problem?

I'm the only one who *reported* the problem, big difference. I wouldn't 
be pushing it so much if I didn't expect other TGit/Msys-git users to 
also have to experience the same issue.

Again, as far as I'm concerned, I don't trust git one bit to handle 
CRLFs (wasted enough time with that already), and I want to be in 
control of the files that matter. In the branches that are under my 
control, I have now achieved these goals. Besides, if we switch to SVN 
tomorrow or another VCS, all the time spent figuring out that issue will 
be worthless.

The fix I'm proposing is fine and it *WILL* address the issue completely 
(no need to overblow potential reintroduction of CRLFs when it can be 
fixed as easily). The only problem we really have with it that git 
zealots say it is not the "git way".

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, and that's why this 
is the last reply you'll get from me on this matter. If I have to 
dos2unix my files when I use official branches, because you don't want 
to apply -crlf (would need it on *.sh, *.ac, *.am), I'll go through with 
it, because it'll still be less time consuming than the alternative.

Regards,

/Pete