Re: [Libcdio-devel] RFC: Support for non-POSIX systems?

[Pete Batard]

On 2012.03.23 00:54, Rocky Bernstein wrote:
> More central to the main point was this weird distortion:
>
>     Treating MSVC as a minor platform that can be brushed aside ...
>
> I wondered for a while where that mis-impression comes from.  I suppose is
> it partly from the remark I made that perhaps not supporting MSVC is not a
> bad thing.

Indeed, this is exactly where it came from, as well as the following 
statement:

"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."

> Rather I was thinking along a very narrow set of concerns of whether how to
> manage the project when there are two very different philosophies of the
> project.  I can't accept the means by which you work by any more than you
> are willing to accept mine.

Well, what I have a problem with is that, up until know, you seemed to 
be OK with an actual broken state of MSVC support, that also came with 
no tests whatsoever.

Therefore, I fail to comprehend how, now that we can bring MSVC to a 
state where it actually works, it has somehow become a less desirable 
than the previous situation, and should warrant a fork as a result 
(since you are effectively advocating a fork).
We're going from "not working, with no tests" to "working, with no 
tests". How is this expected to be more problematic for libcdio users to 
the point that it should be removed?

And I am using the term "working", knowing that you may object about 
calling software "working" outside of running a series of extensive 
tests. But if you do object, then I would very much object to libcdio 
having ever been declared "working" as I did find major issues, that 
weren't MinGW, MSVC or UDF related, and for which no tests existed.
Even as all the tests passed, as far as I am concerned, I could say that 
I found libcdio "non-working" when I started using it. Furthermore, 
since this may be important to explain our divergence of philosophies, I 
will assert that software can only be declared working for the specific 
scenarios it was tested with, but not further, which, in the case of 
MSVC, would be the 2 sample applications provided, and for POSIX, the 
series of existing tests. Or if you want to formulate it another way, 
software is either in 2 states: "working until proven otherwise" (or 
more realistically "non-working, but not yet proven otherwise") or 
"proven non-working". As far as I am aware, MSVC is currently in state 
1, no matter how many tests were ran for it.

As to accepting that your philosophy is as valid as mine, sorry but I do 
see a major difference between trying to impose something that is going 
to cost somebody else's time (such as producing a batteries of tests 
before declaring MSVC fit for formal integration, or requiring the 
installation of foreign components), versus something that isn't.

You are trying to force somebody to write tests to *continue* to have an 
existing platform included in mainline. I'm not forcing you do do 
anything with regards to MSVC. I'm not asking you to test it. I'm not 
asking you to support it. I'm not even asking you to pay attention to it 
in any shape of form if you don't want to, unless you find that the 
proposed changes impact the platforms you want to concern yourself with 
(which, for the most part, I tried to ensure wouldn't be the case). Only 
the version.h has an actual impact, because I didn't think it would be 
seen as much of an issue, and I am going to fix that. The rest is just a 
blank set of additional macros and separate files, that are designed for 
both the lowest footprint and least amount of maintenance.

> For example, the importance of having automated tests that users can easily
> run.

Something that costs somebody time.

> Or the burden of having programmer install additional tools -- and
> what they are -- when working from the development repository.

And, there again, something that costs somebody time.

In both cases, what you advocate is going to cost someone else's time. 
In both case, what I advocate is designed to save someone else's time.

Unless you want to consider time spent as a non issue, I fail to see the 
approaches we advocate as having the same weight.

> I think it clear that we're not going to bridge this gap easily in the near
> future.

Indeed. I don't see us bridging the gap if one of us fails to consider 
that users and contributors time, and how to save it, must be factored 
when it comes to deciding the direction a project should take.

> That's why I suggested the branch which I was hoping would be seen
> as more official and with closer integration than say forked project

A branch is a fork, no matter how you look at it.

> It is what we've done with paranoia code.

Again you're trying to compare elements that are very dissimilar.

The paranoia fork is removing files from one repo and moving them to 
another repo. So, in essence, it results in 2 separate sets.
An MSVC fork would be *duplicating* files in boths repos, and having to 
keep them in sync. There are major problems in doing that. For what is 
worth, more than 2 years in, and libusb is still dealing with the result 
of a similar policy, so I have a very good idea of how damaging it can 
be for users of a Free Software project.

> So in sum a lot of the discussion has been to try to come up with one set
> of rules for two different philosophies or trying to convince one person to
> follow some other project or software methodology. For the short term, I
> can't see how to do it short of something like treating these as two
> possibly strongly aligned or related projects.

For the short term, I don't think you have that strong a point, when 
your philosophy is expected to add an additional cost in time to both 
contributors and, more importantly, users of the project.

I'd like to be able to put it more delicately, as well as deflate the 
issue at hand, but I cannot help to see what you advocate as anything 
but damaging for libcdio users, and therefore not something I can really 
keep silent about.

Regards,

/Pete