Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-q.b-one.net (mx-q.one.com [91.198.169.248])
	by mail9.b-one.net (Postfix) with ESMTP id 20DB740014C
	for <info@awaresystems.be>; Tue,  4 Jan 2011 22:04:31 +0100 (CET)
Received: by mx-q.b-one.net (Postfix, from userid 106)
	id 109D930A80E9; Tue,  4 Jan 2011 22:03:58 +0100 (CET)
X-Virus-Scanned: by one.com
X-Spam-Flag: NO
X-Spam-Score: 2.796
X-Spam-Level: **
X-Spam-Status: No, score=2.796 tagged_above=0 required=4
 tests=[WEIRD_QUOTING=2.796]
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144]) by
 mx-q.b-one.net (Postfix) with ESMTP id 36A14308561C for
 <info@awaresystems.be>; Tue,  4 Jan 2011 22:03:57 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by
 lists.maptools.org (Postfix) with ESMTP id 189321B0096; Tue,  4 Jan 2011
 16:02:48 -0500 (EST)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by
 lists.maptools.org (Postfix) with ESMTP id 60D4E1B0095 for
 <tiff@lists.maptools.org>; Tue,  4 Jan 2011 15:50:08 -0500 (EST)
Received: from even-desktop.localnet (unknown [88.162.84.61]) by
 smtp6-g21.free.fr (Postfix) with ESMTP id BC8B782283; Tue,  4 Jan 2011
 21:50:03 +0100 (CET)
From: Even Rouault <even.rouault@mines-paris.org>
To: Lee Howard <faxguy@howardsilvan.com>
Date: Tue, 4 Jan 2011 21:50:03 +0100
User-Agent: KMail/1.13.2 (Linux/2.6.32-27-generic; KDE/4.4.2; x86_64; ; )
References: <201101011441.00281.even.rouault@mines-paris.org>
 <201101042020.45499.even.rouault@mines-paris.org>
 <4D237963.5050102@howardsilvan.com>
In-Reply-To: <4D237963.5050102@howardsilvan.com>
MIME-Version: 1.0
Message-Id: <201101042150.03674.even.rouault@mines-paris.org>
Cc: tiff@lists.maptools.org
Subject: Re: [Tiff] Regression in libtiff 4.0 CVS when creating a JPEG RGB
 contig
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
 <mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
 <mailto:tiff-request@lists.maptools.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

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.
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
