On Wed, Feb 22, 2012 at 7:30 AM, Pete Batard <[email protected]> wrote:
> On 2012.02.21 12:51, Rocky Bernstein wrote: > >> Since no other comments, looks like we'll go for one release with >> everything. >> > > Great. > > As previously indicated, I'd still prefer to push bitesize set of patches > from what I have in my branch, for you to integrate, and I am more or less > waiting on the previous patchset to find its way into mainline before > pushing some more. > I appreciate the small bitesize patches. There was just a miscommunication in that each bitsize patch should not break existing tests so I got stuck early on. Will try to move forward on this, this week. Last week I was out of town. > I still need to remove cdparanioa from my branch though, which I must say > is a bit of a pain (I would have preferred if this exercise had been left > for after -pbatard integration, since I have quite a few cdparanoia related > commits there and that means I can't just pick that commit and apply it > without conflicts...). This also means that some of the commits from > pbatard-integration need to be redone, since some of the headers changes > touched paranioa files as well. > I'm sorry about this. Removing paranoia was mentioned last November: http://lists.gnu.org/archive/html/libcdio-devel/2011-11/msg00011.html and the git repository had been there since about then. So there had been this existing duplication of code. I'm sorry I didnt' remove this previously > At the moment, I must say I am not sure how you want the -pbatard > integration to proceed. I'd prefer being the one pushing the patches, since > I'm supposed to have the better view of how they can be broken down, Breaking the patches down is different from pushing patches. Breaking the patches down, I totally agree with. Pushing feels a little different. > but doing so against a moving target makes it a bit difficult. Unless a > critical patchfix pops up, could we try to freeze mainline until we've > churned through the -pbatard integration? > Freezing the master for code is okay. The only outstanding issue I am aware of is that Leon was going to revise libcdio.texi for CD-Text. That should be totally independent. > On a side note, please be aware that I had to apply a fix for the commit > from Nicolas (deprecation), since __attribute__ is known to GNU only [1]. > Once we're done with integration, libcdio may need to be more mindful of > GNUisms... ;) > Ok. One problem I have had though is getting people to test releases beforehand. So can I rely on you to handle the MinGW and Microsoft side? > > Regards, > > /Pete > > > [1] http://git.savannah.gnu.org/**gitweb/?p=libcdio.git;a=**commitdiff;h=* > *2956107300f685f8527320cd6e2ffc**650c02d44d<http://git.savannah.gnu.org/gitweb/?p=libcdio.git;a=commitdiff;h=2956107300f685f8527320cd6e2ffc650c02d44d> > > > > >
