On Tue, Jan 31, 2012 at 11:22 AM, Pete Batard <[email protected]> wrote:
> On 2012.01.31 02:50, Rocky Bernstein wrote: > >> I meant to add one other small point which I think should be worth >> mentioning. >> >> In a project like libcdio the extent of its portability is determined >> largely by those who use it and are willing to help out. At various times >> in the past, the code has been more friendly to say BSDI or OSX. If >> support for these has OS's wained, it is because the people who were >> interested in them have lost interest. I'm not expressing this as a good >> or >> bad thing -- just they way things are. >> > > This seems to be true with most of the projects I know of. > > As far as I'm concerned, I'm planning to hang around libcdio even after > I'm done with this exercise and ensure that MSVC/MinGW still works, at > least for the features I added. I may not participate actively in future > discussions, but I'll try to test regularly and give a shout if I anything > broken on Windows. > > > Now, since I'm nearing completion of MinGW/MSVC support, and since > -pbatard cannot exactly be used in its current state for integration (some > patches need to be merged, other have been reverted or amended), this is > what I'm planning to do next: > > 1. Once I consider -pbatard feature-complete for MSVC/MinGW, I'll create a > new branch, most likely -pbatard-integration, based on mainline, and I will > refactor the patches from -pbatard into formal commit proposals for > mainline. > > 2. Once I have a few commits in -pbatard-integration, I'll submit the > patches to the list for review > > This work will probably happen in discrete packets, i.e. submit 2 or 3 > patches, wait for review and only once the existing ones have been > integrated into mainline produce and submit some more. > > If you want to proceed differently, let me know. > This is far more than I expected, so thanks! > > Regards, > > /Pete > >
