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

[Rocky Bernstein]

When I wrote "we" I meant libcdio developers. You seem to have interpreted
this as "you and me" which effectively might be the same thing.

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. Therefore, it only makes sense to
have the code and project work along a way that is consistent with the way
I develop code.

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.

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.  Furthermore, you've convinced
me that supporting MSVC is not something libcdio developers other than
yourself currently can do.

Therefore if you want MSVC support what I suggest is that you develop in
another branch outside the master. In that branch, feel free to check in
version.h or make other changes in that branch that you want. To the extent
it makes sense to merge the changes in master, we can do that.

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. There will be a version
number change probably to 0.90 before release, but that's about it. So
folks don't get confused, I'll also remove the MSVC project files in the
master branch and make note to look in some other branch for the MSVC
project files.


On Mon, Mar 19, 2012 at 7:07 PM, Pete Batard <address@hidden> wrote:

> On 2012.03.18 04:07, Rocky Bernstein wrote:
>
>> Is the glass half empty or half full? Right now we don't *have* any MSVC
>> users, except yourself.
>>
>
> Indeed. And by the looks of it, it doesn't look like you're willing to
> take any steps to encourage more MSVC users to use libcdio, by applying a
> *pragmatical* approach to MSVC support.
>
> Especially, you may want to acknowledge that there are quite a few more
> developers using MSVC than any other development environment out there, and
> therefore that the interest in an MSVC friendly libcdio is likely to be
> quite a bit more important than, say, the interest in an Amiga friendly
> libcdio (for which, by the way, partial support is at least partially
> already available, since there exist Amiga specific statements in types.h).
>
> There is such thing as market penetration considerations.
>
>
>  So I'd turn statement
>> around to ask to what extent do we want to *attract* MSVC users.
>>
>
> Please don't use "we" here.
>
> You are the only one pondering as to whether you want to attract MSVC
> users so far, whereas my latest proposal contained all the steps I saw
> necessary to *actually* attract them.
>
> It did so by making libcdio as straightforward and easy as possible to
> use, through the removal of encumbrances that MSVC developers wouldn't want
> to concern themselves with, such as a brand-new, time-consuming and
> prone-to-breakage MSVC testing implementation (only really useful for the
> maintainers of the library, rather than people who merely reuse it), or
> having to jump through hoops just to get a 2 line version.h file created.
>
>
>  Given what
>> you report, excerpted below (all of these are just very long) I am getting
>> the impression that we probably can't go as far as you want towards MSVC
>> friendliness.
>>
>
> We very much can (see above), but not if you are focused on making what
> are essentially secondary matters for library users more important than
> they should really be.
>
>
>  And perhaps not supporting MSVC is not a bad thing.
>>
>
> Perhaps not a bad thing for *you*.
>
> However, I don't think you can state that it wouldn't be a bad thing for
> the collective of MSVC developers out there who may have some use for a
> libcdio like library and could avoid wasting their time reinventing the
> wheel.
>
> Are you not developing a cross-platform libcdio in the hope that it will
> be useful for others?
>
>
>  Code I have seen that supports MSVC and non-POSIX systems -- like GNU Make
>> -- does so at a great price. Often there are people dedicated to making
>> things work on just MSVC.
>>
>
> Same thing is true for projects that originated from MS environments and
> then went cross platform, so I'm not sure what your point is.
>
> Or are you saying you're afraid you won't have enough contributors to help
> you with MSVC support, and therefore that it is pointless to do anything to
> make libcdio MSVC friendly and attract such contributors in the first
> place? Looks like a self fulfilling prophecy to me...
>
>
>  ... Bug is fixed in git repo or new feature is added, and next tarball;
>>
>>> release is whenever =>  developer wants to use git.
>>>
>>> Also, if developer finds bug, they may want to feed it back =>  better be
>>> in a position to do so right from the start. If I'm starting to pick up
>>> issues with software that I reuse, even if I originally picked a tarbal,
>>> then I'm probably going to switch to using the git version so that I can:
>>> 1. ensure that I'm not missing something that is only fixed in git
>>> 2. feed back patches if I address problems.
>>>
>>>
>> People who work this way should have more than MSVC development tools. I'd
>> expect at least MinGW development tools as needed.
>>
>
> Nope. They have git and the MSVC debugger. That's all they need. As a
> matter of fact, the first thing I did when I encountered issues with the
> now obsolete paranoia in MinGW tests was create a project for MSVC, so that
> I could fix things more easily. And as a side note, had the paranoia tests
> not been there to fix in the first place, I could have spared about one
> week of development on a task that was pretty much useless since bound for
> removal. Thus I could actually have done with less or even no testing at
> all in libcdio.
>
> But if you want a real life example, in all the development I do, I spend
> about 95% of my time with Visual Studio, and would spend 100% if I didn't
> *choose* to provide MinGW support in order to be friendly for people who
> may not have access to that environment => my MinGW usage is pretty much
> limited to testing for breakage, as well as potentially releases when they
> present some advantage over VS (eg. smaller or easier to script for). I'm
> pretty sure that if you ask around, you will find that most developers tend
> to avoid having to install more than one development environment,
> especially when their goal is usually to develop an application for one
> target only.
>
>
>  ... I don't expect MSVC users to run any libcdio tests. Ever.
>>
>> This doesn't compel me to want to include MSVC support.
>>
>
> And thus MSVC people will be deprived of a library that would probably
> work just fine for their needs because *you* are unhappy that it won't come
> with tests and expect it to blow up as soon as used there.
>
> I'm afraid that this focus on internal testing, as the only way to declare
> the library fit for consumption, makes even less sense as the simplest
> means of testing I could think of, which is picking as many ISOs as one can
> and churn them through libcdio, did a magnificent job at identifying major
> bugs, that internal tests would probably never have been implemented for
> (Joliet + El Torito, >4GB file in a >4GB ISO, etc.). As a matter of fact,
> had libcdio not come with tests, it probably wouldn't have changed much
> with regards to the patches I submitted.
>
> If libcdio was proprietary, closed source, and expected to receive little
> to no user feedback, I'd agree with you that having a comprehensive set of
> tests for all supported platforms would be crucial. But it is none of that,
> therefore Cathedral building rules need not apply.
>
>
>  You may be cool to the idea that users provide bug testing for you free.
>>
>
> Yes. And others seem to be too. That's called the Bazaar approach. Quite a
> few FOSS projects seem to happily use it, often to great success.
>
>
>  But aside from the fact that as a user I dislike that, as someone who is
>> called on to fix the bugs, I definitely don't want to be the guinea pig
>> for
>> a patch that are fed back to the code. The minimum standard for a patch is
>> that it not break existing tests.
>>
>
> In that case, we might as well be consistent and ask Linux developers who
> submit a patches to make sure that they don't break MSVC tests, if we start
> making such tests available. I could probably provide a guide on how to
> install the freely available WDK in the freely available Wine to run those,
> so there wouldn't be much of a reason not to test MSVC. And as you
> indicated, requiring libcdio developers to install extra development
> components and jump through hoops is fair game, as long as it improves
> testing...
>
> Or should it be acceptable for POSIX users not to test non-POSIX when they
> can, but not the opposite?
>
>
>  People sending patches I would prefer, or
>> perhaps *require*, to run the tests before I do.
>>
>
> There's a difference between encouraging and requiring.
>
> Despite what I seem to imply above, I agree that, time permitting it is
> preferable to check on more than one platform. Time permitting, this is
> also what I try to do (I tend to check MSVC+ MinGW + Linux before proposing
> a set of patches. Also check cygwin from time to time. And this is VERY
> time consumming, especially as autotools are an order of magnitude slower
> on anything Windows). I would expect MSVC-libcdio contributors to naturally
> try to test either one of MinGW or Linux too.
>
> And I have to stress out time as THE major factor in all of this
> discussion. It's arguably the most valuable resource everybody has,
> therefore the one that we must take steps to ensure it is wasted as little
> as possible collectively.
>
> If you are not going to provide straightforward MSVC support, when it has
> been demonstrated that it could indeed easily be provided, then you are
> ensuring that MSVC developers will have to waste their most valuable
> resource.
>
>
>  Furthermore, when someone
>> sends a bug fix, I generally want a test added to demonstrate that the bug
>> is fixed.
>>
>
> If it's a preference, that's fine. But if it's a requirement, I don't
> think you will see as many contributions as you'd like...
>
>
>  ... As long as we have project files that can build the executables or
>>> libraries they were designed for, so that these executables can be used
>>> and
>>> tested with applications, that's fine with me.
>>>
>>
>> Yes, but it's not fine with me. It is not uncommon when someone reports a
>> bug for me to ask if the tests worked.
>>
>
> That's only relevant if they provided a test, which I'd expect few to do,
> because it's time consuming and the person who patched the bug would
> probably have the means to test a real-life scenario and see standalone
> limited duplication as a waste of time they have in short supply.
>
>
>  I suspect that's going to be the case here too. Are you volunteering to
>> rewrite code using CMake?
>>
>
> Of course not, especially since I have seen that the pragmatic approach of
> maintaining 2 sets of project files seems to work quite well in practice
> (libusb). Unless CMake becomes the de-facto standard, forcing everybody to
> become familiar with CMake will be yet another collective time waster =>
> something we should try to avoid.
>
>
>  ... Avoidable complexity
>>>
>>
>> One could make the same argument regarding including MSVC.
>>
>
> Except the audience very much matters. Avoidable complexity for whom? You
> only, or the collective of developers for one platform? My MSVC support
> proposal does not expect anything from POSIX users, especially as I
> wouldn't expect anybody else but me to ever check for breakage there.
>
> he approach you had for the existing MSVC/XBOX support was fine: leave it
> as is, and if found broken, wait for interested people to fix it. Why
> suddenly change it?
>
>
>  Or again, is
>> adding all of the complexity to support worth it? Are you volunteering to
>> be the contact person for MSVC-related problems?
>>
>
> I already indicated I would, again, time permitting.
>
> I think it is pretty much implied that, when someone provides a set of
> patch to add a new platform support, they become the de-facto
> sub-maintainer for that platform, for as long as they can afford such a
> position.
>
> Regards,
>
> /Pete
>
>