LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
February 2010
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
2010.02.22 17:45 "Re: Libtiff 4.0.0beta5 Released", by Lee Howard
Frank Warmerdam wrote: > Lee Howard wrote: >> Frank Warmerdam wrote: >>> Could people please raise their voice here on the list >>> if there is a reason not to proceed to a release candidate right >>> now? Would >>> anyone like to review the open bug list and see if they find >>> something that >>> should be treated as release critical to fix? >> >> This is critical for me: >> >> http://bugzilla.maptools.org/show_bug.cgi?id=2135 >> >> This isn't critical, but it's important to me: >> >> http://bugzilla.maptools.org/show_bug.cgi?id=2029 >> >> It's my opinion that both patches can be committed immediately. > > Lee, > > I have reviewed both bugs, and I don't see that either relates to a > regression > from earlier versions of libtiff. Also, neither relates to an ABI > issue that > ought to be dealt with now as it would be hard to change later. > > As such, it is hard for me to construe these as release critical. As > they > are in fairly fragile code I'm not terribly comfortable they can be > applied > without significant risk. > > I'm also deathly afraid of the jpeg code. :-) > > Perhaps another developer would like to incorporate them and take > responsibility? Frank, Although I never discussed 2029 on this list, I did point at the bugzilla 2135 report about two months ago: http://www.asmail.be/msg0054588867.html I re-solicited the same report one month ago: http://www.asmail.be/msg0054589825.html This was preceded by an attempt to generate discussion: http://www.asmail.be/msg0054584515.html None of these generated any further on-list developer discussion about the proposed patch. However, regarding the underlying problem, there was a bit of developer discussion almost three months ago: http://www.asmail.be/msg0054683840.html I understand your response to mean that you wish to promote the current 4.0 beta to a release-candidate rather than making changes that would generally require another beta. I have nothing against this. I am completely supportive of whatever is required to speed up the pace of libtiff releases. My response, however, was made so that I have some idea of what to tell my users: whether they can use 4.0.0, or 3.9.3, or whether they can expect to be able to use 4.0.1, or whether for the foreseeable future they'll have to continue to patch and rebuild or use pre-patched sources from me. I'd really like to quickly get out of the business of distributing "custom" versions of libtiff to my users. So if if it's not going to happen in 4.0.0, then I can live with that, but do I have any hope of seeing the patches make it into 4.0.1 or 3.9.3? My concern is that there is seems to be some expectation or requirement of other developers chiming in on the proposed changes when they have not done so during the last two months with solicitations for discussion in three different postings to this mailing list during that time. I would think that at some point in time someone just has to say "time's up", and then either the proposed changes are committed (due to lack of objections) or the proposed changes are rejected (due to lack of support), depending on what the project policy is. My interpretation of your response is that patches in limbo (and there are a number of them on Bugzilla) are in a state of rejection until those who care about it drum up enough developer support to get the patches committed. The Bugzilla list isn't terribly long at the moment (60 open bugs), but it really doesn't seem to get much attention, and patches posted to this list really aren't getting picked up independently, either (I just posted one such in bug 2162). Thanks, Lee.