-
2016.09.07 16:38 "Re: [Tiff] remotesensing.org URLs (http and ftp)", by Even Rouault
-
2016.09.07 18:42 "[Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Even Rouault
-
2016.09.08 14:19 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Jeff McKenna
-
2016.09.08 14:51 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Bob Friesenhahn
- 2016.09.08 14:58 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Jeff McKenna
-
2016.09.08 15:11 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Even Rouault
-
2016.09.08 16:26 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Bob Friesenhahn
-
2016.09.08 17:01 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Edward Lam
-
2016.09.13 11:32 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by
- 2016.09.13 13:21 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Olivier Paquet
-
2016.09.14 02:34 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Bob Friesenhahn
- 2016.09.14 12:34 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Jeff McKenna
-
2016.09.14 20:26 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Kemp Watson
-
2016.09.16 15:26 "Re: [Tiff] remotesensing.org URLs (http and ftp)", by Kemp Watson
- 2016.09.16 15:32 "Re: [Tiff] remotesensing.org URLs (http and ftp)", by Jeff McKenna
- 2016.09.16 16:21 "Re: [Tiff] remotesensing.org URLs (http and ftp)", by Bob Friesenhahn
-
2016.09.16 15:26 "Re: [Tiff] remotesensing.org URLs (http and ftp)", by Kemp Watson
-
2016.09.13 11:32 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by
-
2016.09.08 17:01 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Edward Lam
-
2016.09.08 17:53 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Rick Widmer
- 2016.09.08 18:29 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Lee Howard
-
2016.09.08 16:26 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Bob Friesenhahn
-
2016.09.08 14:51 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Bob Friesenhahn
-
2016.09.08 14:19 "Re: [Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Jeff McKenna
-
2016.09.07 18:42 "[Tiff] Fwd: Re: remotesensing.org URLs (http and ftp)", by Even Rouault
- 2016.09.07 17:20 "Re: [Tiff] remotesensing.org URLs (http and ftp)", by Bob Friesenhahn
- 2016.09.16 16:47 "Re: [Tiff] remotesensing.org URLs (http and ftp)", by Fred Rothganger
- 2016.09.25 21:59 "Re: [Tiff] remotesensing.org URLs (http and ftp)", by Bob Friesenhahn
2016.09.16 16:37 "Re: [Tiff] remotesensing.org URLs (http and ftp)", by Bob Friesenhahn
For the record, the non-subscriber also contacted me, in that same message, but i am hesitant to commit the OSGeo foundation to this, without the approval from the libtiff community here. -jeff
The most important thing to me is that the final solution solves the longevity issue. Libtiff has existed for 29 years already and could easily be useful for another 29 years.
The problem we have encountered is that active maintainers obtained support from benefactors (sometimes their then employers) who provided DNS and servers. Some active maintainers faded away and benefactors forgot about the services they were providing, or went defunct. Remaining libtiff maintainers have no knowledge of who is providing the services.
Whatever is done now needs to help libtiff be maintained for another 29 years. There is no assured warranty for any individual or company so the solution needs to assure that whoever constitutes the current maintainers are able to carry on. It needs to be possible to move foward to new servers/services without the risk of suddenly being locked out.
A distributed version control system is good. Use of proven long-term bug trackers (including Bugzilla) is good provided that there can be live mirrors of the buck tracking database so nothing is lost if the keeper of the server goes away.
Depending on a commercial "portal" which offers really nice services but does not provide the ability to completely back up its source code, bug tracker, and distribution files, would introduce lock-in which is harmful to the long term future of the project.
Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/