To be clear when I write: I feel like you and/or Portia should be the maintainers of OS2 libcdio.
I mean you should set up a separate repository that you maintain. On Tue, Nov 29, 2016 at 8:02 AM, Rocky Bernstein <[email protected]> wrote: > > Unfortunately, kLIBC v0.6.6 uses the same name as my wrapper. > > I see that SafeDosDevIOCtl went in libcdio August 2014 and was in the 0.93 > release in September. kLIBC 0.6.6 was released the next month in October > 2014. How is it that they happened to use exactly that same very specific > name? Given this has been this way for two years already, it doesn't feel > like this is a pressing issue that has been bothering a lot of people. And > why didn't you mention this earlier? > > > Let's go back to our correspondence two years ago: > > You: > > Hi/2. >> Rocky Bernstein wrote: >> > Ok, then you can be responsible for OS/2 . That means that you will be >> > *expected to test, in advance, releases*. [emphasis added] Note that >> this is a change from the >> > laxness we've had in the past with respect to releases. >> > >> No problem. >> > 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. >> > >> Ooops... I feel the very much responsibility. ^^ >> >> > Ok. There was a release this year and that would have been an ideal time > to get this change in. You blew it. > > > > So what I wrote in over two years ago is still true: > > About a month and a half ago we were discussing dropping libcdio's OS/2 >> driver altogether. See http://lists.gnu.org/archi >> ve/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. > > > And that is still feels like the situation now. There have been API > changes and there are ones that may come up. > > In the past, I suggested setting up libcdio developer access to OS/2. That > hasn't happened. > > So given the history, your lack of involvement and commitment, the > smallness of the OS/2 libcdio community, the lack of libcdio developer > access, and the general lack of libcdio resources, I feel like you and/or > Portia should be the maintainers of OS2 libcdio. I'll be happy to > contribute to that. > > That said, I welcome comments from you and other people on the libcdio > developers mailing list. > > > On Tue, Nov 29, 2016 at 6:55 AM, KO Myung-Hun <[email protected]> wrote: > >> Hi/2. >> >> Rocky Bernstein wrote: >> > At the risk of going down a rabbit hole of OS2 stuff which I doubt many >> > people use, (you are the only one I am aware of that has *ever* used >> > libcdio), I wonder about this. Is there harm in having the wrapper >> there? >> > >> > The last OS2 release was in 2000 with and end release date of 2006, a >> > decade ago. >> > >> > Removing the code above would force people to use >> > <https://trac.netlabs.org/libc>kLIBC v0.6.6 < >> https://trac.netlabs.org/libc>, >> > which I guess is an add-on. >> > >> > I'd be grateful if you'd explain the harm of keeping the old code. >> > >> >> Unfortunately, kLIBC v0.6.6 uses the same name as my wrapper. So call to >> the wrapper leads into 'not enough memory' due to a recursive call. >> >> kLIBC v0.6.6 has backward compatibility. As well as kLIBC v0.6.6 >> provides older versions of DLLs forwarding to v0.6.6. So even if people >> upgrade their kLIBC to v0.6.6, they will not encounter any problem at >> all. And most of all OS/2 users are already using kLIBC v0.6.6. >> >> Not enough ? >> >> -- >> 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 >> >> >> >
