[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, hea
From: |
Pete Batard |
Subject: |
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming |
Date: |
Tue, 20 Mar 2012 12:15:56 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 |
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
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, (continued)
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/11
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/11
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/12
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/14
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/14
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/15
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/15
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/18
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/19
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/20
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming,
Pete Batard <=
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/05