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 19:41 "Re: Libtiff 4.0.0beta5 Released", by Lee Howard
Frank Warmerdam wrote: > Lee Howard wrote: >> 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. > > I am concerned that incorporating the changes without reviewing the > carefully, and perhaps having another beta would be somewhat risky. > And they don't seem to be have any special priority related to the > 4.0 release. They are just bug fixes and enhancements that could > be done anytime or have been done anytime in the last decade. Okay, so I understood. Since I've now committed the changes I think that the completely proper thing is to release another beta, but I personally find the propriety of release procedure self-defeating in many cases such as this. I would rather see current CVS be cut as 4.0.0-rc1 than to see another beta. I think that the changes would get better pre-release exposure that way than to cut another beta. > >> 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). > > That is all true. I do try to skim the bugs, and I do fix bugs that fall > into my area of interest from time to time. I would humbly suggest that > most bugs or enhancements now days tend to fall outside areas that any > of the existing developers are keen to accept responsibility for. I'm willing to take responsibility for reviewing patches, testing them, committing them, and then backing them out if they cause trouble. I can't pretend to be able to provide fixes for most of the bugs reported, but I certainly am willing to review, test, and commit. I hope that nobody is expecting more than that. > Libtiff is, to my mind, an unambitiously maintained project. The > existing > developers address pain points for themselves, and will generally try and > fix problems that are significant regressions from previous releases, but > we aren't all that keen on taking on more work for the sake of libtiff. > With respect to the others who do certainly go beyond this from time > to time, > we just don't seem to consider libtiff our front-and-center project on > which > we lavish love, attention and time. I certainly understand. And I am completely in the position you describe: I don't have a lot of motivation in trying to address things that are beyond the scope of my day-to-day work. However, the general health of the libtiff project and community *IS* important to my day-to-day work, and so I'm willing to contribute as I can for that purpose. > > It is particularly unfortunate when someone like you does a good analysis > of an issue and prepares a patch and we are just to chicken even apply > it. > I'm personally hoping to drive you apeshit enough that you will become a > commiter. :-) > > /me goes through COMMITERS list. > > Hey, you already are a committer! No one has objected - why don't you > just go ahead and commit the changes? Sooner might have been better, and > after 4.0 might also be a bit safer, but I'm not going to stop you from > doing it right now as long as you are willing to throw yourself into the > gap if things go wrong! I've committed the changes for bugs 2135 and 2029, and I'm willing to immediately begin working through the patches on Bugzilla to review, test, and commit them. However, I think I need to hold off on the latter until we know if we're headed into a release candidacy or into another beta. If the community is willing to tolerate another 4.0 beta then I'm willing to do the reviews/tests/commits this week. If current CVS will become a release candidate, then I'll hold off on the Bugzilla work-through until after the 4.0 release. My preference would be to get the patches committed and cut another beta... if the community can agree to test the beta and quickly (i.e. within one month) move towards release candidacy. Also, I'm very much interested in seeing a 3.9.3 release that coincides with the 4.0.0 release. I suggest that that would likely be the last 3.9 release. (Maintaining multiple branches is rather burdensome.) Thanks, Lee.