On Fri, 2007-08-03 at 21:13 -0400, Luis Francisco Araujo wrote: > > - arch-specific patches/dependencies - If someone is requesting KEYWORD > > changes on a package and it requires a patch or additional dependencies > > for your architecture, you are not only permitted, but really are > > required to make the necessary changes to add support for your > > architecture. > > I am not sure about this last one ... what if for example this patch is > only for supporting a special option of the package for that > architecture, but the maintainer of the package found out that such a > patch is unnecessary and/or will cause other kind of problems in the > package, therefore preferring avoiding such a patch ... or he just > wouldn't like to apply the patch for X or Y; or even further, he just > wouldn't like to have such a package available for that architecture > just yet for Z or W.
The vagueness made it kinda hard to follow, but if a maintainer doesn't want their package on an architecture, they need to mark it -arch for that architecture. As it is right now, any arch team can add ~arch without maintainer consent. > The stabilization idea sounds good and it could free maintainers from > filing similar bugs over and over ; but wouldn't this be more and harder > work for arch teams?. For example, they should carefully track the > history of all the packages to know when and if they should stabilize it > yet. Huh? It's simple. The maintainer says "stabilize foo-1.2-r1" which gives a minimum level that all arches should be using. If foo-1.2-r2 comes out, it is up to the arch team to decide if/when to stabilize it, *unless* the maintainer requests a newer version/revision. Basically, the maintainer sets the minimum level they would like stable. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation
signature.asc
Description: This is a digitally signed message part
