6.2; 6.3; EOL; combustible discussions

[Josh Carroll]

> I think the developers and users have made their points clear, and
> they're no going to agree any more (but they may agree less) over
> time.

You make it sound as if all users are of the same opinion as Jo. The
majority of the responses from users running 6.3 in the thread(s) have
been positive feedback of its operating properly. I know what you
meant, though. Just don't want anyone to think there is somehow a line
being drawn in the sand between users and developers. :)

> * Some users standing up, stating "yes, 6.2 lifetime means a lot to
> us, we'll happily contribute back security fixes and/or bug fixes for
> our hardware so we can continue using it!", and then doing so.

While it would be interesting to see the response here, it still
doesn't necessarily provide a solution. It will still involved
developers' time to QA the user-submitted patches, so it won't
entirely eliminate the additional workload for maintainers. There is
also zero (enforceable) accountability. If X people commit to this,
what happens when only a fraction of them actually do end up helping?

> * Some users (Jo, in particular) providing hardware which 6.2 runs on
> but 6.3 may or may not, and allowing interested developers to jump on
> and test/debug, so this whole discussion can be ejected out the
> nearest airlock.

That would, of course, require that Jo actually try to run 6.3 on his
particular hardware, something he said he does not have the time
(currently) to do. As others have pointed out, hardware often has
numerous revisions and it's quite possible 6.3 will work fine for him.

> Anything else, really, is just going to continue upsetting people.
> Yes, users want stability in their specific environments. Yes,
> developers are mere mortals, and users should be happy that there's
> even a project here they can get access to without some kind of
> warez-like upload/download ratio. further discussion is just going to
> upset people even further. :)

I agree, the horse has been beaten to death numerous times.

I guess the one thing that I've taken away from this entire discussion
is that perhaps it would be useful to the end users to have a
managed/tracked list of regressions between releases. I know there are
known bugs published, but is there a list of items that are strictly
regressions? Even if it doesn't solve the problem of users with
particular hardware configurations being able to run the new release,
at least it's something people can use in deciding when/if to upgrade
or whether they want to go the route of self-supporting
security/errata fixes until they find a release they feel comfortable
migrating to?

Just my two cents, and hopefully I'm not throwing wood on the fire here.

Regards,
Josh