On Wed, 15 Jan 2014 01:06:07 +0100 "Andreas K. Huettel" <dilfri...@gentoo.org> wrote:
> Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman: > > On Tue, 14 Jan 2014 15:37:19 -0600 > > > > William Hubbs <willi...@gentoo.org> wrote: > > > Thoughts? > > > > In this situation, I see three opposite ends of choices: > > > > Here's another idea: > > 4. Friendly ask the arch teams / make a policy that @system packages > come first. Hmm, I'm wondering if that has an actual use or whether that would just move the problem. The bug in question that WilliamH demonstrated is indeed part of @system; but shouldn't be, it is due to functions.sh. So, assuming OpenRC wouldn't have been part of it, as it should be; this suggestion wouldn't change WilliamH's problem. Then comes the question whether we expand on all options in the virtuals, dependencies that come in through certain USE flags of @system; as well as the important libraries that aren't necessarily part of @system. Though on the other hand, what would be the point of prioritizing stabilization of important libraries if the applications are way too long detailed? Maybe it could improve their workflow of picking bugs a bit, dunno; I guess arch teams can shed some light on this last part. > (maybe these stable requests could be marked "major" in bugzilla > then?) Given that I think that we want more than just @system in the future, but those other things wouldn't be as important as @system and thus need a different way of being marked; I think we should rather pick "blocker" for @system packages. Then it still leaves us "critical" and "major" available for packages that are in between being the most and least important. Though as said, I think this would make only certain people happy; the question is to whereas how unhappy the other people would be, I can't really comment on this because of completely using unstable here. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
