LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
January 2011
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
2011.01.04 21:39 "[SPAM WARNING]Re: [Tiff] Regression in libtiff 4.0 CVS when creating a JPEG RGB contig", by <peter.bauer@datamine.ca>
Hi, I submitted an issue/question about 10 days ago and have not seen it sent out. Not sure why - I just subscribed to this group. It had to do with being able to add and set the value of the focal_length tag to an image. I've been able to add tags, but this one never gets written to the image (no error occurs either). Regards, Peter Bauer -----Original Message----- From: tiff-bounces@lists.maptools.org [mailto:tiff-bounces@lists.maptools.org] On Behalf Of Even Rouault Sent: Tuesday, January 04, 2011 3:50 PM To: Lee Howard Cc: tiff@lists.maptools.org Subject: Re: [Tiff] Regression in libtiff 4.0 CVS when creating a JPEG RGB contig I don't want this to turn into a flame discussion and I certainly appreciate your work on libtiff. I was indeed a bit surprised to see the change we discuss in this thread in 3.9 branch as it seemed to belong more to the "improvement" category than to the "bug fix" one, but of course, I'm biased since I only use libtiff based software... My experience with GDAL maintenance confirms what you said : deciding what goes into stable branch or not is a non-trivial (and non-scientifical) exercice. Sometimes I think : "well, this is indeed a bug fix, but I fear it is too risky for the benefits, so just let's put it into the trunk". Depends on how brave I feel that day ;-) But to be fair, sometimes we also push things into the stable branch that can be considered as enhancements, like providing compatibility with a newer version of a third-party library. So we don't have a clear policy on this either. From my point of view, as you underlined the lack of man power for libtiff maintenance and the overhead caused by 2 actives branches, the 3.9 branch could receive essentially just the critical security fixes (what is a critical security bug is another issue...). This would serve as a repository to collect the security bug fixes provided by the vendors, and perhaps """obviously"" non- risky bug fixes". Which somehow would help limiting the risk of regressions. As I see it, a side-effect of fewer changes in 3.9 branch would be hopefully a wider testing and adoption of the 4.0 branch, the message to users being "the cool things happen now in 4.0 branch, so fetch it and tell us how it works to help releasing it soon"... Now that it is in debian-experimental, we can perhaps be a bit optimistic :-) Best regards, > > Someone would need to define for me what "stable" means for me to be > able to respond properly. My understanding is that 3.9 is a > "maintenance" branch and therefore bug-fixes go there as well as > critical security fixes (or whatever one may designate should only be > committed to a "stable" branch). > > As I see it, users will look for the latest round of bug fixes in the > latest release. Until 4.0 releases the 3.9 branch is necessarily still > the place where users are going to turn to look for bug fixes. > Therefore, until the 4.0 release occurs I can't see how 3.9 could be > resigned to receiving only a select subset of bug fixes. > > I can certainly understand that at this point where we have a > development branch and a maintenance branch that any new feature > enhancements should go only into the development branch. But in my mind > bug-fixes go in both branches at least until the development branch cuts > a versioned release. > > If I am wrong in this, then I'll happily ignore 3.9 completely. I can't > be expected to know when a bug-fix is deemed critical-enough to merit > committal to a branch that only gets some certain kinds of bug fixes. > > My broader opinion is that our development team is far too small to > warrant more than one code branch and that it's really the distributions > that provide a meaningful implementation of "stable". I don't think > it's within the developer's capabilities to define what is or isn't > "stable". > > Thanks, > > Lee.