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

[Tom Wijsman]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1



On Mon, 17 Jun 2013 18:15:45 +0200

Chí-Thanh Christopher Nguyễn <chithanh@g.o> wrote:



> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tom Wijsman schrieb:
> >> 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/
>
> How about you make your points in whole sentences? That is easier to
> reply to.


You can easily integrate it, I don't like forking for no good reason.



Do you have a reply instead of this ad hominem response?



> >> 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.
>
> USE flag masking is totally not related to this.


If the solution is not related, your example problem is not related.



But let me assume you have asked "How is USE flag masking related?"

instead; well, if a proprietary driver is not yet compatible with a

package then its VIDEO_CARDS expanded USE flag can be masked such that

an older version will be considered by Portage. Works perfectly.



> >> 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.
>
> You said it increases hardness and inconsistency. I said that this is
> not necessarily the case when there is proper documentation.


Extra efforts aren't proper when you can instead avoid inconsistency;

instead of that simple integration, you end up writing yet another tool

which you have document, support (docs aren't perfect) and fix bugs for.



> >> 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...
>
> Nonsense or not, it is users who have that desire (however irrational
> that may be) and either you care about them or not.


People that think desires of our users are irrational should state that

and give professional reasoning; on the other hand, developers that

oppose shouldn't start yelling right away and ask for clarifications.



The lack of interest from both sides of such arguments is problematic.



I hope to see these MLs turn into something more constructive; it

shouldn't be a place where some random people just vent against the

masses for their own good, the majority isn't going to agree anyway.



I don't see a group of users that hate unit files, please show me...



> > 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.
>
> That has nothing to do with the current argument.


This has a lot to do with the subject.



- -- 

With kind regards,



Tom Wijsman (TomWij)

Gentoo Developer



E-mail address  : TomWij@g.o

GPG Public Key  : 6D34E57D

GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2.0.20 (GNU/Linux)



iQEcBAEBAgAGBQJRv0iwAAoJEJWyH81tNOV9K7IH/iVkZLPk4+gAntQw6v8s/RZK

k3Pada0kTLMPyA2Padr/l+C6LteJvKP3JtkxCiAXmE7ht4RW5h7UPZ+/6gIwIq9x

pX0Nf9CPRPlDVbT3BxCDceaIuzVWEd+b/bkpuVHhQ9VWDzRU/tX4b21Yx0nekdE3

ZzcvgRdraGEVsv8mCf8oveTnUUp8BQjeXAP1ZxeZ9yahH2zivt1vEIhgNCJXL45b

z+tpd2z19PqwmdhVCK9dlhCgj/Pf62q50X2wEP3PpZHwIAsQGsIBjYv8nOOViRLn

p8B+JyaQtb9LBbIuHC63yYF0Attivg274fz4tyIqzWQLUnV+eXU+szC8wBga/SE=

=qNsC

-----END PGP SIGNATURE-----