2010.02.11 21:56 "[Tiff] TIFF and IJG JPEG 8", by Bob Friesenhahn

2010.02.22 18:29 "Re: [Tiff] Libtiff 4.0.0beta5 Released", by Frank Warmerdam

Lee Howard wrote:
> 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

Lee,

Agreed. I personally skimmed the discussions, but as they seemed to me to be special cases and not to represent regressions in functionality (and the jpeg association) I avoided getting involved.

> 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.

> 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?

There is always hope, but I'm really trying to avoid taking on more libtiff work than I think is necessary for my user base, or to avoid outragously poor filling of the co-maintainer role.

> 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.

Patches (and bug reports) in bugzilla are implicitly in limbo till a developer with commit access accepts responsibility for them. Half the battle is begging, intriguing or shaming a developer into taking responsibility. The ultimate step is to volunteer to be a developer - a competent and apparently sane developer is seldom refused. :-)

> 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.

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.

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!

Sorry for having forgotten you were a committer. I'm a bit abashed, and I do know you as a "competent voice" but to be honest libtiff is not usually my top-of-mind project.

Best regards,
--
---------------------------------------+--------------------------------------

I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam

and watch the world go round - Rush    | Geospatial Programmer for Rent