Re: [gentoo-dev] Guidelines for IUSE defaults

[William L. Thomson Jr.]

On Sunday, February 5, 2017 7:14:45 AM EST Kent Fredric wrote:
> On Sat, 04 Feb 2017 12:44:38 -0500
>
> "William L. Thomson Jr." <wlt-ml@××××××.com> wrote:
> > The question to ask is who do you want to create more work for?
> > People maintaining packages, or people maintaining profiles.
>
> I would probably say "yes" to both of those, because the main objective here
> is to create less work for the end user, and that burden has to be paid by
> somebody.

Definitely needs to be developers vs end users paying the time price. Just 
increasing requirements to maintaining package can increase the entrance 
barrier. It is not like people are flocking to maintain packages as is now.

I am sure most any developer would welcome another even if they just maintain 
a single package :)

> I don't think its anything that is the responsibility of either one of those
> targets in isolation.

I would agree as I am all about working together rather than apart! That said 
I am not against teams having a particular focus, and working with others on 
their agenda.

> > Essentially your saying IUSE defaults do not belong in a package, but in a
> > profile. The problem is that is a hard rule to follow. What if the default
> > benefits all, like in a base profile. Then it might make sense to add
> > directly to ebuild than profile. But that would go against any
> > rule/policy saying only add IUSE defaults to profiles. At the same time,
> > if more than one profile needs that enabled by default, it is creating
> > more work there.
>
> That's rather the problem as I see it, people are trying to see it as an
> "either" situation when its rather both.

It is hard to satisfy both. Both do not share the same perspective or goal.

> > While the latter is cleaner, and therefore would seem preferred. It is not
> > that much effort to negate a flag in a profile. That is likely time better
> > spent. Than to have package maintainers messing with profile defaults,
> > touching more than one profile potentially, etc.
> >
> > Its probably best to have a team, familiar with profiles managing
> > profiles.
> > Rather than every developer working with IUSE and packages. While they may
> > be bloated, or uglier. There isn't really a way around, short of
> > something that bypasses default flags, allowing others to be set instead.
>
> As I see it, people who manage "profiles" are essentially managing a
> distinct "vision", a template of sorts of a stereotype of a specific type
> of end user, concerning themselves with espousing the same interest over a
> wide variety of packages.

Yes, and that vision may not be shared, or even cared about by the package 
maintainer. Why should the package maintainer be burned with something that 
does not apply to them?

Seems it is the profile people who care about such. Plus profiles could be 
created without the package maintainers awareness. Or changes there in and 
they would have to be kept in the loop.

> Whereas the people who manage packages are more concerned with a more
> "upstream centered" vision of things, ( where the maintainers themselves
> are a kind of upstream ).
>
> So naturally it will require some sort of negotiation, where the people
> who define profiles write guidelines for how packages should fit into
> those profiles, and the people who write packages should work out how
> to dovetail the upstream vision of things into those specific
> guidelines.

I agree, but I think that responsibility should fall on the profile team. They 
should contact the package maintainer and work with them on their vision. Even 
that will be taking time from the maintainer on a vision they may not share.

Putting increased requirements on the maintainers may be demotivating, and 
create other problems. New profile added they are not aware of. Now they have 
to go add IUSE defaults etc. There are a fair amount of profiles.

> For instance, perhaps one specific profile might be the "I Just want a
> kde/qt desktop of some kind, I don't care how", and thats the point of
> that profile, to deliver that specific experience.
>
> But the individual packages will still have to decide how to best
> satisfy that profile, which in some cases might end up preferring qt4
> instead of qt5 for instance (perhaps out of necessity)
>
> Maintainers of individual packages have the most knowledge about how to
> best deliver that specific package, but maintainers of profiles have
> the best understanding of what people want to see.

Yes has to be a balance. I do not believe package maintainers will always 
share the vision of the profiles.

Said another way, if defaults were sane enough, would profiles be necessary?

Profiles are kind of an extra added benefit to the end user, and those making 
the profiles. Mostly a benefit for the end user. There isn't much benefit to the 
package maintainer. I could not really see anything that would give them 
reason to spend their time on something that would not benefit them.

-- 
William L. Thomson Jr.