Re: [Libcdio-devel] OS/2 patches

[Rocky Bernstein]

Ok, then you can be responsible for OS/2 . That means that you will be
expected to test, in advance, releases. Note that this is a change from the
laxness we've had in the past with respect to releases.

If you disappear and there is no one else to take responsibility, the
ability to test OS/2 disappears, then OS/2 support in libcdio may disappear
as well.

> What about testing an OS getopt first ?

We have 7 or so drivers that work with the supplied getopt.c and one that
doesn't. And for that one driver we have maybe two people who use that.
Even here, their use is probably infrequently for say Mplayer while the
uses elsewhere span audio ripping, other media players, making boot CDs and
lots of other things I probably don't know about. So guess which way causes
the least disruption to the majority of users and developers?

Couple that with the fact currently we don't have rigorous tests either
getopt routine to make sure that works.  It's possible, though that in one
of the larger integration tests, we might catch a malfunctioning getopt,
but I wouldn't want to count on that.

If you want to start writing a test suite for getopt whether it the
provided one or the OS-supplied one, we can reconsider. But given things
are currently the way they are, if the supplied getopt works, it's better
to to use that, because assuming the getopt.c compiles as it was intended,
we *know* what the intended behavior is.



On Mon, Jul 28, 2014 at 10:12 PM, KO Myung-Hun <address@hidden> wrote:

>
>
> Rocky Bernstein wrote:
> > Sorry for the delay. Things have been busy for me.
> >
>
> No problem. ^^
>
> > It is interesting to hear back after the 5 or so years. About a month
> and a
> > half ago we were discussing dropping libcdio's OS/2 driver altogether.
>  See
> > http://lists.gnu.org/archive/html/libcdio-devel/2014-06/msg00004.html
> >
> > What motivated this was the desire to change the API to add
> get_track_isrc
> > and Robert Kausch mentioned he had no way to test OS/2. In that, we
> > realized that basically no one *is* actively testing OS/2.
> >
> > Aside from yourself and possibly Natalia, do you know anyone else that is
> > using this?
> >
>
> I don't know. But those who want to build MPlayer with audio cd
> supports, would be using libcdio.
>
> > Given the low activity and difficulty for finding developers and testers,
> > I'm inclined to have this maintained by you and Natalia in separately.
> She
> > already has a fork on github of libcdio-paranoia.
> >
> > If OS/2 is to survive in libcdio, someone needs to commit to handle
> > problems and API changes as such things arise. Are you willing to commit
> to
> > this?
> >
>
> Of course. Five years ago, it's me to submit OS/2 patches as you know. ^^
>
> > Lastly, on the first patch. It has to do with deciding on whether the use
> > the libcdio-supplied getopt.c,and this is based purely on OS. OS/2 is the
> > only one to not used the supplied getopt.c
> >
> > Rather than have a test by OS, I'd prefer a test to compile the supplied
> > getopt;  if that fails, then run a test to see if there is an OS getopt.
> >
>
> Ok. What about testing an OS getopt first ? I think, it's better to
> consider libcdio-getopt as a fallback.
>
> >
> >
> > On Sat, Jul 26, 2014 at 11:50 PM, KO Myung-Hun <address@hidden> wrote:
> >
> >> Ping ?
> >>
> >> KO Myung-Hun wrote:
> >>> Hi/2, long tiem no see. ^^
> >>>
> >>> I attach the patches to build libcdio and to enhance memory usage on
> >> OS/2.
> >>>
> >>> Review, please...
> >>>
> >>>
> >>>
>
> --
> KO Myung-Hun
>
> Using Mozilla SeaMonkey 2.7.2
> Under OS/2 Warp 4 for Korean with FixPak #15
> In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM
>
> Korean OS/2 User Community : http://www.ecomstation.co.kr
>
>
>