after dealing with m68k, mips, and the *-fbsd ports, i think we could do with a new state for profiles.desc. the new field would simply be "exp" to indicate that the profile is experimental and that qa tools should generally not issue warnings about them. so in repoman's default mode, you wouldnt get any warnings, but if you were to run it in full mode, you'd see stuff like normal. this is useful for new projects which are still in the process of merging (like *-fbsd, m68k, and any new hardware i get my hands on) and are not really ready for "dev" marking. there are plenty of warnings in packages right now due to these profiles being labeled as "dev" that are the sole problem of the keyword maintainer in question and not the package maintainer. -mike
Mike Frysinger wrote: > after dealing with m68k, mips, and the *-fbsd ports, i think we could do with > a new state for profiles.desc. the new field would simply be "exp" to > indicate that the profile is experimental and that qa tools should generally > not issue warnings about them. so in repoman's default mode, you wouldnt get > any warnings, but if you were to run it in full mode, you'd see stuff like > normal. this is useful for new projects which are still in the process of > merging (like *-fbsd, m68k, and any new hardware i get my hands on) and are > not really ready for "dev" marking. there are plenty of warnings in packages > right now due to these profiles being labeled as "dev" that are the sole > problem of the keyword maintainer in question and not the package maintainer. > -mike
I've very much been a proponent of properly listing out all of our profiles in profiles.desc. This sounds very reasonable and logical. And hopefully if the tools in question are coded properly, it should be compatible with older versions until users upgrade.
Good stuff Mike.
-- Doug Klima Gentoo Developer -- gentoo-...@lists.gentoo.org mailing list
On Fri, 2008-01-11 at 09:59 -0500, Doug Klima wrote: > Mike Frysinger wrote: > > after dealing with m68k, mips, and the *-fbsd ports, i think we could do with > > a new state for profiles.desc. the new field would simply be "exp" to > > indicate that the profile is experimental and that qa tools should generally > > not issue warnings about them. so in repoman's default mode, you wouldnt get > > any warnings, but if you were to run it in full mode, you'd see stuff like > > normal. this is useful for new projects which are still in the process of > > merging (like *-fbsd, m68k, and any new hardware i get my hands on) and are > > not really ready for "dev" marking. there are plenty of warnings in packages > > right now due to these profiles being labeled as "dev" that are the sole > > problem of the keyword maintainer in question and not the package maintainer. > > -mike
> I've very much been a proponent of properly listing out all of our > profiles in profiles.desc. This sounds very reasonable and logical. And > hopefully if the tools in question are coded properly, it should be > compatible with older versions until users upgrade.
To go along with this, I've always wanted a few other minor changes.
For one, a way to mark a profile as deprecated in profiles.desc so repoman doesn't scan it (currently, we remove tend to remove them from the list). The second would be a change to repoman that's more "invasive" in that it changes current behavior a good bit, but having repoman only scan "stable" profiles, by default, with options to scan the other types. I've always wanted to have *every* valid profile listed in profiles.desc so we can do things like have portage not allow someone to use a profile that isn't listed in profiles.desc (of course, overlay users crazy enough could do their own profiles.desc and it would be stacked with the in-tree one). The main problem with doing this has been the effect on repoman, since it scans every listed profile every time. I know that most of the profile selection tools out there already only show profiles that are listed in profiles.desc, so it wouldn't really be a change for them, but I think it would be useful elsewhere, too. All in all, having profiles.desc actually showing the status of all of the profiles would be great.
> Good stuff Mike.
Indeed.
-- Chris Gianelloni Release Engineering Strategic Lead Games Developer
On Friday 11 January 2008, Chris Gianelloni wrote:
> For one, a way to mark a profile as deprecated in profiles.desc so > repoman doesn't scan it (currently, we remove tend to remove them from > the list).
is this really needed ? i'm trying to see why this would be useful, and not coming up with much ... profiles.desc exists for two reasons: - for qa tools to scan - so people have a list of valid profiles if a profile is deprecated and on the way out, neither of these two things apply to it, so what's the use of having it listed ? we can already mark profiles deprecated for users who already have it selected ...
> The second would be a change to repoman that's more > "invasive" in that it changes current behavior a good bit, but having > repoman only scan "stable" profiles, by default, with options to scan > the other types.
i think by moving our most annoying profiles out of the dev to the exp state would mean that any warnings left while in the dev state are something we want to be seeing and addressing. the problem right now is that we have two types of profiles listed in dev: ones that people should care about and shouldnt be breaking and ones that people shouldnt care about and are free to break. package maintainers obviously dont (and shouldnt) know which are which.
> I've always wanted to have *every* valid profile > listed in profiles.desc so we can do things like have portage not allow > someone to use a profile that isn't listed in profiles.desc (of course, > overlay users crazy enough could do their own profiles.desc and it would > be stacked with the in-tree one). The main problem with doing this has > been the effect on repoman, since it scans every listed profile every > time. I know that most of the profile selection tools out there already > only show profiles that are listed in profiles.desc, so it wouldn't > really be a change for them, but I think it would be useful elsewhere, > too. All in all, having profiles.desc actually showing the status of > all of the profiles would be great.
i could see it tied to FEATURES=strict. if you have this enabled, then you're only allowed to use declared profiles (which means if you use a non-standard one, you'd need to declare it). -mike
On Sat, 2008-01-12 at 00:40 -0500, Mike Frysinger wrote: > On Friday 11 January 2008, Chris Gianelloni wrote: > > For one, a way to mark a profile as deprecated in profiles.desc so > > repoman doesn't scan it (currently, we remove tend to remove them from > > the list).
> is this really needed ? i'm trying to see why this would be useful, and not > coming up with much ... profiles.desc exists for two reasons: > - for qa tools to scan > - so people have a list of valid profiles > if a profile is deprecated and on the way out, neither of these two things > apply to it, so what's the use of having it listed ? we can already mark > profiles deprecated for users who already have it selected ...
I guess I was thinking more for the package manager. As I said, I would love for it to enforce a valid profile as defined in profiles.desc, even if it is a deprecated one, until the user switches. This means the deprecated profile needs to be listed in profiles.desc, but we don't want to run QA on it, as you said.
> > The second would be a change to repoman that's more > > "invasive" in that it changes current behavior a good bit, but having > > repoman only scan "stable" profiles, by default, with options to scan > > the other types.
> i think by moving our most annoying profiles out of the dev to the exp state > would mean that any warnings left while in the dev state are something we > want to be seeing and addressing. the problem right now is that we have two > types of profiles listed in dev: ones that people should care about and > shouldnt be breaking and ones that people shouldnt care about and are free to > break. package maintainers obviously dont (and shouldnt) know which are > which.
Indeed. I can see that with the profiles reassigned there's no need for this.
> > I've always wanted to have *every* valid profile > > listed in profiles.desc so we can do things like have portage not allow > > someone to use a profile that isn't listed in profiles.desc (of course, > > overlay users crazy enough could do their own profiles.desc and it would > > be stacked with the in-tree one). The main problem with doing this has > > been the effect on repoman, since it scans every listed profile every > > time. I know that most of the profile selection tools out there already > > only show profiles that are listed in profiles.desc, so it wouldn't > > really be a change for them, but I think it would be useful elsewhere, > > too. All in all, having profiles.desc actually showing the status of > > all of the profiles would be great.
> i could see it tied to FEATURES=strict. if you have this enabled, then you're > only allowed to use declared profiles (which means if you use a non-standard > one, you'd need to declare it).
Sure. I see no reason to not allow someone to turn it off.
-- Chris Gianelloni Release Engineering Strategic Lead Games Developer
