[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Rocky Bernstein
Subject: Re: [Libcdio-devel] RFC: Two releases or one?
Date: Wed, 22 Feb 2012 10:35:41 -0500

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: 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]**gitweb/?p=libcdio.git;a=**commitdiff;h=*
> *2956107300f685f8527320cd6e2ffc**650c02d44d<;a=commitdiff;h=2956107300f685f8527320cd6e2ffc650c02d44d>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]