On 11/29/06, Andrew Gaffney <[EMAIL PROTECTED]> wrote:
The 3-4 weeks of releng filing a ton of "doesn't build with gcc-4.1.1" bugs wasn't a big enough clue? :)
No. We get those all the time; there's always someone trying out an unsupported release of gcc.
Also, the arch teams (or at least the arch's release coordinator...if they didn't tell the rest of their team, that's not releng's fault) that were moving to it and people in base-system working on it were "in the know".
What about everyone else, who isn't part of an arch team? Sorry, but I just don't get how you expected us to know it was coming, when you didn't announce it, and you don't even feel that an announcement was your (releng's) responsibility (even though stabilisation of gcc-4.1 was for you). You personally went out of your way earlier this year to critisise me about bad communication, just for announcing that work had started on something in Gentoo. And yet here you are today, somehow expecting the rest of us to rely on clairvoyance to know in advance about a change that your team pushed onto the entire tree. It's a great illustration why the releng snapshots, as things stand today, aren't the right way to deliver a meaningfully stable tree to our users. It's simply difficult to trust you with the way you choose to behave today.
Yes, that's part of wolf31o2's idea. The tree would be "non-moving" except for GLSA's and any dependencies required by the updated version of the security-affected package.
How are you going to ensure that all the security fixes that never get a GLSA get into the tree?
A slower-moving (or "non-moving" with security updates) tree is perfect for me, and I'm sure for many other people as well.
Before you release these trees to users, I trust you'll be doing the responsible thing, and ensuring that upgrades from one tree to the next work? You can't take that for granted; package maintainers cannot be relied upon to test upgrades spanning that length of time. (Which is why upgrade early, upgrade often is a practical way to manage Gentoo boxes) Best regards, Stu -- -- gentoo-dev@gentoo.org mailing list
