Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming

[Pete Batard]

On 2012.03.20 05:26, Rocky Bernstein wrote:
> Over the 12 or more years, I have been more or less the only person working
> on libcdio. There have been periods where others have come and contributed
> greatly; but over time people disappear.

Yes, and this is true for every single FOSS project. This is a very well 
known given parameter, that everybody seasoned FOSS developer is acutely 
aware of, and does take into account. I very much did for the get go, 
and my proposed changes do factor in the fact that I may not stick 
around. Heck, this is the main reason I advocate the approach I advocate 
when it comes to MSVC support.

> Therefore, it only makes sense to
> have the code and project work along a way that is consistent with the way
> I develop code.

This is where I disagree. The role of maintainers should never be to 
make it easy on themselves, but instead always to seek out ways to make 
it easy on the users of the software.
You are supposed to be a facilitator for development and usage.

I think the issue is you believe such a task automatically equates 
taking on more work for yourself, whereas, I think a pragmatic approach 
to project maintenance would demonstrate that this doesn't have to be case.

> I realize you have a different philosophy of coding and development. I
> don't expect you to change the way you develop code. But also don't ask or
> expect me to change my way of developing code.

If I can identify areas that can both save you time in maintenance and 
support, and help with the goal of being a facilitator for users from 
all horizons I will give you my advice. You're free to take it or reject it.

Introducing a macro that is specifically tailored not to do a thing on 
non MVSC systems, dropping tests requirements for MSVC and keeping a 
version.h in git (and no, until you provide the specifics of the files 
that were involved in the case(s?) where you saw autogenerated + 
committed as an issue, you haven't provided conclusive evidence that 
what I advocate is bound to cause problems) would allow straightforward 
support for MSVC platform and is very much targeted at helping you not 
having to spend any extra time on MSVC... ever.

It may happen that, since you're not going to spend time on it, it will 
break and some fixup will be needed in the future, which is exactly the 
state I found MSVC support in, but you should also find out that most 
developers are OK with a project that is 99% there, and where they have 
to fill in the remaining 1%, as it still beats having to reinvent the wheel.

Nobody, especially not me, is asking you to test for MSVC, or even pay 
special attention to it while you continue to focus on POSIX in the same 
fashion as you did previously. As much as I could test, I made sure that 
none of the proposed changes broke POSIX, and that, the ones that are 
visible to POSIX (header modifications for ISO9660) were kept to the 
bare minimum.

All I am asking then is to integrate them, even with a big "NOT 
OFFICIALLY SUPPORTED" warning, so that it is available for people like 
me, who may need it and furthermore, may want to take the steps to help 
with maintenance and support should noone else be available to do so. 
This is exactly what existed for MSVC/Xbox support so far, which was a 
very pragmatic & sensible approach, since, even as I found it in a 
broken/unmaintained state, it was in a ready-enough state to allow 
anyone to be operational quickly. Had MSVC been supported only in a 
separate branch forked off official, it would have been a very different 
story

> I don't use or even have MSVC. No libcdio developer that is currently
> reading this list other than yourself has indicated they use MSVC, let
> alone expressed an interest in helping out.

Which is hardly surprising for a mailing list with little traffic (as 
far as I can see) tied to a project that doesn't officially support 
anything non-POSIX. However, as libusb demonstrated in a very similar 
situation, if you build it, they will come.

> Furthermore, you've convinced
> me that supporting MSVC is not something libcdio developers other than
> yourself currently can do.

Then I should have made that point more obvious right from the start, 
because I thought this was a given, and that you would be taking this 
fact into account.

> Therefore if you want MSVC support what I suggest is that you develop in
> another branch outside the master.

No.

Been there, done that, and I am, well placed to know first hand that 
this it doesn't help anyone BUT the project maintainer. It especially 
doesn't help the users the branch is targeted at. I've seen exactly what 
that such an approach entails with libusb, where I have been maintaining 
a separate libusb-pbatard branch for years now, even as the maintainers 
gave all assurance that its changes would be merged quickly. Thus, I 
know exactly what is in store, and how damaging the requirement for one 
class of users to use a separate non-official branch actually is. 
Needless duplication, sync issues, painful maintenance and confused 
users. Fool me once.

Hate to put it that way, but either MSVC is part of the mainline source 
(again, it doesn't have to be in an official manner - the way it was 
before I picked it up with a "may or may not work" warning was just 
fine), or I'm not going to be involved any further.

> For now though, it doesn't make sense for version.h to be in master. Since
> you assert it isn't that much work, it shouldn't be that much work for you
> to check this in every now and then when need be.

*I* don't have a problem jumping through extra hoops. That's what I've 
been doing ever since I started using libcdio in my project, and that's 
fine.

What I do have a problem with however is that, in the long run, I do 
expect a lot more people than myself having to jump through these 
avoidable hoops, with the amount of time collectively wasted doing that 
being greater than the alleged amount of time we would need to sorting 
out sync issues with a committed yet out of sync version.h, should they 
ever occur.

Now, if you genuinely expect me to be the only MSVC user for libcdio 
ever, then by all means, don't bother with it. I already have libcdio in 
the state I need for my project, and all I am trying to do right now has 
nothing to do with my personal benefits (why else would I have bothered 
spending time fixing paranoia?), but because I believe it will help 
*others*.

Thus, if you say that you don't expect other MSVC users to materialize 
themselves, the solution to all of our problems will be exceedingly 
simple...

Regards,

/Pete