Return-Path: <SRS0=Vc/b=JM=lists.osgeo.org=tiff-bounces@osgeo.org>
Delivered-To: filtered@awaresystems.be
Received: from mx2.pub.mailpod8-cph3.one.com ([10.27.38.12])
	by mailstorage22.cst.mailpod8-cph3.one.com with LMTP
	id uBGkI/bLvmVoLgAAwT5NuQ
	(envelope-from <SRS0=Vc/b=JM=lists.osgeo.org=tiff-bounces@osgeo.org>)
	for <filtered@awaresystems.be>; Sat, 03 Feb 2024 23:27:50 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=custmx.one.com; s=20201015;
	h=sender:content-type:reply-to:from:list-subscribe:list-help:list-post:
	 list-unsubscribe:list-id:subject:in-reply-to:references:to:mime-version:date:
	 message-id:x-halone-refid:x-halone-sa:from:x-halone-sa:x-halone-refid;
	bh=PspgVoac2CG9NXhQ+cOa/FZdaRt86C1DUUwcBzI6kdw=;
	b=b0LLs84BATkK7yQ4xxMHsIFrLTLnNC+Str2ftJ0ZEmTI4d4A8mgJAuXiD/9drHxY4CTtnR2dsZ5vq
	 mMpgBLYF2naZpcpDUZ12UkAYm8ep/OZyZclFvez/Z+gDCJY5r3V5MAv6tTYSKGOvOnxJ9X42b/0Y0E
	 nV+zAmtEttzXe8KxBsptL94xpn+qOGHZWFB8fZkhaXoAanjTGwbwQ4wZptVwz5X0Z7D6A8G1hb1uSW
	 rYChHTvbDfoNN+4k1XLLeZRfNHibfmBmgsS0XFvzoerM7dXknzKJvByrk58AgffXorPinHZpLEWD5O
	 lBEUjJBfyu5XEEn/73LkdEaIGYfdPnQ==
X-HalOne-SA: -1
X-HalOne-RefID: 155866::1707002869-EE8D63B7-3ADD9C47/0/0
Authentication-Results: mx2.pub.mailpod8-cph3.one.com;
	spf=pass smtp.mailfrom=osgeo.org smtp.remote-ip=140.211.15.3;
	dmarc=pass header.from=lists.osgeo.org;
X-HalOne-ID: d7e29b63-c2eb-11ee-8616-98039b05783e
Received: from lists.osgeo.org (osgeo6.osgeo.osuosl.org [140.211.15.3])
	by mx2.pub.mailpod8-cph3.one.com (Halon) with ESMTP
	id d7e29b63-c2eb-11ee-8616-98039b05783e;
	Sat, 03 Feb 2024 23:27:49 +0000 (UTC)
Received: from osgeo6.osgeo.osuosl.org (localhost [127.0.0.1])
	by lists.osgeo.org (Postfix) with ESMTP id E07E5614682F;
	Sat,  3 Feb 2024 15:27:47 -0800 (PST)
X-Greylist: delayed 364 seconds by postgrey-1.36 at osgeo6;
 Sat, 03 Feb 2024 15:27:45 PST
Received: from mailhost1.ifax.com (mail-out.ifax.com [208.177.107.124])
 by lists.osgeo.org (Postfix) with ESMTPS id 95D4B6146811
 for <tiff@lists.osgeo.org>; Sat,  3 Feb 2024 15:27:45 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon)
 with ESMTPSA id 2C0E2282D4E
 for <tiff@lists.osgeo.org>; Sat,  3 Feb 2024 18:21:40 -0500 (EST)
Received: from mail.ifax.com (mail-out.ifax.com [208.177.107.125])
 by mailhost1.ifax.com (Postcow) with ESMTP id D7341282D48
 for <tiff@lists.osgeo.org>; Sat,  3 Feb 2024 18:21:39 -0500 (EST)
Received: from [192.168.38.155] (modemcable174.41-201-24.mc.videotron.ca
 [24.201.41.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits))
 (No client certificate requested)
 by mail.ifax.com (Postfix) with ESMTP id BA722548019
 for <tiff@lists.osgeo.org>; Sat,  3 Feb 2024 18:21:38 -0500 (EST)
