LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
August 2008
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2008.09.03 21:39 "Re: Some security fixes from RHEL", by Lee Howard
Ron wrote: > On Wed, Sep 03, 2008 at 10:20:29AM -0700, Lee Howard wrote: > >> Bob Friesenhahn wrote: >> >>> We should make sure that 3.9 is ABI/link compatible with previous >>> releases if possible. Otherwise Debian and other distributions will >>> refuse to distribute it as updates to their stable releases. >>> >> I have no problem with seeing 3.9 be ABI/link compatible with previous >> releases, but I don't want to see a 3.9 release blocked by that >> condition waiting on code work that will not be forthcoming. >> > > Uhm ... it would probably be valuable to realise how much extra work > you will _create_ for other people if you insist on rushing things out > as a 'stable' release without checking them properly. > Don't misunderstand me. I'm not insisting on rushing anything. I am suggesting that libtiff step out of this stalemate. This ABI/link compatibility issue has been talked about for three months now with no resolution. Up until this thread I didn't see any active discussion or work on it, either. So, if we guess that no ABI/link compatibility work will be forthcoming ever, then we have two choices: 1) release with an ABI incompatible with 3.8, or 2) do nothing. I wish that I were able to understand why the ABI were broken and what the consequences would be of reverting code changes. Unfortunately, I didn't write the code, and learning the code is really outside the scope of what I can commit to do any time soon. > 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. However, I don't think that I'm managing releases or dso versions. 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. > I get the feeling I should point out a > fundamental attribute of this word 'stable' that lots of people bandy > about and seem to think has some connection to number of bugs. But it > has a very simple and easy to follow definition, the most directly > applicable being: > > stable > ... > 5: showing little if any change; > 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? >> Meanwhile, I think that we have an obligation to the rest of the >> libtiff-using community to cut code releases as development occurs. >> >> The release-develop-release-develop cycle is co-dependent. If you stop >> releasing then development also slows (especially in the form of >> contributions). >> > > What you are talking about is a development branch. Sure. And as I understood it 3.9 was originally to be the same as 4.0 but only without BigTIFF. When did 3.9 become "stable" and 4.0 become "development"? > If you want developers to use > your code you _have to_ stop changing it so they can get on with > their own work and not have to follow what you are frantically > doing every day. > I agree entirely. I understand this. Believe me, I do. I am a code developer myself, and in one application I'm stuck on libtiff 3.7.4 for reasons that I haven't bothered to debug. My point, however, is that there needs to be an active path for newly developed code to make it to public release in a regular and frequent way. Library users who are happy with the library code in 3.8 don't need to go to 3.9, do they? > The busy-work and development belongs on the 4.0 branch as I > understand it. This is not what I have understood at all. For example, JBIG support is in 3.9 where it wasn't in it in 3.8. My understanding was that 4.0 and 3.9 were only to be differentiated by BigTIFF. > The stable branches should be getting little > more than the most critical fixes that don't break existing > apps. Does libtiff even have a stable branch? > You might think of it as being 'stale', but to the people who > are perfectly happy that their code currently does everything > they want it to and would like to just get on with _using_ it > instead of constantly 'fixing' it, it's something approaching > pure heaven. And all too rare. > I understand, really, I do. Isn't the 3.8 to 3.9 indicator clear enough to show that things are changing? > Please talk to Jay, and listen to what he needs. He represents > a large portion of your users and he's not a fool. Debian has > already had to independently bump the soname and manage a > transition because incompatible changes slipped in to earlier > releases. It would be really good have a plan to get all that > back in sync again. Understanding why Debian does what it does > rather than dismissing it as some irrational dogma _will_ save > everyone a lot of needless pain. We've collectively made far > more mistakes than you'll live long enough to repeat for > yourself. We'd generally much rather share some clues and > user feedback than have to grump about how you keep making the > same old tired mistakes that new people keep repeating over > and over and over again ... I think that you're beating me up needlessly. If you don't want me (a "new people") to try to help you could have said it more directly. I'll gladly go away. Thanks, Lee.