On Fri, 2008-01-04 at 21:02 +0000, Ciaran McCreesh wrote: > X and Y are pretty much irrelevant. The important factor is Z, the > impact of leaving things the way they are.
...and the idea is to let the Council decide what level of Z is acceptable. Currently, it appears as if the "issue" is maintainers being forced to keep abhorrently old versions of packages, including security-vulnerable packages, simply because a security-unsupported architecture hasn't had time to test/update/whatever. This has been an issue for quite some time. Of course, the impact is debatable, but it seems that we cannot agree ourselves on what is agreeable, so I see this as a point to bring to the Council simply so it can be resolved "once and for all" and things can resume normal operation. I know that I, as an ebuild developer, would be much more comfortable/accepting of having to keep around old versions of packages, if the Council had deemed it to be something "important" enough. No offence to any alternative architectures or their hard-working team members, but there are some times when we have to look at the common good, and forcing maintainers to spend time keeping older ebuilds that are possibly using older ebuild code and other idiosyncrasies versus the current versions for the more mainstream architectures simply might not be worth it for architectures with a very minimal number of users. I've heard some suggestions for removing stable KEYWORDS on arches that aren't security supported. I see this as a possible solution to such issues, since ~arch packages aren't "security-supported" in the sense of GLSA and such, so why not keep arches which aren't security-supported from having stable KEYWORDS? Of course, this is a "global" change which affects multiple architectures, so it should be deferred to the Council. I don't really think it requires a large amount of discussion simply because it is simple to see how it would come to a swift stand-still. The arch teams affected will want nothing to change, the package maintainers will want to make things easier on themselves. This is to be expected. We elect the Council for a reason. Making decisions like this is one of them. Let's let them do their job and follow their leadership. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation
signature.asc
Description: This is a digitally signed message part
