On Sun, 2005-09-04 at 22:46 +0200, Simon Stelling wrote: > Stuart Herbert wrote: > > I've no personal problem with arch teams sometimes needing to do their > > own thing, provided it's confined to a specific class of package. > > Outside of the core packages required to boot & maintain a platform, > > when is there ever a need for arch maintainers to decide that they know > > better than package maintainers? > > I assume you're talking of the case where arch team and maintainer's arch are > the same. I think normally package maintainers can decide better whether > their > package should go stable on their arch than an arch team, as they get all the > bugs for it. On the other hand, we can't define a "maintainer arch" in many > cases, so either we leave the authority to the arch team or we'll just have > an > x86 arch team without the expected effects.
I still think that the concept of a "maintainer arch" is completely broken anyway. I like the idea of adding something like a "maint" KEYWORD, or something similar to mark that the ebuild is considered "stable" material by the maintainer. We can't rely on the maintainer using *any* arch as their main architecture. Take myself, as an example. The architecture I use when doing maintenance and adding new packages is just whatever machine I happen to be using. It could be x86, amd64, ppc, hppa, sparc, or mips, and there's no rhyme nor reason to which I am using at any point in time. This is becoming a more common occurrence that our developers have machines across many architectures. Personally, I don't think this should be an added KEYWORD, so much as a variable within the ebuild. I'd hate to start seeing users filing bugs using "maint" as their "arch" or adding maint to their USE flags. Just remember that if it is possible, somebody will do it... ;] -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
