Re: [Libcdio-devel] RFC: Two releases or one?

[Rocky Bernstein]

On Wed, Feb 22, 2012 at 7:30 AM, Pete Batard <address@hidden> 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>
>
>
>
>
>