Re: [liblo] [ann] liblo 0.27 released

On Tue, Jul 9, 2013 at 10:51 AM, J. Liles <mal...@gm...> wrote:
>
>
>
> On Tue, Jul 9, 2013 at 7:07 AM, Felipe Sateler <fsa...@gm...> wrote:
>>
>> Hi,
>>
>> On Tue, Jul 9, 2013 at 5:33 AM, Stephen Sinclair <rad...@gm...>
>> wrote:
>> > On Mon, Jul 8, 2013 at 6:23 PM, J. Liles <mal...@gm...> wrote:
>> >> On Mon, Jul 8, 2013 at 9:14 AM, Felipe Sateler <fsa...@gm...>
>> >> wrote:
>> >>> On Mon, Jul 8, 2013 at 11:41 AM, J. Liles <mal...@gm...>
>> >>> wrote:
>> >>
>> >> In that case I would like to point out that this ABI breakage was
>> >> noticed by myself and others who did not use the function in question.
>> >> I assumed it was intentional (there had been some back and forth on
>> >> this list at the time about changing some functions in the API). The
>> >> incompatibility actually caused a  minor flame on LinuxMusicians.com
>> >> when some individuals took the ABI breakage as an excuse to denigrate
>> >> all things OSC. FYI, I have a 64-bit system.
>> >
>> > Oh that's great.  As maintainer of the package this really grinds my
>> > gears.  I waited 4 years between releases trying to make sure it was
>> > perfect, but basically between myself and Camille, we are the only
>> > ones actually regularly testing the master branch, and I simply don't
>> > have a server farm of every architecture under the sun to test on.  A
>> > little more testing help from the OSC community would be appreciated
>> > rather than people silently dismissing the whole thing when I make a
>> > small mistake.
>>
>> I wouldn't put much weight in unsubstantiated claims by random people.
>> A private symbol dissapearing is hardly a binary compatibility issue,
>> but rather a "I want my program to be fragile" issue on the part of
>> depending applications.
>
>
> Excuse me, but I am not a random person, I am the author of 4 large
> application that use liblo, and I am responsible for the inclusion of liblo
> in almost a dozen more.

I'm sorry. The above was way too aggressive and wasn't intended (and
the "randomness" wasn't meant as an insult). What I mean is that
unsubstantiated claims of "doesn't work" are useless, and therefore
one shouldn't waste time and effort into looking into them. Decent bug
reports are worth looking into. "Doesn't work!!!11" is not. IMO, of
course, and YMMV.


>> >
>> > Anyways, in the future I'll be sure to do release candidates instead
>> > of just putting it out there directly, since obviously my testing
>> > approach is not thorough enough.  As a maintainer, it's annoying to
>> > have several bug reports come in immediately *after* a long-awaited
>> > release, instead of before.
>>
>> I'm sorry I didn't report before, but the usual excuse of lack of time
>> applies.
>>
>> >
>> > By the way, on the technical side, I don't see how omitting an
>> > internal function from the ABI would cause breakage?  Can someone
>> > explain this to me?
>>
>> It can only cause breakage if someone decided to use said undocumented
>> function. So, either the program was asking for breakage, or nothing
>> bad happens.
>>
>
>
> But that is not the reality.
>
> Perhaps I haven't been clear enough. I don't know the cause of the breakage.
> This is the situation:
>
> When liblo 0.27, myself and several distro packagers tried it. I was excited
> about the possible performance improvements. However, when liblo 0.27 was
> installed, the OSC functionality stopped working in every program on the
> system that used it--they all had to be recompiled against 0.27 in order to
> work. Now, you can call that what you will, and it's true that I never
> investigated the issue thoroughly enough to get to the bottom of it. If not
> an ABI change, it certainly had the same effect as one.

This looks more like a true implementation bug rather than a binary
compatibility issue. Missing symbols, invalid parameters, and other
binary issues would cause the hosts to crash, not silently drop OSC
functionality.

--

Saludos,
Felipe Sateler