Re: [liblo] [ann] liblo 0.27 released

On Tue, Jul 9, 2013 at 4:51 PM, 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.

No worries, I am certainly interested in fixing bugs as they appear.
Currently I can't since I have to date been unable to test on a 64-bit
machine and reproduce this problem.

Hopefully I'll be able to soon enough.


>> > 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.

I understand.  To be clear, I'm not all that upset, but it's just
that, knowing that liblo is used in many applications, I really did
try to ensure that this was a fairly stable release.  I was very
surprised to learn about some problems it caused, since there had been
basically no reports of problems from the master branch on the mailing
list.

Beyond my own testing and reports from other people using the master
branch, I don't know what I could have done to avoid this, other than
testing everyone else's software.  However, the same excuses apply
here in reverse... lack of time, and more importantly, not having the
interest to compile a bunch of dependencies to get an experimental
version of someone elses software working just so I can test mine.

>> > 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.

Okay, but this seems like an expected cycle for me.  I put out a
release, distro maintainers test it, and then report back that it's ok
for inclusion.  If it's _not_ ok, I hope they have the sense not to
include it and instead report some bugs upstream, which is what's
happening now.  I'll fix them and put out 0.28, and everything is
dandy.  In the future I'll use RCs for this purpose.  I didn't think
it worth it this time since all tests checked out for me, which was
obviously a mistake.

So I am not that put off by what's happening now, but I only wish
people wouldn't take it as a bad sign, but rather as a normal part of
the development cycle.  Calling it an RC would have made this clear.

What I did take exception to was only that there was apparently a big
discussion about the release on a separate mailing list and the first
I've heard of it is after the software has been removed from the
project.  (Why? If 0.26 was working fine, just keep it, and report the
bugs upstream.. communication, people!)

By the way, what performance improvements are you referring to? I
don't recall including anything about performance improvements in the
release notes.

> I apologize for not bringing it to everyone's attention sooner--I figured
> that since the problem was quite obvious it was either intentional or would
> be noticed quickly. I maintain too much software of my own to be able to
> spent a whole lot of time debugging other projects.

It was only "quite obvious" if it actually triggered on your system.
I guess my particular testing platform didn't trigger this bug, or my
testing methodology was not good enough.

Anyways, mostly my testing consisted of "make test".  I also used
"icheck".  I admittedly didn't do a lot of "install distro X and
replace the liblo binary" kind of testing.  This takes time and
resources, which I don't have.

Steve