Re: [gentoo-project] Council: Policy for Systemd units

[Tom Wijsman <TomWij@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 7788 bytes --]

On Sat, 15 Jun 2013 14:01:47 +0430
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Tom Wijsman schrieb:
> > On Sat, 15 Jun 2013 02:44:50 +0430
> > Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> >
> >> Tom Wijsman schrieb:
> >>
> >>> Oh, and not to forget about X-openrc, X-cron, X-..., ... and so
> >>> on.
> >>
> >> X-selinux if you want an example of what is currently in tree.
> >
> > That's not the point, the point is that different approaches are
> > used; this leads to inconsistency that makes things harder for our
> > users.
> 
> So what? If one approach is better, then over time it will win over
> the others. If there is not one single best approach, then users will
> have to live with the diversity (or inconsistency as you call it).

"users have to live with"

Seriously?

> >
> >
> >>> Putting the maintenance burden on users is the worst thing we can
> >>> do.
> >>
> >> Users have no extra maintenance burden in this case.
> >
> > They do, because of the inconsistency they can't take a single
> > action.
> >
> >> Users have to make informed decisions, which is something they have
> >> to do all the time anyway when using Gentoo.
> >
> > Irrelevant to the maintenance burden, it is not about not making
> > informed decisions but rather about not making them harder to apply.
> 
> "Follow this HOWTO/guide" is not hard.

s/Follow this/Find and read yet another/

s/not hard/extra unnecessary efforts we can avoid/

It's not hard if you make it seem easy; but in practice, it is hard.

> >> IIRC, QA needs no formal justification for masking a package.
> >
> > They do, otherwise they can't pursue their goal; if they don't
> > define quality and can't justify themselves, then what exactly do
> > they assure?
> 
> Usually QA does justify their actions, but I found nowhere a rule that
> this is a requirement.

Does there have to be a rule for them to state what they assure? Odd.

> >> x11 team decided some time ago that we would not let proprietary
> >> drivers hinder the progress of X.org packages.
> >
> > This is irrelevant, since optional files do not hinder progress.
> 
> This is very relevant. Imagine if one day a user comes and wants us to
> include a very small, almost zero-maintenance, upstream-rejected patch
> for xorg-server that makes it easier to run proprietary drivers on
> Gentoo. Oh wait, someone already did[1].

Cool, he had a big share of our users in mind.

> And if any other developer disagrees, he is welcome to make his own
> xorg-server package that includes this patch.

s/disagrees/doesn't care about our users/

s/own/yet another/

s/includes/introduces an additional step/

> >> Would it be better for our users if we instead bent over to
> >> accommodate for the binary blobs from AMD, Intel (yes, Intel) and
> >> NVidia?
> >
> > Yes, I don't see how this is a problem for the X11 team.
> 
> This is not a problem for the X11 team, but one for the users that we
> care about, namely the ones who use the free/open source drivers. They
> would not see latest package versions in stable with latest features
> and bugfixes, until the proprietary drivers are compatible with them.

I still don't see the problem, we have USE flag masking for this.

> >> However for all *I* care, blob users can go use Windows.
> >
> > They don't have to, and using Gentoo as a means to bother users one
> > hates isn't really the right approach to go about it; that's
> > careless.
> 
> I don't hate that group of users, I just don't care about them. I do
> not do anything to deliberately sabotage their choice to use blobs,
> but I to put it in the words of a well-known kernel developer[2]: I
> refuse to tie my hands behind my back for them. If they use blobs, it
> is their problem.

Yet, you don't have to do anything for them; so, why would you bother?

> >> You mean that page? http://www.gentoo.org/main/en/about.xml
> >> I don't see the words "direction" or "stream", nor anything similar
> >> mentioned there.
> >
> > Why do the exact words have to be there. It being an about and
> > therefore it is sufficient to give a description of Gentoo.
> >
> > "automatically ... for just about any ... need", I don't see how
> > "maintenance burden" is "automatically" and how "all *I* care" is
> > "any ... need"; that would be disrespectful to what Gentoo is.
> >
> > In fact, if you want more exact words; a better read is
> >
> > http://www.gentoo.org/main/en/philosophy.xml
> >
> > which has "goal" & "philosophy", uses the word "should" several
> > times, "strive", "mission" and more. Are you going to ignore this
> > as well?
> 
> I don't ignore this. It describes Gentoo as tools which work for the
> goals of the user. So create the tools that are fine for your users. I
> will create those that are fine for mine, and they all can be part of
> Gentoo. The about or philosophy pages do not put an upper limit on the
> number of tools that can be in Gentoo.

Since when is this conversation about the amount of tools?

Don't pull things out of context.

> >>>> Gentoo is a collection of individuals which each work on a small
> >>>> part of it, and the interference in that is kept to the necessary
> >>>> minimum, mostly by Council enacted rules. I would be very unhappy
> >>>> if that were to change.
> >>>
> >>> You can't avoid interference, it is bound to happen sooner or
> >>> later; when it does, Council shouldn't be implied, but rather be
> >>> the exception.
> >>>
> >>> I would be very unhappy if Gentoo only ran on rules and silence;
> >>> these not only affect our developers, but even more also our
> >>> users.
> >>
> >> Interference does happen, I did not claim otherwise.
> >
> > You claimed it to be kept minimum; that's either silence or
> > ignorance.
> 
> I said it needs to be kept to the *necessary* minimum. That is for
> example QA rules like observing visibility requirements, no
> substantial changes to stable packages, technical implementation of
> legal rules like RESTRICT for packages with problematic license, and
> so on.

And those rules are irrelevant to this conversation, why recall them?

> >> If you disagree with another developer, you of course are entitled
> >> to complain loudly and try to convince him of your way.
> >
> > This in not about developers agreeing, it is about our users
> > agreeing.
> >
> > Oh, and that philosophy link above, it has "user" all over the
> > place...
> 
> Users are diverse and they don't agree on many things either.

They don't have to agree, because Gentoo gives them choice.

> yngwin is not alone in rejecting non-upstreamed systemd units in his
> packages, there are many users who don't want them either (whether
> that is a rational decision or not) and for whom this change is
> unwelcome. So these are the users that he cares about.

We've been to that argument already, it was found to be non-sense...

Think about it, the size of the unit files installed take less space
than the presence of the word systemd in the Portage tree does.

"We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil. Yet we should not pass
up our opportunities in that critical 3%. A good programmer will not be
lulled into complacency by such reasoning, he will be wise to look
carefully at the critical code; but only after that code has been
identified" — Donald Knuth

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]