On Sun, Mar 14, 2010 at 02:02:46AM +0200, Mart Raudsepp wrote:
> On Sat, 2010-03-13 at 13:16 -0800, Brian Harring wrote:
> > While I agree in principle within mixins, no one here is discussing
> > the QA affect of it- right now we can do visibility scans of
> > combinations of gnome + amd64 + 2010 because they're defined.
> What sort of QA affects do you imagine it having?
Simple enough. Right now, you change a profile, or want to stable a
pkg, you can do a scan and identify all new visibility issues from
profiles- you can validate up front that for the list of
supported/stable profiles, these changes occur.
If things are shifted over to prefering users mixing/matching profiles
on their own (meaning we no longer have a gnome amd64 2010 for
example), devs no longer get QA warnings when they break stuff for it.
Users see it however.
> Though I'm talking in the context of what I proposed - using it for just
> the target profiles that only tweak USE flags and other such defaults,
> nothing else.
Current QA (repoman/pcheck), if a use flag is defaulted on, it's deps
in a pkg must be visible. Via repoman/pcheck, they ensure that the
default use configuration for a profile, all visible pkgs dependencies
are visible (making the pkg fully usable).
Consider mixing/matching gnome/kde with a profile that has quite a few
packages masked- say mips. To be clear, this is a hypothetical case-
I know it exists, I'm just choosing two likely targets. Say gnome
requires some codecs use flag flipped on triggering a dep on a pkg
masked for mips.
I'm not saying these situations can't be worked around- we already fix
them now as they come up. The thing is, whenever you change something
now, those profile combinations are validated- with mix/match
approach, that validation won't be occuring, the users will be the
ones seeing the breakage rather than the dev.
> I considered QA affects for that case, at least in my own
> thoughts. I think QA would be checked anyhow there, as part of all USE
> flags enabled assumpting testing or static testing of various USE flag
> combinations of a package (e.g, for statically finding circular
> dependencies or the like).
Either you're suggesting that repoman/pcheck would have to scan all
arbitrary combinations of gnome/kde/desktop w/ misc arches, or you
need to be a fair bit more precise about how QA tools would identify
what profile combinations to check.
If you're proposing that the QA tool arbitrarily combines arches w/
various desktop/server mixins, I'll again note that the run time of
visibility scans is directly related to # of profiles to check- for
example, removal of mips profiles from profiles.desc is if memory
serves me a ~33% reduction in visibility runtime for pcheck.
For repoman (which all devs have to use for commiting), # of profiles
is even more of a critical value performance wise.
> Do you foresee bad QA affects for the for the
> desktop/developer/gnome/kde/server profiles case too, or just when
> mixing in selinux/toolchains/etc?
Issues will exist regardless of what the combination is. The point
I'm making is that with the current model, we catch those issues prior
to commit- having users mix/match on their own means users will see
those issues rather than devs. Literally, they'll see the breakage.