2008.09.03 22:35 "Re: [Tiff] Some security fixes from RHEL", by Ron

On Wed, Sep 03, 2008 at 02:39:02PM -0700, Lee Howard wrote:

If you have a reason to break the ABI, and want to do that willfully, that's fine, but if you don't know how to check that, or what you should do to manage the release and soversions when you do that, then I fear your enthusiasm is going to lead you astray if you don't come up to speed on those things.

If you would care to educate me on this - or at least point me in a direction where I could learn what it is that you want me to understand on this, then I will gladly learn.

This is probably a good starting point: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

Not everything there is directly relevant to what you have planned, but the stuff on library versioning and compatibility is pretty universal.

You could try here if you really want to melt your brain on the subject (: http://people.redhat.com/drepper/

However, I don't think that I'm managing releases or dso versions.

You were talking about hurrying up a new release, that implies someone needs to take on that responsibility for it, if it's not going to be you.

I thought that the scope of my commitment was to contribute what I could. If my abilities will be a burden more than a blessing in the world at large then I will happily walk away and continue managing my own private build in my own tiny world.

That's not at all what I was trying to say. Please don't think I'm beating on you, your initial comments just got me a little worried that you were thinking of applying 'bleeding edge' release principles to ostensibly stable code.

Why does 3.9 need to have little if any change from 3.8? Isn't the point of a new code release to have had change?

My impression was 3.9 was supposed to be a stopgap with important fixes while 4.0 had some more time to shake out any remaining issues with BigTIFF.

There is a difference between implementation fixes and interface changes. The former are (almost) always good, the latter always come at a price. It seems to not be clear yet whether it's a price we have to or want to pay for this particular point release. And that's not really my call to make here.

As I said, I'm not going to complain whichever way you choose to go on this one, so long as it's an informed and willful choice and there is reasonable consensus from the folks here that it's the best one in the circumstances.

Most of the people here are a) very busy, b) very patient. It should not be underestimated how valuable those traits are for producing a high quality production library, but that's not to say that your fresh enthusiasm is unwelcome.

I just think the important question is not "how long before we should release", but rather "what still needs to be done before we are happy to release". When the answer to the latter is a resounding 'nothing I can think of', then it's a good time to give people the final cooling off period of the former.

It's also a completely separate question from 'what can I do to help today'. And I really, really, don't want to discourage you from asking that one...

Cheers,
Ron