2010.02.22 19:41 "Re: [Tiff] Libtiff 4.0.0beta5 Released", by Lee Howard

Lee Howard wrote:

> I understand your response to mean that you wish to promote the

> beta to a release-candidate rather than making changes current 4.0

>> 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),

> really doesn't seem to get much attention, and patches posted but it

> really aren't getting picked up independently, either (I to this list

> one such in bug 2162). just posted

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.