joe1962: Your solution to getting this issue discussed is perfectly fine with me if the core developers and decision makers are here.
FWIW, I agree with everything said by joe1962 and eauster so far. I'd like to bring a couple of additional points from the previous thread which I made to this one to hopefully focus on why this discussion is important:
A lot of places (particularly businesses and government) as well as security paranoid individuals like me want to keep any known vulnerabilities closed. I do this stuff for a living, though not with Vector Linux. I'd love VL to get to the point where businesses and government think it's worth considering. You may have no idea how close, quality wise, this distro is.
You've just raised another point. gtk+ 2.8.x wasn't a security vulnerability and it wasn't broken. There wasn't a compelling reason other than GNOME 2.18.0 to put gtk+ 2.10.11 in patches. It, with GNOME, probably needed to be put in a separate (new) repository so that everyone who does a
wouldn't get it. It's too late for that now.
The point I'm making is that we need to have a sensible upgrade policy and a build policy that tracks it. This isn't about individual choices but rather what our user community, especially people migrating from things like the very broken recent release of Xubuntu Feisty Fawn, is likely to expect from us.
When Daniel Baranger of Red Hat suggested that VL lacked karma (he couldn't find another way to say why he didn't like it) I kind of agreed. I think this is an example of why. It isn't that there is anything wrong with VL. It's actually pretty darned impressive at this point. It's more suffering growing pains and needs some more rigorous (professional?) standards that we all follow. Oh, and yeah, that includes me even if I don't like them -- hence my feeling that I need to build against a clean box since that is the current standard -- at least until this issue is addressed.
In every other major distro (I'm assuming VL is moving into the ranks of majors here) once something is in patches or the distro equivalent it is the de facto standard. Every other major distro recommends keeping up with patches. Up until VL 5.8 there was no workable mechanism to do that. With VL 5.1 the docs advised against a slack-get --upgrade for good reasons:
1) slack-get wasn't terribly mature, and
2) the repository management wasn't there yet
If you tried to do a mass upgrade on 5.1 you broke things. On 5.8 that is no longer true. It works like a charm, even with the rather daring gtk+ 2.10.11 upgrade. The sole broken piece after the gtk+ upgrade is wifi-radar and the package which fixes that is in testing. Doing a mass upgrade is what someone migrating from another distro with sane package management (read: NOT Slackware) is probably used to and it's what they likely expect.
The nice thing about respinning the current iso is that you basically replace the stuff on the current iso with the stuff from patches (plus wifi-radar 1.9.8 from testing) and go with what you have. It's pretty much all tested already except for running the installer with the newer packages. Considering the huge amount of stuff already upgraded (xfce, seamonkey, firefox, gtk+, glib2, vl-hot, cairo, pango, etc...) I don't think it would be much a stretch to "release" 5.8.1 as it has as many or more changes than what typically happens between two releases of Ubuntu or Fedora or whatever. You wouldn't need new repositories either... just continue with the existing ones. You also get the bonus of new community press on the new "release".
Re: SOHO. My forthcoming review for O'Reilly makes the point that it should have been called 5.8.1. It has so many changes and upgrades from Standard that they can't really be considered the same version IMHO. BTW, you're going to like my review of SOHO. I haven't seen KDE move that fast on my aging hardware in ages.