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 19:32 "Re: Some security fixes from RHEL", by <ron@debian.org>
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. 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 Debian and others will refuse to distribute it in their stable (read: > "stale") releases then that is their decision, and they're welcome to > patch away at a previous release. Well one man's stale is another mans absence of pointless rework caused by sloppy library releases. 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; > 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. Debian calls that Sid, named after the kid who smashes everyone's toys (but plenty of people run it's snapshots quite happily on production servers). That mode is all fine and good in some circumstances, and your enthusiasm for that sort of thing is most welcome, but it's not really appropriate for a stable release candidate. The important obligation there is that you do not break other people's existing code if you have to make an update. I'd repeat that in all caps, it really is important, but I hope you get the point without that. 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. The busy-work and development belongs on the 4.0 branch as I understand it. The stable branches should be getting little more than the most critical fixes that don't break existing apps. If you do or must break them, you need a transition plan. Without that, all your good work will just make someone else curse you for taking a day (or more) of their time they weren't ready to give up for this. There are far more of them than you, so there is a huge multiplier in time wasted if you screw something up. 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. 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 ... release-develop-release-develop isn't a cycle, it's a linear flow. When you do it right it's smooth, when you don't it gets turbulent and sometimes people get motion sick. If the abi was broken and that was not intentional, then it's a bug, of the release critical variety that must be fixed before a new public release. If it was intentional and you decide to keep it, then you have some other work to do to ensure a smooth transition for existing users. I don't really mind which you choose, the only big mistake you might make is not choosing either and blindly releasing to some arbitrary time line, not knowing what you broke or whether you intended to. I don't want to rain on your enthusiasm or your parade, but please do consider that there is more to good release management than just meeting self-set short deadlines. And also who your target users for these releases really are. What proportion of them are actually downloading and building libtiff themselves, compared to those getting their updates from a distro. How may of those getting them directly from here actually use the tarballs, or do they just work out of cvs instead? If you say 'to hell' with the distros, would you actually be saying 'to hell' with the vast majority of your supposed users that you were ostensibly rushing the releases out for in the first place? If you give the distros what they need, they can shield you from a lot of that. It's what I'd be doing -- but you're the one who has volunteered your time, so I'm not going to tell you how to spend it beyond this gentle admonition. We'll see how it goes ;) Cheers, Ron