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. ~harring
pgpMhGs1sARlW.pgp
Description: PGP signature
