Re: OT - Packages maintaining source for systems no longersupported [WAS: Re: Portability of preprocessor directives]

[Earnie Boyd]

Andreas Buening wrote:
> Earnie Boyd wrote:
>
> [snip]
>
>
> > I would like to emphasize though, if the hobbyist isn't willing to test
> > for new releases using his hobby environment then support for that
> > environment should be removed.  A package maintainer doesn't have enough
> > cycles to maintain code that no one uses and doesn't have enough cycles
> > to do the testing himself.  So, if no one is testing then the maintainer
> > can assume that no one is using that environment and drop support for it
> > altogether.
>
>
> What do you consider a hobbyist system? 

One that the vendor no longer supports and supplies fixes for and I as a 
maintainer of the software no longer have no access to test it myself. 
If it's not even tested how can it be used?  It has a high probability 
of not working anyway!

> I guess, 99.99% of all people
> (maybe even more) don't test software packages as long as they don't
> need to do.

If I'm rolling out new systems and new software, then yes regressions 
must be tested for.  I only care about the ones I use, not the ones I 
don't.  If I have a HP UX 9.x system and a maintainer of a software 
package makes improvements and I don't test them I my system then whose 
fault is it.  The maintainer doesn't make any warranties, nor does 
anyone else.  I must myself make the warranty, provide the appropriate 
patches and move on.

> I remember Debian hit the 8000 package limit some time
> ago. How many of the software packages you use for your daily work
> do you really test? 1000? 100? I guess, it's less. Much less.
> If it's just 1 then you do much more than 99.x% of all people do.
> Having no tester for a specific system doesn't mean there are no users.

Well, if the package works for the maintainer and he rolls that out as a 
production release but it works for no one else because no one has an 
enviroment like the maintainers then the package will only have one 
user.  It is impossible for a package maintainer to test all 
combinations of environment.  He can do his best to try not to break the 
workings of the program for a particular system, but if no one is using 
that system anyway why continue to support it?  At that moment of 
realization it's time to prune support for that system from the code.

> Not all packages have as many contributors as autoconf. If you immediately
> drop support for all systems when you don't have a tester then you will
> hurt all systems that are not a standard Red Hat Linux out of the box
> installation. 

So, you've tried both RedHat and Debian versions of Linux. ;)  I'm not 
talking about viable well supported systems that are currently being 
used.  I'm talking about systems that are no longer supported by their 
respective vendors at all and used little.

> You won't get a feedback one day after you've released
> the new version of foo, maybe not even this year, maybe in two years
> when Joe User wants to compile the cool new xyz program on SysBlurb which
> needs the great and unique abc library. And to compile abc he needs the
> latest version of foo and this doesn't work because "there was no tester
> so nobody needs foo on SysBlurb".

At that point it's called porting.  He ports the package to his system 
and submits patches to the maintainer for enjoyment in the future.  The 
maintainer of an open source package is more a facilitator of patches 
more than he is the originator of the patch himself.

I take it from your tone that you are a user and not a participant in 
open source?  I take it from your tone that you don't want your programs 
to stop working but that you aren't willing to put effort into making 
sure that doesh't happen beyond spouting words?  I take it from your 
tone that you think the maintainer of code should keep code in his 
source files that someone someday maybe might use again on the pretense 
that someone used it once and it maybe someday just might be done that 
way again?  Ridiculous!  If the code isn't being used then remove it. 
If I remove the code from packages I maintain and it was used then 
perhaps someone might complain and it can be readded.  Perhaps someone 
will do something even more clever and supply a better patch.  Perhaps 
it just might cause testing by those interested in the package before 
the next release.

Earnie.