Message-ID: <d6bb4be0-8e65-497a-9cd2-7364401b85e4@ifax.com>
Date: Sat, 3 Feb 2024 18:21:39 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: tiff@lists.osgeo.org
References: <alpine.GSO.2.20.2402030845480.18702@scrappy.simplesystems.org>
 <bc24ea0d-8709-4a68-8575-3e517eed85ed@spatialys.com>
 <alpine.GSO.2.20.2402031001500.18702@scrappy.simplesystems.org>
In-Reply-To: <alpine.GSO.2.20.2402031001500.18702@scrappy.simplesystems.org>
X-Last-TLS-Session-Version: TLSv1.3
Subject: Re: [Tiff] www.libtiff.org is restored
X-BeenThere: tiff@lists.osgeo.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.osgeo.org>
List-Unsubscribe: <https://lists.osgeo.org/mailman/options/tiff>,
 <mailto:tiff-request@lists.osgeo.org?subject=unsubscribe>
List-Post: <mailto:tiff@lists.osgeo.org>
List-Help: <mailto:tiff-request@lists.osgeo.org?subject=help>
List-Subscribe: <https://lists.osgeo.org/mailman/listinfo/tiff>,
 <mailto:tiff-request@lists.osgeo.org?subject=subscribe>
From: Patrice Fournier via Tiff <tiff@lists.osgeo.org>
Reply-To: Patrice Fournier <patrice.fournier@ifax.com>
Content-Type: multipart/mixed; boundary="===============5892907030233934853=="
Errors-To: tiff-bounces@lists.osgeo.org
Sender: "Tiff" <tiff-bounces@lists.osgeo.org>

This is a multi-part message in MIME format.
--===============5892907030233934853==
Content-Type: multipart/alternative;
 boundary="------------F0EhD1jD6jWUjn96Cuvstb3o"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------F0EhD1jD6jWUjn96Cuvstb3o
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Bob,

On 2024-02-03 10:00, Bob Friesenhahn via Tiff wrote:
> Lee Howard has managed to acquire the libtiff.org domain (with great 
> effort and expense to himself).

That's an excellent news! Thanks Lee!


On 2024-02-03 11:15, Bob Friesenhahn via Tiff wrote:

> We should keep in mind that Lee Howard is a maintainer of Hylafax, 
> which is now broken given latest libtiff due to many libtiff utilities 
> being removed.  It would be beneficial for his project (and others) if 
> the deprecated/removed libtiff utilities are restored (with security 
> fixes), if even as a different project from libtiff itself.

This would be really helpful indeed! I was already looking at my teams 
(iFAX Solutions (HylaFAX Enterprise and HylaFAX), but also T38Fax which 
uses these tools internally) to spare some time to work on this, but 
first, we'll need to know where to work on this and where to handle the 
issues. We'd personally prefer it be in the libtiff project, either in 
the main project, master branch or at minimum a separate branch from 
which (security issues) fixed tools are merged back into master. This 
would require all tools bugs to be restored and `wontfix-unmaintained` 
tags changed to `tools` or something like that, from which we could 
identify/label security issues and know which ones to concentrate on for 
this task (and the main libtiff team could exclude in their buglist if 
they so prefer, until we made enough progress).

Working in a separate project under the libtiff group or a separate one 
(I got `libtiff-tools` just in case) would allow giving rights to 
different people from the main project and have the bugs completely 
separated if that is preferred. And if it's a fork of the main project, 
still makes for easy merge requests so the fixes makes it to the main 
project. Adding that layer would complicate things when it's time to 
report bugs to tools though, especially when some tools bugs need to go 
to the main project and not others.

Is the libtiff team willing to have a group of helpers come on board to 
work on tools issues inside the libtiff project so we can restore these 
tools and willing to restore tools to build automatically inside the 
main libtiff project?  (So at first, restore the issues  that have been 
closed so we can work on this and agree to get tools back inside the 
main project?) If the goal is to not burden the current team with these 
issues, then we'd need to create a tools team to triage these bugs, add 
labels, close them, etc., so that would require at minimum some reporter 
level users. Might also need some developer to merge the fixes unless 
the main team is willing to accept that role.


