On Fri, 14 Dec 2012 14:36:49 +0000 Markos Chandras <[email protected]> wrote:
> On 14 December 2012 14:29, Michał Górny <[email protected]> wrote: > > On Fri, 14 Dec 2012 12:38:24 +0000 > > Markos Chandras <[email protected]> wrote: > > > >> On 13 December 2012 21:46, Zac Medico <[email protected]> wrote: > >> > On 12/13/2012 12:43 PM, Michał Górny wrote: > >> >> On Thu, 13 Dec 2012 21:33:50 +0100 > >> >> "Andreas K. Huettel" <[email protected]> wrote: > >> >> > >> >>> Am Mittwoch, 12. Dezember 2012, 11:30:17 schrieb Zac Medico: > >> >>>>> Yes, and having 'stable' and 'unstable' profiles will work just > >> >>>>> the same. Except for the fact that it will be a bit cleaner, not > >> >>>>> require > >> >>>>> EAPI=5 at all and probably make arch testing a bit easier for a few > >> >>>>> people. > >> >>>> > >> >>>> Sounds good to me. > >> >>> > >> >>> Except that it completely breaks stabilization procedures, since > >> >>> packages are > >> >>> then not only tested with a larger range of useflags, but with an > >> >>> entirely > >> >>> different profile. Not such a great idea. > >> >>> > >> >>> The whole point of the stable masking was to keep the changes minimal > >> >>> when > >> >>> going from a "testing" to a "stable" state - by only restricting the > >> >>> use flag > >> >>> choices, and nothing else. This means most of the testing done with > >> >>> ~arch > >> >>> packages is still valid and provides meaningful feedback to > >> >>> maintainers and > >> >>> arch teams for stabilization. > >> >> > >> >> Well, it's all a question of decisions, I believe. If we make sure that > >> >> the new 'unstable' profiles differ from the 'stable' ones only by > >> >> additional masked/unmasked USE flags, I don't think it'd be an issue. > >> > > >> > Yeah, should be fine. > >> > >> How are you engoing to ensure that? And how are you going to monitor > >> them so they will not get out-of-sync in future? We have plenty of > >> examples of stale profile entries > >> all over the profiles/arch directory so I think that the stable > >> *use.stable.mask will also end up > >> unmaintained in the near future. > > > > What is your solution then? Keeping two revisions of most ebuilds so > > that one could be stabilized? I don't see how that is more > > maintainable, except for a few days who will easily stay out of it > > and pretend that the issue doesn't exist. > > > > -- > > Best regards, > > Michał Górny > > By keeping multiple ebuilds around you are transfering the maintenance > responsibility to the invdividual developer/herd. > By adding the *use.stable.mask to each architecture, you are > transferring this responsibility to the arch maintainers. Yes and no. Although we have a few arches which believe nobody should touch their files (but instead wait a few weeks till they actually notice someone asked them to mask a flag), I think you shouldn't overreact on this. Let's talk on examples. A good example is pypy which is not stable on any arch. I don't really see a problem with Python team actually maintaining use.mask entry for that implementation. And even if arch teams preferred to handle this on their own, I don't think that's much work as long as it's clear what the goal is. A quick look at dev-python gives me almost 800 packages; a quick ugly grep gives around 350 packages with stable keywords. This means that in the near time there will be around 250-300 additional ebuilds to maintain just because we can't mask the pypy flag on stable arches. > We already have plenty of understaffed arches, I don't think it is > wise to throw more responsibilities to them. Unless of course all > developers are allowed to touch these *stable* profiles which > personally I don't like because arches will lose > control of their stable trees. I'd like to point out that my proposal implies that the *current* arches become the stable arches, and new sub-arches would be the testing ones. Therefore, everyone will be allowed to touch like everyone is allowed to touch the *stable* profiles today. In other words, we mask python_targets_pypy* in the base profiles, and unmask them in the testing sub-profiles for amd64 & x86. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
