Stuart Herbert wrote:
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.
From other developers, most of which were releng members?
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).
It's stupid to "blame" releng for the stabilization of gcc-4.1.1. It would have
been stabilized soon as part of the normal process of package maintenance
whether releng wanted it or not. And really, it was up to each arch to say they
wanted it for the release, not releng. We didn't force it on people.
And as always, if you wanted to know what was going on as part of the release,
the info was there for everyone to see in the usual places (such as the
gentoo-releng mailing list or the #gentoo-releng IRC channel). This argument
about people not knowing what releng is doing seems to come up after every
release. It's crap.
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?
If it doesn't get a GLSA, it doesn't get in the release tree. This may mean that
we need to modify the GLSA process a bit so that ~arch packages found to be
vulnerable get GLSAs as well. Although, release tree users won't have these
~arch versions anyway, so I don't see it being *that* big of an issue.
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)
Absolutely, it would be stupid to release it to users without testing that the
upgrade path is even feasible. However, we can't test the upgrade with *all*
packages in the tree, but we can certainly do it with certain "profiles" (gnome
desktop, kde desktop, LAMP server, etc.) to try to cover as many bases as
possible. This testing can be easily scripted.
--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Installer Project
Today's lesson in political correctness: "Go asphyxiate on a phallus"
--
gentoo-dev@gentoo.org mailing list