P.S. http://libtiff.org/ doesn't redirect like http://www.libtiff.org/ 
does. It shows the main Simple Systems web page.


Regards,

-- 
Patrice Fournier
iFAX Solutions, Inc.
http://www.ifax.com/

--------------F0EhD1jD6jWUjn96Cuvstb3o
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Bob,</p>
    <div class="moz-cite-prefix">On 2024-02-03 10:00, Bob Friesenhahn
      via Tiff wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:alpine.GSO.2.20.2402030845480.18702@scrappy.simplesystems.org">Lee
      Howard has managed to acquire the libtiff.org domain (with great
      effort and expense to himself).</blockquote>
    <p>That's an excellent news! Thanks Lee!</p>
    <p><br>
    </p>
    <p></p>
    <div class="moz-cite-prefix">On 2024-02-03 11:15, Bob Friesenhahn
      via Tiff wrote:<br>
    </div>
    <br>
    <blockquote type="cite"
cite="mid:alpine.GSO.2.20.2402031001500.18702@scrappy.simplesystems.org">We
      should keep in mind that Lee Howard is a maintainer of Hylafax,
      which is now broken given latest libtiff due to many libtiff
      utilities being removed.  It would be beneficial for his project
      (and others) if the deprecated/removed libtiff utilities are
      restored (with security fixes), if even as a different project
      from libtiff itself.
      <br>
    </blockquote>
    <p>This would be really helpful indeed! I was already looking at my
      teams (iFAX Solutions (HylaFAX Enterprise and HylaFAX), but also
      T38Fax which uses these tools internally) to spare some time to
      work on this, but first, we'll need to know where to work on this
      and where to handle the issues. We'd personally prefer it be in
      the libtiff project, either in the main project, master branch or
      at minimum a separate branch from which (security issues) fixed
      tools are merged back into master. This would require all tools
      bugs to be restored and `wontfix-unmaintained` tags changed to
      `tools` or something like that, from which we could identify/label
      security issues and know which ones to concentrate on for this
      task (and the main libtiff team could exclude in their buglist if
      they so prefer, until we made enough progress). <br>
    </p>
    <p>Working in a separate project under the libtiff group or a
      separate one (I got `libtiff-tools` just in case) would allow
      giving rights to different people from the main project and have
      the bugs completely separated if that is preferred. And if it's a
      fork of the main project, still makes for easy merge requests so
      the fixes makes it to the main project. Adding that layer would
      complicate things when it's time to report bugs to tools though,
      especially when some tools bugs need to go to the main project and
      not others.<br>
    </p>
    <p>Is the libtiff team willing to have a group of helpers come on
      board to work on tools issues inside the libtiff project so we can
      restore these tools and willing to restore tools to build
      automatically inside the main libtiff project?  (So at first,
      restore the issues  that have been closed so we can work on this
      and agree to get tools back inside the main project?) If the goal
      is to not burden the current team with these issues, then we'd
      need to create a tools team to triage these bugs, add labels,
      close them, etc., so that would require at minimum some reporter
      level users. Might also need some developer to merge the fixes
      unless the main team is willing to accept that role. <br>
    </p>
    <p><br>
    </p>
    <p>P.S. <a class="moz-txt-link-freetext" href="http://libtiff.org/">http://libtiff.org/</a> doesn't redirect like
      <a class="moz-txt-link-freetext" href="http://www.libtiff.org/">http://www.libtiff.org/</a> does. It shows the main Simple Systems web
      page.</p>
    <p><br>
    </p>
    <p>Regards,</p>
    <pre class="moz-signature" cols="72">-- 
Patrice Fournier
iFAX Solutions, Inc.
<a class="moz-txt-link-freetext" href="http://www.ifax.com/">http://www.ifax.com/</a>
</pre>
    <div id="grammalecte_menu_main_button_shadow_host"
      style="width: 0px; height: 0px;"></div>
  </body>
</html>

--------------F0EhD1jD6jWUjn96Cuvstb3o--

--===============5892907030233934853==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Tiff mailing list
Tiff@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/tiff

--===============5892907030233934853==--
