[gentoo-project] Council: Policy for Systemd units

[gentoo-project] Council: Policy for Systemd units

[Rich Freeman]

Alas, I couldn't attend the council meeting in-person, but it seems
like council missed the point of my request RE commits against
maintainer wishes (or maybe not - if so I'll happily shut up as far as
persuading the council goes).  That said, I expressed it as a general
request in the hope to not have something systemd-specific, and it
sounds like that is not desired.

Picking just a single quote that I think gives the sense of the discussion:

<11.06.2013 19:10> <@Betelgeuse> Still I don't think policies
necessary need adjusting
<11.06.2013 19:10> <@Betelgeuse> If you need something system wide
with opposition then ask council on a case by case basis

So, what we need system-wide with clearly stated opposition on -dev is
permission to add unit files to individual packages when the package
maintainer doesn't want this done.

I'd ask that the council consider explicitly permitting this.  If not
you're just going to get an agenda item for specific exceptions for
the 10 packages that the maintainer blocked adding units to that
particular month.  Either that or you'll see 10 new packages with
co-maintainers where the two maintainers are in complete disagreement,
or the one who actually cares about the package and not the unit file
quits and the package stagnates as a result.  Nobody needs council
permission under the current policies to become a co-maintainer.  I
really see this as a case where lack of direction from above is just
going to lead to a lot of fighting at the ground level.

If the council isn't willing to make policy regarding adding units to
packages, just where do they expect them to go?

Rich

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

[Markos Chandras]

On 12 June 2013 12:05, Rich Freeman <rich0@gentoo.org> wrote:
> Alas, I couldn't attend the council meeting in-person, but it seems
> like council missed the point of my request RE commits against
> maintainer wishes (or maybe not - if so I'll happily shut up as far as
> persuading the council goes).  That said, I expressed it as a general
> request in the hope to not have something systemd-specific, and it
> sounds like that is not desired.
>
> Picking just a single quote that I think gives the sense of the discussion:
>
> <11.06.2013 19:10> <@Betelgeuse> Still I don't think policies
> necessary need adjusting
> <11.06.2013 19:10> <@Betelgeuse> If you need something system wide
> with opposition then ask council on a case by case basis
>
> So, what we need system-wide with clearly stated opposition on -dev is
> permission to add unit files to individual packages when the package
> maintainer doesn't want this done.
>
> I'd ask that the council consider explicitly permitting this.  If not
> you're just going to get an agenda item for specific exceptions for
> the 10 packages that the maintainer blocked adding units to that
> particular month.  Either that or you'll see 10 new packages with
> co-maintainers where the two maintainers are in complete disagreement,
> or the one who actually cares about the package and not the unit file
> quits and the package stagnates as a result.  Nobody needs council
> permission under the current policies to become a co-maintainer.  I
> really see this as a case where lack of direction from above is just
> going to lead to a lot of fighting at the ground level.
>
> If the council isn't willing to make policy regarding adding units to
> packages, just where do they expect them to go?
>
> Rich
>

What worries me is that we've reached the point where we need the
Council to define a policy for adding simple text file to packages.
If maintainers can't work things out then a policy can't fix that. We
simply can't have a policy for every single bit. If maintainers refuse
as responsible adults then the problem is deeper. Having to read the
rulebook everytime we want to commit something takes the fun away.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

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

[Rich Freeman]

On Wed, Jun 12, 2013 at 7:17 AM, Markos Chandras <hwoarang@gentoo.org> wrote:
> What worries me is that we've reached the point where we need the
> Council to define a policy for adding simple text file to packages.
> If maintainers can't work things out then a policy can't fix that.

I do agree that ideally this is often a personal issue.  And yet, the
issue still exists.  If a dev wants to add a file to a package and the
maintainer refuses the only way for the dev to get that file in is to
just add themselves as a maintainer, add the file, and send bugmail to
/dev/null other than stuff related to the one file they want to
maintain.  If the first maintainer walks away in a fit then the only
remaining maintainer ends up leaving as well since the only reason
they were there was to override the desires of the first.

It doesn't help when people basically threaten to quit over systemd units.

Rich

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

[Markos Chandras]

On 12 June 2013 12:24, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Jun 12, 2013 at 7:17 AM, Markos Chandras <hwoarang@gentoo.org> wrote:
>> What worries me is that we've reached the point where we need the
>> Council to define a policy for adding simple text file to packages.
>> If maintainers can't work things out then a policy can't fix that.
>
> I do agree that ideally this is often a personal issue.  And yet, the
> issue still exists.  If a dev wants to add a file to a package and the
> maintainer refuses the only way for the dev to get that file in is to
> just add themselves as a maintainer, add the file, and send bugmail to
> /dev/null other than stuff related to the one file they want to
> maintain.  If the first maintainer walks away in a fit then the only
> remaining maintainer ends up leaving as well since the only reason
> they were there was to override the desires of the first.
>
> It doesn't help when people basically threaten to quit over systemd units.
>
> Rich
>

Unfortunately we can't please everyone. This is a FOSS project meaning
you don't get to always do what you want.
You have to be a team player, and you have to think of that users want
even though this is something that you never will
use yourself. I regret to say that but if people threaten to leave
over such minor things, they might as well quit instead of adding more
and more rules.   Sometimes it sounds like a "blackmail" to me.
"Either do that or I will quit". A policy will never fix such
behaviors.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

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

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1137 bytes --]

Am Mittwoch, 12. Juni 2013, 13:24:41 schrieb Rich Freeman:
> On Wed, Jun 12, 2013 at 7:17 AM, Markos Chandras <hwoarang@gentoo.org> 
wrote:
> > What worries me is that we've reached the point where we need the
> > Council to define a policy for adding simple text file to packages.
> > If maintainers can't work things out then a policy can't fix that.
> 
> I do agree that ideally this is often a personal issue.  And yet, the
> issue still exists.  If a dev wants to add a file to a package and the
> maintainer refuses the only way for the dev to get that file in is to
> just add themselves as a maintainer, add the file, and send bugmail to
> /dev/null other than stuff related to the one file they want to
> maintain.  If the first maintainer walks away in a fit then the only
> remaining maintainer ends up leaving as well since the only reason
> they were there was to override the desires of the first.

Well, that's why being a team player can be equally or even more important 
than technical expertise.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Ciaran McCreesh]

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

On Wed, 12 Jun 2013 12:17:53 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:
> What worries me is that we've reached the point where we need the
> Council to define a policy for adding simple text file to packages.

It shouldn't come as a surprise. People have been up in arms about what
is and isn't allowed when it comes to replacing "official Gentoo
software" for a decade now. This isn't anything new.

-- 
Ciaran McCreesh

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

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

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/12/2013 01:26 PM, Ciaran McCreesh wrote:
> On Wed, 12 Jun 2013 12:17:53 +0100 Markos Chandras
> <hwoarang@gentoo.org> wrote:
>> What worries me is that we've reached the point where we need
>> the Council to define a policy for adding simple text file to
>> packages.
> 
> It shouldn't come as a surprise. People have been up in arms about
> what is and isn't allowed when it comes to replacing "official
> Gentoo software" for a decade now. This isn't anything new.
> 

That is, because we like working solutions. (at least when it's about
_replacing_)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRuFvRAAoJEFpvPKfnPDWzAKEH/1U3uojCdWcXTYNVtcQF67Ky
a3aXm9W7yuES6+z3N/1t4tEOIC0JB69WPqIuNEXv2RafrT53zSDNdtofsswFmUEL
cj7XVk2oXy3GbwN9wfgLgWCIN1pqKpYsIQg6tJtQ1miRL0e6ce5nZwGczPuQlovz
m3o91MCvW8rdiDu1N9zkJXfc+sB7HhFx4G9s1D3Oo4vY5SyUGoNXUHQnWhLi2Txu
K36i833wvP2E9uRXnlvDp9UvEhACyJhTjNWZga+AtyzfAeWthjVzlc+B/xcbKMfH
biDlmf1DRblfRbdfcT2z5JmS0rck+UKTTJocLzwpdi433rsIkkHlQpotxeS7bYg=
=lWbF
-----END PGP SIGNATURE-----

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

[Tomáš Chvátal]

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

That is the problem, you ask for distro wide rule that unit files are fine
as Markos says.

We should not have any darn rule just to please one project, the best
council should do is to say that systemd in main tree is fine (which it
already had) and that maitnainers can offload the maintenance burden for
the file to systemd team if they don't want to care about it.

[-- Attachment #2: Type: text/html, Size: 510 bytes --]

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

[Rich Freeman]

On Wed, Jun 12, 2013 at 7:22 AM, Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> We should not have any darn rule just to please one project, the best
> council should do is to say that systemd in main tree is fine (which it
> already had) and that maitnainers can offload the maintenance burden for the
> file to systemd team if they don't want to care about it.

Then could the council at least say that?  Right now they basically
said that if the maintainer doesn't want the file they can remove it,
unless the systemd team signs up as co-maintainers on any package with
hostile maintainers.  They did NOT say that the maintainers should
accept these files and offload the maintenance burden for the file
(something which the systemd team indicated on-list is acceptable to
them).

Rich

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

[Pacho Ramos]

El mié, 12-06-2013 a las 13:22 +0200, Tomáš Chvátal escribió:
> That is the problem, you ask for distro wide rule that unit files are
> fine as Markos says.
> 
> 
> We should not have any darn rule just to please one project, the best
> council should do is to say that systemd in main tree is fine (which
> it already had) and that maitnainers can offload the maintenance
> burden for the file to systemd team if they don't want to care about
> it.

I fully agree

Also, isn't it already being done with prefix (and some hardened like
pax_marking) stuff? Why systemd case needs to be different? (well,
probably people hating systemd so much will know)

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

[Rich Freeman]

On Wed, Jun 12, 2013 at 8:20 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> Also, isn't it already being done with prefix (and some hardened like
> pax_marking) stuff? Why systemd case needs to be different? (well,
> probably people hating systemd so much will know)

It doesn't need to be different.  The issue is that if I ping a
maintainer about adding some prefix variable to their ebuild and they
don't respond, and then I commit that change to their package, then
chances are that all I'll hear back are crickets.  If I were to
instead add a systemd unit to their package there is a chance it will
get reverted, flames on -dev, escalation to devrel, and so on.

Honestly, right now what I'd advocate for systemd unit maintainers is to:
1.  File a bug with the maintainer with a patch asking for the unit to
be added, and indicating that if there is no response in 7 days it
will be commited.
2.  If the maintainer doesn't commit it themselves, then commit it for
them in 7 days.
3.  If the maintainer objects, then if the unit is important tell the
maintainer that you are also going to maintain the package, and commit
it anyway.
4.  If the original maintainer quits, oh well.  Continue to maintain
the package or not per your personal interests.  If the original
maintainer gets into revert-wars/etc escalate to devrel.  As an
additional maintainer be responsive to bugs related to the unit file
you committed.

So, in a sense I agree that no new policy is strictly needed.
However, Council could show some leadership and suggest how people
could work together constructively, whether it is in the particular
manner I suggested or otherwise.

As has already been said in this thread, I don't have a lot of
sympathy for people who threaten to quit when they don't get their
way.

Rich

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

[Markos Chandras]

On 12 June 2013 14:59, Rich Freeman <rich@thefreemanclan.net> wrote:
> So, in a sense I agree that no new policy is strictly needed.
> However, Council could show some leadership and suggest how people
> could work together constructively, whether it is in the particular
> manner I suggested or otherwise.
>

This is bad timing don't you think? The current council is done with
the meetings.
However, people might want to consider that when they get to vote for
new members

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

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

[Alexander V Vershilov]

On 12 June 2013 17:59, Rich Freeman <rich@thefreemanclan.net> wrote:
>
>
> Honestly, right now what I'd advocate for systemd unit maintainers is to:
> 1.  File a bug with the maintainer with a patch asking for the unit to
> be added, and indicating that if there is no response in 7 days it
> will be commited.
> 2.  If the maintainer doesn't commit it themselves, then commit it for
> them in 7 days.

It will be good if commiter will add himself/or systemd team to metadata with
description that unit bugs will be should be assigned to him. As it will add a
level of responsibility for commiter, as he should realize that if
current maintainer is
unable or unwilling to test this part of functionality.

> 3.  If the maintainer objects, then if the unit is important tell the
> maintainer that you are also going to maintain the package, and commit
> it anyway.
> 4.  If the original maintainer quits, oh well.  Continue to maintain
> the package or not per your personal interests.  If the original
> maintainer gets into revert-wars/etc escalate to devrel.  As an
> additional maintainer be responsive to bugs related to the unit file
> you committed.
>
>
> Rich
>

--
--
Alexander

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

[Michał Górny]

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

Dnia 2013-06-12, o godz. 18:16:10
Alexander V Vershilov <qnikst@gentoo.org> napisał(a):

> On 12 June 2013 17:59, Rich Freeman <rich@thefreemanclan.net> wrote:
> >
> >
> > Honestly, right now what I'd advocate for systemd unit maintainers is to:
> > 1.  File a bug with the maintainer with a patch asking for the unit to
> > be added, and indicating that if there is no response in 7 days it
> > will be commited.
> > 2.  If the maintainer doesn't commit it themselves, then commit it for
> > them in 7 days.
> 
> It will be good if commiter will add himself/or systemd team to metadata with
> description that unit bugs will be should be assigned to him. As it will add a
> level of responsibility for commiter, as he should realize that if
> current maintainer is
> unable or unwilling to test this part of functionality.

I don't understand why do we need to treat systemd special here.

If package fails on Prefix, bugs are usually assigned to Prefix
directly. If package fails due to bug in another package, sometimes
even bug wranglers CC relevant people to help maintainer settling on
where the problem lies.

Now, why does every package supposedly need systemd@ as co-maintainer?
I don't think it's usually hard to see that a particular bug report is
relevant to systemd and reassign/CC. Even bug wranglers can CC systemd
if anything related to systemd is involved.

The major point of teams like systemd@g.o is to *help*, and supervise
for a consistent user experience. We are practically involved in
anything related to systemd units and I don't think there needs to be
a special <maintainer/> tag to get us CC-ed.

-- 
Best regards,
Michał Górny

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

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

[Rich Freeman]

On Wed, Jun 12, 2013 at 10:25 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Now, why does every package supposedly need systemd@ as co-maintainer?
> I don't think it's usually hard to see that a particular bug report is
> relevant to systemd and reassign/CC. Even bug wranglers can CC systemd
> if anything related to systemd is involved.

I agree that it shouldn't be necessary.  However, absent some policy
change, it might be necessary in the case of maintainers hostile to
systemd.  Otherwise the maintainer will just revert the change and
hide behind the standing policy that maintainers basically have the
final say.  That really isn't the intent of the current policy, but
that is basically what it boils down to.

What all of this really amounts to is a bunch of people who don't want
to work together trying to legally apply the rules to accomplish their
personal goals, whatever they may be.

Honestly, if the Council just said "we don't want to make this a
policy, but if systemd maintainers are willing to handle the bugs
package maintainers should let them add units because that is the
spirit of the existing policy" I'd be a lot happier.

Rich

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

[Ben de Groot]

On 12 June 2013 22:52, Rich Freeman <rich0@gentoo.org> wrote:
> What all of this really amounts to is a bunch of people who don't want
> to work together trying to legally apply the rules to accomplish their
> personal goals, whatever they may be.

"Do what I say, or I will take over your package and do it anyway" is
a really funny way of working together...

In most places I know this would be called bullying. I don't want to
spend my free time on a project that condones that kind of behaviour.

--
Cheers,

Ben | yngwin
Gentoo developer

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

[hasufell]

On 06/12/2013 05:41 PM, Ben de Groot wrote:
> On 12 June 2013 22:52, Rich Freeman <rich0@gentoo.org> wrote:
>> What all of this really amounts to is a bunch of people who don't want
>> to work together trying to legally apply the rules to accomplish their
>> personal goals, whatever they may be.
> 
> "Do what I say, or I will take over your package and do it anyway" is
> a really funny way of working together...
> 
> In most places I know this would be called bullying. I don't want to
> spend my free time on a project that condones that kind of behaviour.
> 

You are not giving _any_ kind of technical argument against the proposed
enhancement... except authority.

And that is not enough.

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

[Ulrich Mueller]

>>>>> On Wed, 12 Jun 2013, hasufell  wrote:

> On 06/12/2013 05:41 PM, Ben de Groot wrote:
>> "Do what I say, or I will take over your package and do it anyway"
>> is a really funny way of working together...
>> 
>> In most places I know this would be called bullying. I don't want
>> to spend my free time on a project that condones that kind of
>> behaviour.

> You are not giving _any_ kind of technical argument against the
> proposed enhancement... except authority.

> And that is not enough.

There was the argument that the unit file wasn't accepted upstream,
and I wouldn't dismiss this lightly. Often it's a cleaner solution if
files foreign to a package are installed by a separate supplementary
package. It avoids recompilation of the original package by the user,
for example.

Ulrich

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

[hasufell]

On 06/12/2013 06:16 PM, Ulrich Mueller wrote:
>>>>>> On Wed, 12 Jun 2013, hasufell  wrote:
> 
>> On 06/12/2013 05:41 PM, Ben de Groot wrote:
>>> "Do what I say, or I will take over your package and do it anyway"
>>> is a really funny way of working together...
>>>
>>> In most places I know this would be called bullying. I don't want
>>> to spend my free time on a project that condones that kind of
>>> behaviour.
> 
>> You are not giving _any_ kind of technical argument against the
>> proposed enhancement... except authority.
> 
>> And that is not enough.
> 
> There was the argument that the unit file wasn't accepted upstream

That probably goes for a lot of openrc scripts as well.

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

[Tomáš Chvátal]

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

2013/6/12 Ulrich Mueller <ulm@gentoo.org>

>
> There was the argument that the unit file wasn't accepted upstream,
> and I wouldn't dismiss this lightly. Often it's a cleaner solution if
> files foreign to a package are installed by a separate supplementary
> package. It avoids recompilation of the original package by the user,
> for example.
>

So is openrc file.
So is logrotate file.
So are cron scripts.

Come on... lets split everything out for the fun.

[-- Attachment #2: Type: text/html, Size: 893 bytes --]

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

[Ulrich Mueller]

>>>>> On Wed, 12 Jun 2013, Tomáš Chvátal wrote:

>> There was the argument that the unit file wasn't accepted upstream,
>> and I wouldn't dismiss this lightly. Often it's a cleaner solution
>> if files foreign to a package are installed by a separate
>> supplementary package. It avoids recompilation of the original
>> package by the user, for example.

> So is openrc file.
> So is logrotate file.
> So are cron scripts.

I was more thinking about support files for Emacs, where we do this
all the time: If the file is included with the upstream package, it's
being installed by that package's ebuild. Otherwise, it will go into
its own separate package. (And I guess it is similar for Vim.)

> Come on... lets split everything out for the fun.

That I didn't say. It's perfectly fine if a package installs its
openrc or cron script, if the package maintainer thinks that this is
the best way to handle things. But it is not the only possible
solution, technically.

Ulrich

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

[Michał Górny]

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

Dnia 2013-06-12, o godz. 18:37:08
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >>>>> On Wed, 12 Jun 2013, Tomáš Chvátal wrote:
> 
> >> There was the argument that the unit file wasn't accepted upstream,
> >> and I wouldn't dismiss this lightly. Often it's a cleaner solution
> >> if files foreign to a package are installed by a separate
> >> supplementary package. It avoids recompilation of the original
> >> package by the user, for example.
> 
> > So is openrc file.
> > So is logrotate file.
> > So are cron scripts.
> 
> I was more thinking about support files for Emacs, where we do this
> all the time: If the file is included with the upstream package, it's
> being installed by that package's ebuild. Otherwise, it will go into
> its own separate package. (And I guess it is similar for Vim.)

That's very inconsistent and therefore problematic for users. Some
packages work out-of-the-box, others require manually merging
additional packages...

I was thinking of trying to find a better way of providing support
files. I thought about it for a minute then decide it's not really
worth it. There's no simpler and more efficient way than just adding
that tiny file to the package.

Even if that sums up to 10 different files, no other solution can be
better. If you introduce additional packages, the ebuilds, cache, vardb
-- it is all going to take up more space than those installed files.

-- 
Best regards,
Michał Górny

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

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

[Markos Chandras]

On 12 June 2013 17:51, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2013-06-12, o godz. 18:37:08
> Ulrich Mueller <ulm@gentoo.org> napisał(a):
>
>> >>>>> On Wed, 12 Jun 2013, Tomáš Chvátal wrote:
>>
>> >> There was the argument that the unit file wasn't accepted upstream,
>> >> and I wouldn't dismiss this lightly. Often it's a cleaner solution
>> >> if files foreign to a package are installed by a separate
>> >> supplementary package. It avoids recompilation of the original
>> >> package by the user, for example.
>>
>> > So is openrc file.
>> > So is logrotate file.
>> > So are cron scripts.
>>
>> I was more thinking about support files for Emacs, where we do this
>> all the time: If the file is included with the upstream package, it's
>> being installed by that package's ebuild. Otherwise, it will go into
>> its own separate package. (And I guess it is similar for Vim.)
>
> That's very inconsistent and therefore problematic for users. Some
> packages work out-of-the-box, others require manually merging
> additional packages...
>
> I was thinking of trying to find a better way of providing support
> files. I thought about it for a minute then decide it's not really
> worth it. There's no simpler and more efficient way than just adding
> that tiny file to the package.
>
> Even if that sums up to 10 different files, no other solution can be
> better. If you introduce additional packages, the ebuilds, cache, vardb
> -- it is all going to take up more space than those installed files.
>
> --
> Best regards,
> Michał Górny

This entire thread proves how immature we are as a developer community
and that we rather
ignore our users for the sake of our interests and stubbornness. And
of course this is a classic example
of a non-existing or bad leadership.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

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

[Ulrich Mueller]

>>>>> On Wed, 12 Jun 2013, Michał Górny wrote:

>> I was more thinking about support files for Emacs, where we do this
>> all the time: If the file is included with the upstream package,
>> it's being installed by that package's ebuild. Otherwise, it will
>> go into its own separate package. (And I guess it is similar for
>> Vim.)

> That's very inconsistent and therefore problematic for users. Some
> packages work out-of-the-box, others require manually merging
> additional packages...

There's nothing inconsistent about it. Different upstream, different
versioning scheme, different release cycles, therefore it goes into
its own package. Everything else would just be messy.

I guess it often would be a case for SDEPEND, but we don't have that
yet.

Ulrich

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

[Rich Freeman]

On Wed, Jun 12, 2013 at 3:50 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Wed, 12 Jun 2013, Michał Górny wrote:
>
>>> I was more thinking about support files for Emacs, where we do this
>>> all the time: If the file is included with the upstream package,
>>> it's being installed by that package's ebuild. Otherwise, it will
>>> go into its own separate package. (And I guess it is similar for
>>> Vim.)
>
>> That's very inconsistent and therefore problematic for users. Some
>> packages work out-of-the-box, others require manually merging
>> additional packages...
>
> There's nothing inconsistent about it. Different upstream, different
> versioning scheme, different release cycles, therefore it goes into
> its own package. Everything else would just be messy.
>

We're talking about stuff like openrc init.d scripts, logrotate
scripts, systemd units, and so on.

Do we really want postfix-binaries, postfix-upstreamconfig (which
points to directories we don't actually install stuff in),
postfix-gentooconfig (which actually works), postfix-openrc,
postfix-logrotate, postfix-systemd, postfix-selinux, and so on?  In
order to avoid installing a 1kb systemd unit file we'll instead dump
an extra 5 packages in /usr/portage complete with each having a
filesdir, manifest, changelog, and ebuilds, more cruft in various
caches, edb, and so on.

If you want a vanilla postfix install, just download it from upstream,
or go build your own LFS system.  The whole point of a distro is to do
basic integration, and not simply be a glorified upstream mirror.
Gentoo is light on integration by design, but that doesn't mean that
we can't ship init scripts, or systemd units.

When you're talking about substantial amounts of modular change
splitting packages makes sense.  However, we really shouldn't be
splitting them over a single file, unless that file is somehow really
destructive simply by being around (hence flags to control .la files
and such).

Rich

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

[William Hubbs]

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

On Wed, Jun 12, 2013 at 07:35:53PM +0100, Markos Chandras wrote:
> This entire thread proves how immature we are as a developer community
> and that we rather
> ignore our users for the sake of our interests and stubbornness. And
> of course this is a classic example
> of a non-existing or bad leadership.

Markos,

you are absolutely right. There are developers in this distro who will
ignore users, and other developers, in order to pursue their personal
agendas.

You are also right about over-all leadership in this distribution. Parts
of it are non-existent and parts of it are afraid to make controvercial
decisions, so things have not gotten done.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michał Górny]

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

Dnia 2013-06-12, o godz. 23:41:39
Ben de Groot <yngwin@gentoo.org> napisał(a):

> On 12 June 2013 22:52, Rich Freeman <rich0@gentoo.org> wrote:
> > What all of this really amounts to is a bunch of people who don't want
> > to work together trying to legally apply the rules to accomplish their
> > personal goals, whatever they may be.
> 
> "Do what I say, or I will take over your package and do it anyway" is
> a really funny way of working together...
> 
> In most places I know this would be called bullying. I don't want to
> spend my free time on a project that condones that kind of behaviour.

Please don't turn this into word-picking and proper grammar kind
of debate. If we're really to discuss how people word their requests
and so on... it's just not worth it.

The point is that we have global kind of policies. We have common
policies which map to specific policies, and all that we can do is to
expect developers to follow those policies until they have good
*technical* reasons not to.

Please remember that Gentoo is a project, a whole. If there
is a general consensus on something, a single developer should not
stand in the way and shout 'liberum veto'.

Bullying is not the best way of enforcing that consensus. But
the person refusing to follow the policy is not free of guilt either.
In a perfect world, it would be just a nice conversation with
the developer who would accept the global decision.

-- 
Best regards,
Michał Górny

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

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

[Rich Freeman]

On Wed, Jun 12, 2013 at 11:41 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 12 June 2013 22:52, Rich Freeman <rich0@gentoo.org> wrote:
>> What all of this really amounts to is a bunch of people who don't want
>> to work together trying to legally apply the rules to accomplish their
>> personal goals, whatever they may be.
>
> "Do what I say, or I will take over your package and do it anyway" is
> a really funny way of working together...
>
> In most places I know this would be called bullying. I don't want to
> spend my free time on a project that condones that kind of behaviour.

What part of this is bullying?  Asking nicely and then assuming
responsibility for a change if there is an objection?  Or, saying that
somebody else is not welcome to make their additions to a package no
matter what?  Adding a unit file isn't going to cause you harm, and if
you feel otherwise you can always ask the Council for a ruling.

Maintainers MAINTAIN packages, they don't own them.  They're expected
to cooperate with other projects, and if they're going to point at the
rules to justify blocking work others are doing they shouldn't be
surprised if others find rules to point at as well.

Rich

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

[Ben de Groot]

On 13 June 2013 11:12, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Jun 12, 2013 at 11:41 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>> On 12 June 2013 22:52, Rich Freeman <rich0@gentoo.org> wrote:
>>> What all of this really amounts to is a bunch of people who don't want
>>> to work together trying to legally apply the rules to accomplish their
>>> personal goals, whatever they may be.
>>
>> "Do what I say, or I will take over your package and do it anyway" is
>> a really funny way of working together...
>>
>> In most places I know this would be called bullying. I don't want to
>> spend my free time on a project that condones that kind of behaviour.
>
> What part of this is bullying?

The part where someone takes over the package and forces a change that
is objected to by the current maintainer, and you expect him to just
let this happen.

> Adding a unit file isn't going to cause you harm,

In my opinion such a feature request should be sent upstream. It's not
like systemd is obscure.

> and if
> you feel otherwise you can always ask the Council for a ruling.

I'm pretty sure they will vote in favour of those who seem to have the
strongest voice.

> Maintainers MAINTAIN packages, they don't own them.  They're expected
> to cooperate with other projects, and if they're going to point at the
> rules to justify blocking work others are doing they shouldn't be
> surprised if others find rules to point at as well.

Cooperation doesn't include hostile take-over.

And as I said, in my opinion feature requests belong upstream.

If what you're proposing is going to be standard practice in Gentoo,
then I will be looking for a friendlier environment to spend my time
on.
--
Cheers,

Ben | yngwin
Gentoo developer

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

[Rich Freeman]

On Fri, Jun 14, 2013 at 9:09 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>
> Cooperation doesn't include hostile take-over.

It also doesn't include hostile maintainers planting their feet.
There is no take-over.  You're welcome to maintain everything but the
unit file and pretend the unit file isn't there.

>
> And as I said, in my opinion feature requests belong upstream.

It has been stated, and most seem to disagree that this is a feature
request.  There are lots of things Gentoo does that I disagree with.
In the case where it has been considered and I'm just in the minority,
I have to live with that.  If it were up to me council and trustee
members could overlap, because I feel that it reduces the risk of
conflict between the groups (even though this has never been a
problem).  Others feel that they'd rather have more independence and
more people covering those important roles.  I'm in the minority, so I
follow the rules until the rest of you realize that you're wrong.  :)

>
> If what you're proposing is going to be standard practice in Gentoo,
> then I will be looking for a friendlier environment to spend my time
> on.

I'd really hope that you'd reconsider.  The intent is for the systemd
team to do everything they can to avoid making your life as a
maintainer more difficult.  However, if the concern is an ideological
one and not a practical one I understand.  There are some Debian
maintainers who object strongly to non-free software in the main
repository, and they probably would not want to work on Gentoo as a
result because we do allow non-free software in our main repository.
That's a value call, but most Gentoo devs would rather keep the
packages even if it means possibly turning them away (not that they
wouldn't be welcome for our part).

I understand where you're coming from - I tend to be a bit of an
idealist myself.  I have to resist sending hate-bugspam to Mozilla
every time I get pinged because somebody else adds themselves to the
CACert bug which has hundreds of people CC'ed.  I'm sure some of my
emails on this list have annoyed quite a few at times as I can be
fairly stubborn until persuaded (you should see the emails I delete
before sending!).  I suspect that this is a common trait among FOSS
developers - skill levels and as a result confidence tends to run high
and that makes it hard to compromise.  I think we stick around because
we realize that there really isn't anything better out there, and on
our own we are worse off.

We really can't operate if individual package maintainers can dictate
policy that impacts tree-wide initiatives.  Individual maintainers
can't turn away freedesktop entries, init scripts, logrotate/tmpreaper
configs, and systemd units are really no different.  Gentoo isn't just
a mirror of upstream tarballs - we integrate.

Rich

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

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
> On Fri, Jun 14, 2013 at 9:09 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>> Cooperation doesn't include hostile take-over.
> It also doesn't include hostile maintainers planting their feet.
> There is no take-over.  You're welcome to maintain everything but the
> unit file and pretend the unit file isn't there.

I was always under the general impression that a maintainer is free to
do whatever he likes with his package within policy. When p.mask'ed even
outside policy to some degree. If you disagree with how a package is
maintained, you are welcome to fork the ebuild and do it better.


Best regards,
Chí-Thanh Christopher Nguyễn

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

[Rich Freeman]

On Fri, Jun 14, 2013 at 10:51 AM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> I was always under the general impression that a maintainer is free to
> do whatever he likes with his package within policy. When p.mask'ed even
> outside policy to some degree. If you disagree with how a package is
> maintained, you are welcome to fork the ebuild and do it better.

Sure, but there is more than one maintainer - the original one, and
the one who signed up because the original one was being stubborn.
They're both welcome to do whatever they want within policy.  However,
the users don't exactly benefit from daily revision wars.

Maintainers don't have the right to exclude others from also being
maintainers, and when they do become maintainers they have all the
rights the original maintainer had.  Nobody owns a package.

Bottom line is that bad things happen when developers become stubborn
and don't cooperate.  However, the fact that maintainers aren't
cooperating isn't a reason to delay progress.  You can't give every
developer a veto on every project in Gentoo or nothing will get done.
If the standing policies aren't working for somebody they can always
go to Council - that's what it is there for.  The standing policies
say that anybody can maintain anything, and when it gets bigger than
that you have projects that elect leads.

Rich

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

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/14/2013 11:24 AM, Rich Freeman wrote:
> On Fri, Jun 14, 2013 at 10:51 AM, Chí-Thanh Christopher Nguyễn
> <chithanh@gentoo.org> wrote:
>> I was always under the general impression that a maintainer is free to
>> do whatever he likes with his package within policy. When p.mask'ed even
>> outside policy to some degree. If you disagree with how a package is
>> maintained, you are welcome to fork the ebuild and do it better.
> 
> Sure, but there is more than one maintainer - the original one, and
> the one who signed up because the original one was being stubborn.
> They're both welcome to do whatever they want within policy.  However,
> the users don't exactly benefit from daily revision wars.
> 
> Maintainers don't have the right to exclude others from also being
> maintainers, and when they do become maintainers they have all the
> rights the original maintainer had.  Nobody owns a package.

Actually they do.  I've been removed from metadata.xml multiple times
from different packages.  Or was something unfair happening?

Personally I think it's bull, but it seems to be status quo and unless
there is an official policy stating otherwise....

- -Zero

> 
> Bottom line is that bad things happen when developers become stubborn
> and don't cooperate.  However, the fact that maintainers aren't
> cooperating isn't a reason to delay progress.  You can't give every
> developer a veto on every project in Gentoo or nothing will get done.
> If the standing policies aren't working for somebody they can always
> go to Council - that's what it is there for.  The standing policies
> say that anybody can maintain anything, and when it gets bigger than
> that you have projects that elect leads.
> 
> Rich
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRuz0OAAoJEKXdFCfdEflK5aMP/3oqd3PQekSVOEaUsgiAXd9I
MjVgnux5sF4w90gGfs74vIoY1GxfXA6JeIEz0TI4+ZwvL4EHCQq2XSXWf5lLsuwl
NFJ1qB5tnaoBh2QGarXsx+c9X9bbP02ozBLgl7mhSK1iB4J90nDdVmbRUR5CQVpJ
99ZdWWywaZIV+yDFs/udlKTEU6WDoZ3/eWxa4zHMTu8WZ2HSvJH+WyNOSdqph1VR
U7sLKtNNHsln5VpOYTlRRQ0nSkNMv9CBBegNLhdO/lGaltiY/utfxdckX95kagQI
LNpizt53W47N4dLiEH9omw/JGJ8qlPRXlgbSfXc5OzMEEbYpL6AHw4l6+JvkwM1M
j2S40Wv4ZP3spOqp0BD7kU97cZ/5kF0ez6okpbSmeZdk1rXH/w1rcLnckXqB98cf
F6eJ55O/Ap7lA5uuTa+KpEc5/m4Dpiatakk0/p1zZl30nJmZC5sbL4hrE1hDjL1R
ZORjMI5JiV3Zr7QZ56DdqyHBbnGVmLIuVEGXquY5CFFr6s0DOMiMrREjTEhHHIcM
J/EiPzrDjkJ2nFu8T1m3Jy8s6m1/xgcgr0kVHH/EZjqnpHAH0mthIEOftxYMir5X
khocm7eO0hO3SmaCiiFuudcT2gLxokO4THfVvMjNc32xZ56Z1HFIGW3cDhiTreYN
FX7FR769RNMEKs/GJOKZ
=6IWg
-----END PGP SIGNATURE-----

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

[Rich Freeman]

On Fri, Jun 14, 2013 at 11:55 AM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> On 06/14/2013 11:24 AM, Rich Freeman wrote:
>> Maintainers don't have the right to exclude others from also being
>> maintainers, and when they do become maintainers they have all the
>> rights the original maintainer had.  Nobody owns a package.
>
> Actually they do.  I've been removed from metadata.xml multiple times
> from different packages.  Or was something unfair happening?
>
> Personally I think it's bull, but it seems to be status quo and unless
> there is an official policy stating otherwise....

I could have sworn there was something written, but I can't find much.

So, this is basically how I see things working, and if it isn't how
things are working it is how they should be working.  :)  (By all
means chime in if you feel otherwise.)

Packages can be maintained by individuals in which case anybody who
wants to maintain the package can do so, and they're all equals.

Packages can be maintained by projects, perhaps as part of a herd.
Anybody can start/join a project, and project members elect a head
annually.  Projects have more authority than individuals (that just
makes sense).  Devrel and QA are special projects that have different
rules.

Council is the ultimate authority for non-legal matters, and is the
final appeal.

So, anybody can sign up to maintain whatever they want if it isn't run
by a project - nobody can kick them out.  If one or more packages are
important enough that this doesn't make sense a project should exist
to maintain them.  For example, you can't just sign up to go changing
kdelibs without coordinating with the kde project (I'd consider them
as a model of a well-run project at the moment).  Since project leads
have more authority they have a mandate via elections.  Then if
projects are in conflict or things get out of hand there are devrel
and the council to step in.

The whole point of the metastructure GLEP is to avoid overhead and
formality, but to still have some semblance of order.

Bottom line though is that Michał has it right.  We're a team that
works together.  When it is obvious that you're swimming against the
stream you need to change direction.  Gentoo is fairly accommodating
in letting people do weird things on the side that are even
contradictory to the mainstream, but they have to be on the side.
Users really need a decent day-to-day experience with the packages in
the main tree.

Rich

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

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
> Packages can be maintained by individuals in which case anybody who
> wants to maintain the package can do so, and they're all equals.

In my understanding, nobody can monopolize a certain piece of software.
So if developer A maintains package X, and developer B disagrees with
his decisions, then he can fork and commit his ebuild for X under a
different name (say, X-betterthanfromA). So users and other developers
can choose what they like more.

So if you want systemd support for a particular package, you do not need
the agreement of the maintainer. Just commit your own package, and
nobody else will have a say in that.

> Packages can be maintained by projects, perhaps as part of a herd.
> Anybody can start/join a project, and project members elect a head
> annually.  Projects have more authority than individuals (that just
> makes sense).  Devrel and QA are special projects that have different
> rules.

I believe QA has no authority to (functionally) change packages,
although they can p.mask whatever they consider unacceptable. Besides, I
do not think that it makes sense here to distinguish between individual
developers maintaining individual packages, herds (package maintenance
groups) and projects.

> Bottom line though is that Michał has it right.  We're a team that
> works together.  When it is obvious that you're swimming against the
> stream you need to change direction.  Gentoo is fairly accommodating
> in letting people do weird things on the side that are even
> contradictory to the mainstream, but they have to be on the side.
> Users really need a decent day-to-day experience with the packages in
> the main tree.

This is something I fundamentally do not agree with. Gentoo is not a
team that works together. There is no set direction (or "stream").
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.


Best regards,
Chí-Thanh Christopher Nguyễn

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

[Tom Wijsman]

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

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

> So users and other developers can choose what they like more.

I don't think they will like half of the files being in the package X
and the other half being in a different package X-systemd and yet
another half being stuffed in a collective package systemd-units.

Oh, and not to forget about X-openrc, X-cron, X-..., ... and so on.

Putting the maintenance burden on users is the worst thing we can do.

> I believe QA has no authority to (functionally) change packages,
> although they can p.mask whatever they consider unacceptable.

Define "unacceptable", maybe they'll mask the X-whatever packages in the
future because it has turned into a mess; such a mess we can't easily
migrate away from, because we first have to start another 5 threads...

> Besides, I do not think that it makes sense here to distinguish
> between individual developers maintaining individual packages, herds
> (package maintenance groups) and projects.

They were probably just examples; I don't advocate the idea he
explained there, but I'm against all the alternatives that are being
suggested. They might make sense from a "making maintainers happy"
perspective, but in practice it just damages the user experience.

> This is something I fundamentally do not agree with. Gentoo is not a
> team that works together.

It's not like in a sports game, but we are people working together; we
may not pursue the same thing, but we should pursue what is best for
our users. Whatever way you go, the users will end up experiencing it.

> There is no set direction (or "stream").

Then why do we have an about page documenting one? There is.

> 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.

-- 
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 --]

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

[Chí-Thanh Christopher Nguyễn]

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.

> Putting the maintenance burden on users is the worst thing we can do.

Users have no extra maintenance burden in this case. Users have to make
informed decisions, which is something they have to do all the time
anyway when using Gentoo.

>> I believe QA has no authority to (functionally) change packages,
>> although they can p.mask whatever they consider unacceptable.
>
> Define "unacceptable", maybe they'll mask the X-whatever packages in the
> future because it has turned into a mess; such a mess we can't easily
> migrate away from, because we first have to start another 5 threads...

IIRC, QA needs no formal justification for masking a package.

>> This is something I fundamentally do not agree with. Gentoo is not a
>> team that works together.
>
> It's not like in a sports game, but we are people working together; we
> may not pursue the same thing, but we should pursue what is best for
> our users. Whatever way you go, the users will end up experiencing it.

You are free to pursue what you think is best for any particular group
of users that you care about. Just don't expect anybody else to share
that ambition.

x11 team decided some time ago that we would not let proprietary drivers
hinder the progress of X.org packages. 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? Ubuntu for example thinks that this
serves their users best, and I tend to agree. After all, it solves a lot
of headache and confusion for blob users.

However for all *I* care, blob users can go use Windows. Other
developers care more, and put a lot of effort into making the blobs
palatable on Gentoo.

>> There is no set direction (or "stream").
>
> Then why do we have an about page documenting one? There is.

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.

>> 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. If you disagree
with another developer, you of course are entitled to complain loudly
and try to convince him of your way.


Best regards,
Chí-Thanh Christopher Nguyễn

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

[Tom Wijsman]

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

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.

> > 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.

> >> I believe QA has no authority to (functionally) change packages,
> >> although they can p.mask whatever they consider unacceptable.
> >
> > Define "unacceptable", maybe they'll mask the X-whatever packages
> > in the future because it has turned into a mess; such a mess we
> > can't easily migrate away from, because we first have to start
> > another 5 threads...
> 
> 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?

> >> This is something I fundamentally do not agree with. Gentoo is not
> >> a team that works together.
> >
> > It's not like in a sports game, but we are people working together;
> > we may not pursue the same thing, but we should pursue what is best
> > for our users. Whatever way you go, the users will end up
> > experiencing it.
> 
> You are free to pursue what you think is best for any particular group
> of users that you care about. Just don't expect anybody else to share
> that ambition.

They don't have to, because there is no reason for them to be bothered;
at least not in the sense of caring for any group of users.

> 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.

> 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.

> Ubuntu for example thinks that this serves their users best,
> and I tend to agree. After all, it solves a lot of headache and
> confusion for blob users.

Agreed.

> 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.

> Other developers care more, and put a lot of effort into making the
> blobs palatable on Gentoo.

Glad they do.

> >> There is no set direction (or "stream").
> >
> > Then why do we have an about page documenting one? There is.
> 
> 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?

> >> 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.

> 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...

-- 
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 --]

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

[Chí-Thanh Christopher Nguyễn]

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).

>
>
>>> 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.


>> 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.

>> You are free to pursue what you think is best for any particular group
>> of users that you care about. Just don't expect anybody else to share
>> that ambition.
>
> They don't have to, because there is no reason for them to be bothered;
> at least not in the sense of caring for any group of users.

Indeed.

>> 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].

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

>> 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.
>> 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.

>> Other developers care more, and put a lot of effort into making the
>> blobs palatable on Gentoo.
>
> Glad they do.

Yes, that is very cool.

>> 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.

>>>> 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.

>> 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. 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.


Best regards,
Chí-Thanh Christopher Nguyễn


[1] https://bugs.gentoo.org/show_bug.cgi?id=462656
[2] https://lkml.org/lkml/1999/2/8/13

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

[Tom Wijsman]

[-- 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 --]

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

[Rich Freeman]

On Sat, Jun 15, 2013 at 6:31 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Sat, 15 Jun 2013 14:01:47 +0430
> Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
>
>> 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?

++

I don't really think this libertarian where there are 14 versions of
glibc in the tree actually exists.  I'm not really sure there is a
single example of the same package (with the same upstream) being
mantained even two ways in the tree, and if there happens to be one it
is a rare situation indeed.  I don't think there is harm in having it
happen on occasion, but it really can't be the rule.

We can barely maintain the packages we have.  We won't improve the
situation by having 3 different editions of postfix in the tree.
Maybe one has a really good config file that "just works" on install,
another includes an openrc script but hasn't been updated in a year,
and another includes a systemd script.  Do we expect users to install
all three into chroots and then manually merge the parts that are sane
from each onto their system because three devs don't want to talk to
each other and maintain a single package even though the work they are
doing has no technical incompatibilities?

If a developer doesn't want to work on blobs like nvidia-drivers or
whatever, then that isn't a big deal - just don't help out with that
package.  The issue here is when devs want to essentially block the
work of others, even though the other dev is willing to do the work to
ensure that quality is good for the end-users and accept any bugs that
result.  That is essentially territorialism and it doesn't benefit
Gentoo at all.

Distros are about integration.  That is really the only value that we
add.  Users can pull packages from upstream if they just want upstream
tarballs.  Anything we do to make integration smoother for users makes
Gentoo more useful.  We generally try to avoid integration that
interferes with choice and that is what distinguishes us from most
other distros.  However, installing systemd units does not interfere
with choice (users can even choose to mask them fairly trivially).

When we do work for Gentoo, we ought to be doing it for the benefit of
Gentoo.  It is a win/win when we can scratch our own back and Gentoo's
at the same time.  However, if there is a conflict of interest it is
our duty as developers to look out for Gentoo before our own
interests, or at least step aside.  Just ask yourself, "am I getting
as much out of Gentoo as I'm giving?"  I think for most of us the
answer is a clear "yes!"  If not, then perhaps this isn't the right
place to contribute.

Rich

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

[Pandu Poluan]

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

Well, I'm 'just' a user of Gentoo, but please allow me to share my 2
cents...

On Jun 15, 2013 5:52 PM, "Rich Freeman" <rich0@gentoo.org> wrote:
>
> On Sat, Jun 15, 2013 at 6:31 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> > On Sat, 15 Jun 2013 14:01:47 +0430
> > Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> >
> >> 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?
>
> ++
>
> I don't really think this libertarian where there are 14 versions of
> glibc in the tree actually exists.  I'm not really sure there is a
> single example of the same package (with the same upstream) being
> mantained even two ways in the tree, and if there happens to be one it
> is a rare situation indeed.  I don't think there is harm in having it
> happen on occasion, but it really can't be the rule.
>
> We can barely maintain the packages we have.  We won't improve the
> situation by having 3 different editions of postfix in the tree.
> Maybe one has a really good config file that "just works" on install,
> another includes an openrc script but hasn't been updated in a year,
> and another includes a systemd script.  Do we expect users to install
> all three into chroots and then manually merge the parts that are sane
> from each onto their system because three devs don't want to talk to
> each other and maintain a single package even though the work they are
> doing has no technical incompatibilities?
>
> If a developer doesn't want to work on blobs like nvidia-drivers or
> whatever, then that isn't a big deal - just don't help out with that
> package.  The issue here is when devs want to essentially block the
> work of others, even though the other dev is willing to do the work to
> ensure that quality is good for the end-users and accept any bugs that
> result.  That is essentially territorialism and it doesn't benefit
> Gentoo at all.
>

Very well put. I call this concept "sub-maintainer".

Users wanting systemd support files should get them by specifying
USE=systemd

Users who don't want systemd files? They should specify USE=-systemd

But everything is in one package. THAT is how everything is supposed to be.
From the users' point of view.

Gentoo is about choice, and the well-known mechanism for specifying one's
choice, is the USE flags. This is well-known not only within the Gentoo
community, but also other communities.

Not by specifying "X-systemd for systemd users, X-openrc for OpenRC users,
etc."

Rgds,
--

[-- Attachment #2: Type: text/html, Size: 3453 bytes --]

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

[Rich Freeman]

On Sat, Jun 15, 2013 at 8:31 AM, Pandu Poluan <pandu@poluan.info> wrote:
> Users who don't want systemd files? They should specify USE=-systemd
>

That's been debated to death.  Honestly, I could care less which
mechanism we use to control installation of unit files, but we should
be consistent.  USE=systemd for unit files makes about as much sense
as USE=openrc or USE=tmpreaper or USE=logrotate.  Do it one way or the
other.

Rich

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

[Canek Peláez Valdés]

On Sat, Jun 15, 2013 at 7:31 AM, Pandu Poluan <pandu@poluan.info> wrote:
> Well, I'm 'just' a user of Gentoo, but please allow me to share my 2
> cents...
>
> On Jun 15, 2013 5:52 PM, "Rich Freeman" <rich0@gentoo.org> wrote:
>>
>> On Sat, Jun 15, 2013 at 6:31 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
>> > On Sat, 15 Jun 2013 14:01:47 +0430
>> > Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
>> >
>> >> 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?
>>
>> ++
>>
>> I don't really think this libertarian where there are 14 versions of
>> glibc in the tree actually exists.  I'm not really sure there is a
>> single example of the same package (with the same upstream) being
>> mantained even two ways in the tree, and if there happens to be one it
>> is a rare situation indeed.  I don't think there is harm in having it
>> happen on occasion, but it really can't be the rule.
>>
>> We can barely maintain the packages we have.  We won't improve the
>> situation by having 3 different editions of postfix in the tree.
>> Maybe one has a really good config file that "just works" on install,
>> another includes an openrc script but hasn't been updated in a year,
>> and another includes a systemd script.  Do we expect users to install
>> all three into chroots and then manually merge the parts that are sane
>> from each onto their system because three devs don't want to talk to
>> each other and maintain a single package even though the work they are
>> doing has no technical incompatibilities?
>>
>> If a developer doesn't want to work on blobs like nvidia-drivers or
>> whatever, then that isn't a big deal - just don't help out with that
>> package.  The issue here is when devs want to essentially block the
>> work of others, even though the other dev is willing to do the work to
>> ensure that quality is good for the end-users and accept any bugs that
>> result.  That is essentially territorialism and it doesn't benefit
>> Gentoo at all.
>>
>
> Very well put. I call this concept "sub-maintainer".
>
> Users wanting systemd support files should get them by specifying
> USE=systemd
>
> Users who don't want systemd files? They should specify USE=-systemd

Wrong. Users who don't want systemd files should set INSTALL_MASK. The
same for users who don't want OpenRC scripts, or logrotate scripts.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

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

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
> I don't really think this libertarian where there are 14 versions of
> glibc in the tree actually exists.  I'm not really sure there is a
> single example of the same package (with the same upstream) being
> mantained even two ways in the tree, and if there happens to be one it
> is a rare situation indeed.  I don't think there is harm in having it
> happen on occasion, but it really can't be the rule.
> 
> We can barely maintain the packages we have.  We won't improve the
> situation by having 3 different editions of postfix in the tree.

Of course there is no reasonable way to deal with 14 glibc or 3 postfix
versions. If the situation becomes like this the policy (GLEP 39) may need
reconsideration.

> If a developer doesn't want to work on blobs like nvidia-drivers or
> whatever, then that isn't a big deal - just don't help out with that
> package.  The issue here is when devs want to essentially block the
> work of others, even though the other dev is willing to do the work to
> ensure that quality is good for the end-users and accept any bugs that
> result.  That is essentially territorialism and it doesn't benefit
> Gentoo at all.

The maintainer is essentially free to do as he wishes with his package within
policy.
Last time a fork of an ebuild was announced was systemd, but the involved
developers (calchan and mgorny) could reconcile their differences in the end.
I think that is a good demonstration of the self-regulation of the developer
community, which doesn't need more rules here.


Best regards,
Chí-Thanh Christopher Nguyễn

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

[Chí-Thanh Christopher Nguyễn]

-----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.

>> 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.

>> 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?

I do things for them that I don't have to (like the occasional proxy commit
for ati-drivers). But when it comes to free/open source x11 packages I
indeed don't bother.

>> 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.

My argument that a "no mandatory caring about other users" policy does not
hinder the mission of Gentoo in any way. You said it increases hardness and
inconsistency. I said that this is not necessarily the case when there is
proper documentation, and besides not contrary to any goal stated in the
about or philosophy pages.

>>>> 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?

Because you too said something about minimum, I wanted to ensure that we
talk about the same minimum.

>> 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.

> 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.


Best regards,
Chí-Thanh Christopher Nguyễn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/

iEYEARECAAYFAlG/NjEACgkQ+gvH2voEPRBxfQCfVhxb89YrPyF82qj1i7JkV+J+
kO8An2iC1o1+EbxodPKQMDflwScq1scX
=/rNX
-----END PGP SIGNATURE-----

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@gentoo.org> 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@gentoo.org
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-----

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

[Chí-Thanh Christopher Nguyễn]

-----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?

After I apply your sed commands the sentence will read:
"And if any other developer doesn't care about our users, he is welcome to
make his yet another xorg-server package that introduces an additional step
this patch."
Please forgive me if I had trouble parsing this immediately.

The point is that x11 team has a long standing policy against
non-upstreamed patches. Even stronger for patches that upstream explicitly
rejected. I do think that qualifies as a good reason to reject patches like
the one from bug 462656.

Even so, if you can convince a team member that such a patch is still worth
maintaining then we may include it. But for patches that are only useful in
combination with proprietary drivers, the chances are slim.

>> 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.

No, this just causes the flag to be disabled on upgrade, which makes the
driver package fall out of xorg-drivers dependencies and removed by next
- --depclean run. Unless I misunderstand you again, but xorg-drivers is the
only relevant package that has USE_EXPAND flags related to the proprietary
drivers.

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

Saying that anybody here "hates" unit files would be a strawman argument.
There are users who don't want them on their system, and they said so on
this mailing list.

>>> 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.

The reason *why* the aforementioned users don't want the systemd unit files
is mostly irrelevant. They don't want unit files and could not be convinced
otherwise. So if you care about them you help making it easy to achieve
what they want. Or even the default.

- From the philosophy page: "the tool is designed to reflect and transmit the
will of the user" so no restriction to a well-reasoned will.


Best regards,
Chí-Thanh Christopher Nguyễn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/

iEYEARECAAYFAlG/UtoACgkQ+gvH2voEPRAsCQCfeMvFDgXCOxvinBjlMUcYJDjU
WMAAnilk5vrwlyc+0aNSE8lW4nTTtsTN
=gwtG
-----END PGP SIGNATURE-----

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

[Dale]

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

Chí-Thanh Christopher Nguyễn wrote:
>
> Saying that anybody here "hates" unit files would be a strawman argument.
> There are users who don't want them on their system, and they said so on
> this mailing list.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn

+1

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 800 bytes --]

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

[Tom Wijsman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

> 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.  

On Mon, 17 Jun 2013 20:18:02 +0200
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Saying that anybody here "hates" unit files would be a strawman
> argument. There are users who don't want them on their system, and
> they said so on this mailing list.

It is not, the decision for something to be "unwelcome" (your word)
comes from the "hate" emotion; it is a valid argument, and I am yet to
see a group of users stand behind this in a way that they feel
present things to deal with them (eg. INSTALL_MASK) are insufficient.

As in an useful documented case, not a reference to ~2 users; because
those references lead us nowhere, and if there were much more users
in that thread you refer to it would have a result in their favor.

There is a difference between a minor tantrum and a popular revolt.

- -- 
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQEcBAEBAgAGBQJRwGkLAAoJEJWyH81tNOV94ycH/RlDPfIf0HmQ66I1EGxyZ6Hd
tVQfE0UEPNzz0ApoYrO9q/6I5HdzeaKily88D20FkSYXVu+TB7Bhi1DjMWTJUWzW
CCbbcaGGmxA9O/ruD6z1rTB+itiZD4seGiBqMgbJu2P9jcP9FwWMEhEIqHsXoanS
bMiZwmEZsdcghy5HWz/27t+3ORTQ5Ouq7mTUA2gSAdKd1h7DlZMHVR1nP784IiIn
nWbC0crDQgnQNM/ZlviGypcn1no557XrzkT73IpvmFzprDJeeGtmBOglJz3PGyRE
/Nir7UKrqmBNcKbtZgYG/ST3iElKcLkMsXh8Eqa8GJ1ITz5+TtAooAd4PDZsTak=
=5iwM
-----END PGP SIGNATURE-----

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

[Rich Freeman]

On Fri, Jun 14, 2013 at 4:29 PM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> This is something I fundamentally do not agree with. Gentoo is not a
> team that works together. There is no set direction (or "stream").
> 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.

Of course Gentoo is a team that works together.  Sure, we tend to be
informal, and we allow a decent amount of independence.  However, if
we didn't coordinate our work we wouldn't be a distro - we'd just be
another github (one that can't figure out how to run git).

If you want a place to store your packages where nobody else can touch
them and where users can navigate and pick the version of each package
that they like the most, just start an overlay.  They behave EXACTLY
as you describe.

Gentoo isn't just a random collection of ebuilds - it is a coordinated
whole.  Nobody is advocating that developers should be micromanaged.
However, they can't have the absolute final say over anything that
happens to ebuilds they maintain otherwise any semblance of unity goes
out the window, along with the user experience.

The fact is that this is how we've been operating all along.  For the
most part developers even get along while they're doing it.  However,
there seem to be a few individuals who dig their feet in and insist on
others not helping to maintain "their" packages, and holy wars over
particular topics.  My personal feeling is that anybody is expendable.
 If you accept ANY kind of behavior from anybody it just results in a
small clique that nobody wants to join.

Rich

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

[Ben de Groot]

On 15 June 2013 00:51, Rich Freeman <rich@thefreemanclan.net> wrote:
>
> When it is obvious that you're swimming against the
> stream you need to change direction.

Indeed. I find myself again and again in this position lately. Less
and less people in Gentoo seem to share my views (or they simply don't
speak up). It hasn't been fun anymore for the last 6 months or so. So
I will change direction: I'm getting out of the stream that is being
channeled into directions I don't wish to go.

Goodbye, and thanks for all the fish!

--
Cheers,

Ben | yngwin
ex Gentoo developer

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

[Tom Wijsman]

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

On Fri, 14 Jun 2013 21:09:08 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> > What part of this is bullying?
> 
> The part where someone takes over the package and forces a change that
> is objected to by the current maintainer, and you expect him to just
> let this happen.

And why exactly is this bullying?

s/objected to by the current maintainer/usable by a share of our users/
 
> > Adding a unit file isn't going to cause you harm,
> 
> In my opinion such a feature request should be sent upstream. It's not
> like systemd is obscure.

You don't really point out why it is going to cause you harm; your
opinion actually sounds like doing the opposite to you, for what good?

In your case it was sent upstream, this is irrelevant; there's nothing
that keeps us from applying it directly instead of waiting for upstream.

I don't see how endless waiting on upstream makes anybody happy but you.

> > and if
> > you feel otherwise you can always ask the Council for a ruling.
> 
> I'm pretty sure they will vote in favour of those who seem to have the
> strongest voice.

You can't really tell if you don't ask it.

I hope they vote with users in mind, this strongest voice game is silly.

> > Maintainers MAINTAIN packages, they don't own them.  They're
> > expected to cooperate with other projects, and if they're going to
> > point at the rules to justify blocking work others are doing they
> > shouldn't be surprised if others find rules to point at as well.
> 
> Cooperation doesn't include hostile take-over.

But it does include cooperation with other projects; but not only them,
our users as well. If not, whom else would you be maintaining for?

Your case wasn't exactly hostile; on the other hand, denying units
that benefit a share of our users can also be seen as hostile.

Granted, in theory we could stuff a lot more packages into the tree
because some maintainers don't want to help out our users; though it is
an intermediate resolution, it is in the end not going to help anybody
but making the tree more confusing and inconsistent. That's not good.

> And as I said, in my opinion feature requests belong upstream.

Making a package work for a share of users isn't a feature request.

> If what you're proposing is going to be standard practice in Gentoo,
> then I will be looking for a friendlier environment to spend my time
> on.

Sometimes there has to be a hurricane in a glass of water to make
Gentoo more friendly towards our users. A statement like you just gave
exactly shows your objection to being friendly towards our users;
because really, what exactly are you pursuing by rejecting such files?

-- 
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 --]

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

[Michał Górny]

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

Dnia 2013-06-14, o godz. 21:09:08
Ben de Groot <yngwin@gentoo.org> napisał(a):

> On 13 June 2013 11:12, Rich Freeman <rich0@gentoo.org> wrote:
> > Maintainers MAINTAIN packages, they don't own them.  They're expected
> > to cooperate with other projects, and if they're going to point at the
> > rules to justify blocking work others are doing they shouldn't be
> > surprised if others find rules to point at as well.
> 
> Cooperation doesn't include hostile take-over.

Hostile take-over? This is really getting *ridiculous*.

Gentoo is team of people who work *together* to bring our users
the best experience they could get. This is not some kind of corporate
space where developers fight over ownership of packages and use them to
satisfy their personal businesses.

-- 
Best regards,
Michał Górny

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

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

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/14/2013 05:34 PM, Michał Górny wrote:
> Dnia 2013-06-14, o godz. 21:09:08 Ben de Groot <yngwin@gentoo.org>
> napisał(a):
> 
>> On 13 June 2013 11:12, Rich Freeman <rich0@gentoo.org> wrote:
>>> Maintainers MAINTAIN packages, they don't own them.  They're
>>> expected to cooperate with other projects, and if they're going
>>> to point at the rules to justify blocking work others are doing
>>> they shouldn't be surprised if others find rules to point at as
>>> well.
>> 
>> Cooperation doesn't include hostile take-over.
> 
> Hostile take-over? This is really getting *ridiculous*.
> 

I perceive this as trolling.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRu4JdAAoJEFpvPKfnPDWzREsH/0g3A7JVh1drPIVQt0JiZClN
uXS59LiZa29Nd6ouwzV2VmmUFKh46iU6MA2uDv0NTDRK4GPEdnbcT0PoVEH6wlyZ
nYNE18xHsllduWR94veTOLKZiHds8R2iMhc1Mx2VcGUPPz3xWvDYtMv+07L7+ad0
aHKEB4eR6ag5L7OeLed7A18w3oQ5p0KASowGm3fhFB4e9whQQmnrxsT5J3Txq2KQ
eW7L4lTKVK7Z1VbZnxWUSupNDuWow4a6TEteNBph0UUOYC/NHzak90NFLi4i2Htb
b9+0x7SsuWgYOIpjRwv9JqQ+9opVIbvEuresAvA4DVtx0gbTkL6HfvhemWCj6Ec=
=M2Pu
-----END PGP SIGNATURE-----

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

[vivo75]

On 06/14/13 22:51, hasufell wrote:
> On 06/14/2013 05:34 PM, Michał Górny wrote:
> > Dnia 2013-06-14, o godz. 21:09:08 Ben de Groot <yngwin@gentoo.org>
> > napisał(a):
>
> >> On 13 June 2013 11:12, Rich Freeman <rich0@gentoo.org> wrote:
> >>> Maintainers MAINTAIN packages, they don't own them.  They're
> >>> expected to cooperate with other projects, and if they're going
> >>> to point at the rules to justify blocking work others are doing
> >>> they shouldn't be surprised if others find rules to point at as
> >>> well.
> >>
> >> Cooperation doesn't include hostile take-over.
>
> > Hostile take-over? This is really getting *ridiculous*.
>
>
> I perceive this as trolling.
>
ridiculous, no really, that's even too few

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

[hasufell]

On 06/14/2013 03:09 PM, Ben de Groot wrote:
> 
> And as I said, in my opinion feature requests belong upstream.
> 

It's not a feature request. It is supporting an init system that has
been added to gentoo.

It is following gentoo _philosophy_ [1].

There is nothing to decide on by the council. There was no rule broken.
We support systemd as a tool, because the user wants it. At the same
time we will provide full support for this tool as per our philosophy.


--
[1] http://www.gentoo.org/main/en/philosophy.xml

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

[Steven J. Long]

Rich Freeman wrote:
> Honestly, if the Council just said "we don't want to make this a
> policy, but if systemd maintainers are willing to handle the bugs
> package maintainers should let them add units because that is the
> spirit of the existing policy" I'd be a lot happier.

So would I, so we can forget about this topic once and for all, and
get on with our lives..

Any chance of asking the Council to vote on the above as a clarification of
prior statements?

As I don't see any other reasonable method to fulfil that existing policy.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

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

[Tom Wijsman]

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

On Wed, 12 Jun 2013 16:25:35 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> If package fails due to bug in another package, sometimes even bug
> wranglers CC relevant people to help maintainer settling on where the
> problem lies.

Affirmative, I've done this a few times; saw others do this too.

> I don't think it's usually hard to see that a particular bug report is
> relevant to systemd and reassign/CC. Even bug wranglers can CC systemd
> if anything related to systemd is involved.

As I process _all_ bug wrangling mail, including the actions applied by
other wranglers; consider that this will happen from now on.

-- 
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 --]

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

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1664 bytes --]

Am Mittwoch, 12. Juni 2013, 16:25:35 schrieb Michał Górny:
> Dnia 2013-06-12, o godz. 18:16:10
> 
> Alexander V Vershilov <qnikst@gentoo.org> napisał(a):
> > On 12 June 2013 17:59, Rich Freeman <rich@thefreemanclan.net> wrote:
> > > Honestly, right now what I'd advocate for systemd unit maintainers is
> > > to: 1.  File a bug with the maintainer with a patch asking for the
> > > unit to be added, and indicating that if there is no response in 7
> > > days it will be commited.
> > > 2.  If the maintainer doesn't commit it themselves, then commit it for
> > > them in 7 days.
> > 
> > It will be good if commiter will add himself/or systemd team to metadata
> > with description that unit bugs will be should be assigned to him. As it
> > will add a level of responsibility for commiter, as he should realize
> > that if current maintainer is
> > unable or unwilling to test this part of functionality.
> 
> I don't understand why do we need to treat systemd special here.

And that is basically the whole important point. 
* There is no need to treat systemd specially.
* There is however a distinct need to work together. 

If you are listed as the sole maintainer of your package, that still does not 
mean you can do about every possible thing with it. You should still be 
required to cooperate with others in the interest of Gentoo as a whole. 

We all know the slogan "Gentoo is about choice". 

So, please, make that choice possible. Cooperate with others. Help enhance the 
available choices of Gentoo software.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Jeroen Roovers]

On Wed, 12 Jun 2013 16:25:35 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Now, why does every package supposedly need systemd@ as co-maintainer?
> I don't think it's usually hard to see that a particular bug report is
> relevant to systemd and reassign/CC. Even bug wranglers can CC systemd
> if anything related to systemd is involved.

Wait. Stop. Part of the point of the bug-wranglers project was to have
more people participate. One way of making that possible was to do away
with all the petty special cases. Bugs are assigned/CC'd according to
metadata.xml / repositories.xml / herds.xml (and anyone else added is
up to the bug-wrangler's disgression) so please do not count on this.

If you want to ensure systemd@ is CC'd, then add it to metadata.xml, or
try to create an environment where everybody is plain happy about
CC'ing systemd@ themselves (or anyone else they think might help
resolve a bug).


Regards,
     jer

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

[hasufell]

I am sorry, but I don't even understand what a co-maintainer is.

In my understanding there are only package maintainers. Everyone listed
in metadata.xml is a maintainer and has the competence to do any kind of
changes.

If one of the other maintainers disagree, then it's not a question of
who is the master-maintainer and who is the co-maintainer.

That's an internal problem of those people and they should deal with it.
If they are unable to do that, then they can contact devrel. Period.

If a developer refuses to add enhancements to an ebuild without giving
technical reasons, then it's a matter for devrel as well.

Honestly... In case of systemd I'd just open a bug, attach the fixes and
wait for some time. In case of no response I'd just apply it. If the dev
reverts it without giving a reason, I will contact him and if necessary
devrel.

I don't see a reason to introduce a special policy for this. We could go
on about such things all day, because there are and will be more.

And I am not really sorry about devs dropping maintainership because of
such silly issues. If they can't work out something like that, then it's
better that way.


reasoning > authority

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

[Sergey Popov]

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

12.06.2013 15:43, hasufell пишет:
> I am sorry, but I don't even understand what a co-maintainer is.
> 
> In my understanding there are only package maintainers. Everyone listed
> in metadata.xml is a maintainer and has the competence to do any kind of
> changes.
> 
> If one of the other maintainers disagree, then it's not a question of
> who is the master-maintainer and who is the co-maintainer.
> 
> That's an internal problem of those people and they should deal with it.
> If they are unable to do that, then they can contact devrel. Period.
> 
> If a developer refuses to add enhancements to an ebuild without giving
> technical reasons, then it's a matter for devrel as well.
> 
> Honestly... In case of systemd I'd just open a bug, attach the fixes and
> wait for some time. In case of no response I'd just apply it. If the dev
> reverts it without giving a reason, I will contact him and if necessary
> devrel.
> 
> I don't see a reason to introduce a special policy for this. We could go
> on about such things all day, because there are and will be more.
> 
> And I am not really sorry about devs dropping maintainership because of
> such silly issues. If they can't work out something like that, then it's
> better that way.
> 
> 
> reasoning > authority
> 

But you know about "Assignee" field in bugzilla, do not you? Maintainer
in this terms is "Assignee", co-maintainer(s) goes in CC field.

Sometimes co-maintainer and maintainers have different levels of
authority on specific packages(for example proxy maintainers). But
usually if we are talking about two Gentoo developers who maintain
package and have NO additional info in metadata's desciption(descibing
their right, for example 'only issues about foo feature', see
net-misc/openssh metadata) fields than they are equal in their rights on
the package.

P.S. All above is my personal point of view, based on policy, common
sense, etc.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Qt project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/12/2013 01:54 PM, Sergey Popov wrote:
> 
> But you know about "Assignee" field in bugzilla, do not you?
> Maintainer in this terms is "Assignee", co-maintainer(s) goes in CC
> field.
> 
> Sometimes co-maintainer and maintainers have different levels of 
> authority

No, they don't. There might be a different level of knowledge about a
package and that is exactly the criteria I follow when choosing
assignee/CC, sometimes just by judging the ChangeLog.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRuGIRAAoJEFpvPKfnPDWzgp8IAIxfO3DBkZMAY5VKCuuSRrFN
sWnSoVk0IW8vR71wUGNUpEnv58dgkxyYeKFbyFVMCCPY0PzeUz6m4v9zGUH9ubuT
pPBI4TAR621j++oaYmxBKvakP1UIIGG4HRpglwFaNtXtRNVdcO9gm2HtR/WnHfL5
0FmSpw0DD26KdpUEjoCZh8nTtSKIGzbPPTKTnjpF5iGePzR/FENqGXLy3FkcdyLE
J0hJzTTR51ba7kxgLQbt99i8nI8rtYCfLsKsXmqeZym1nUq5a1ng8wxMRsTfqxGl
wO0mbawgMXchnOTEMY+/n+OF2Mk3E0a2iVCr4LLxpiVHQnM6gB7yT8KqSyxk3i8=
=LQdP
-----END PGP SIGNATURE-----

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

[Sergey Popov]

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

12.06.2013 15:57, hasufell пишет:
> On 06/12/2013 01:54 PM, Sergey Popov wrote:
> 
>> But you know about "Assignee" field in bugzilla, do not you?
>> Maintainer in this terms is "Assignee", co-maintainer(s) goes in CC
>> field.
> 
>> Sometimes co-maintainer and maintainers have different levels of 
>> authority
> 
> No, they don't. There might be a different level of knowledge about a
> package and that is exactly the criteria I follow when choosing
> assignee/CC, sometimes just by judging the ChangeLog.
> 

As i said earlier, it is my personal opinion - i see things in that way.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Qt project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Michał Górny]

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

Dnia 2013-06-12, o godz. 15:54:29
Sergey Popov <pinkbyte@gentoo.org> napisał(a):

> But you know about "Assignee" field in bugzilla, do not you? Maintainer
> in this terms is "Assignee", co-maintainer(s) goes in CC field.

I'd rather call that a technical limitation of Bugzilla rather than
anything specific.

Of course, there are cases when there's an agreement that there's main
maintainer and co-maintainers, main maintainer and specific area
maintainers and so on. But it's a result of people's decisions
and agreements, and not of Bugzilla being limited.

-- 
Best regards,
Michał Górny

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

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

[Sergey Popov]

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

12.06.2013 16:05, Michał Górny пишет:
> Dnia 2013-06-12, o godz. 15:54:29
> Sergey Popov <pinkbyte@gentoo.org> napisał(a):
> 
>> But you know about "Assignee" field in bugzilla, do not you? Maintainer
>> in this terms is "Assignee", co-maintainer(s) goes in CC field.
> 
> I'd rather call that a technical limitation of Bugzilla rather than
> anything specific.
> 
> Of course, there are cases when there's an agreement that there's main
> maintainer and co-maintainers, main maintainer and specific area
> maintainers and so on. But it's a result of people's decisions
> and agreements, and not of Bugzilla being limited.
> 

I did not mean, that there is no chance for two Gentoo developers to
maintain one package in equal manner. Bugzilla is just an example, i
understand that only one "Assignee" field is just technical limitaion.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Qt project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

[gentoo-project] Proposal for add-on file utility (run after emerge update)

[Walter Dnes]

On Wed, Jun 12, 2013 at 07:05:55AM -0400, Rich Freeman wrote
> Alas, I couldn't attend the council meeting in-person, but it seems
> like council missed the point of my request RE commits against
> maintainer wishes (or maybe not - if so I'll happily shut up as far as
> persuading the council goes).  That said, I expressed it as a general
> request in the hope to not have something systemd-specific, and it
> sounds like that is not desired.

  I think the best way to avoid maintainer conflicts is to take this out
of the hands of maintainers, and put it in the hands of users.  At one
time there was a package of all possible systemd units that could be
installed as one ebuild.  Apparently, some "inode fundamentalists"
objected to having a bunch of unnecessary files dumped on their hard
drives (imagine that), so that package was removed.  I suggest a more
targetted approach...
* a script (or compiled program)
* that reads the output of "eix-installed -a"
* compares against a config file in /etc
* adds or deletes files based on the contents of the config file

  I was originally thinking of systemd units, but this could be applied
to initscripts or man files or info files or html docs or whatever.  In
addition to pulling in standard stuff, it could pull in custom units or
docs from "personal overlay" sources.  It would usually be run once,
right after an update.

  IANACP (I Am Not A C Programmer), so I would probably do this in bash
if I did it strictly for personal use.  But I'm beginning to wonder if
it might be a useful approach resolve some conflicts between various
groups of users/developers.  I.e. end-users could easily customize their
systems' *REGARDLESS OF HOW DEVELOPERS SET UP EBUILDS*.  This might
require a "systemd units herd" to supply a tarball with systemd units
that would be selectively installed.  And possibly a "documentation
herd", etc.

-- 
Walter Dnes <waltdnes@waltdnes.org>

[gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Tom Wijsman]

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

On Sun, 16 Jun 2013 05:33:22 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

> I think the best way to avoid maintainer conflicts is to take this
> out of the hands of maintainers, 

+1 I was planning to write a GLEP for a concept where optional files
would be maintained separately from packages, this could then be
covered in later revisions of the PMS so that in a reasonable time from
now we can properly support this and end to the rage and rage quits.

But you were before me, so I might as well elaborate with thoughts so
we can all end up improving the idea about how this ends up being.

Basically, what I have in mind is something along the lines of:

    Package directories get an additional directory, let's call it
    "optional", where you can put optional files in to be installed.

    eg. ${PORTDIR}/sys-apps/dbus/files/optional/
    or  ${PORTDIR}/sys-apps/dbus/optional/

    Files in this directory have a special header, it should contain a
    condition based on which to install (eg. package to be present) and
    optionally a parsable list of maintainers maintaining the package.

    (The word "file" below refers to files in the above directory,
    unless noted otherwise; just saying to avoid confusion)

    Since there is a condition based on which these files are to be
    installed, there is no need to specify such thing in the ebuild;
    this effectively separates the maintenance from the pkg maintainer.

    Since the files have their individual maintainers, different
    maintainers can maintain the file without having to maintain the
    pkg itself in question; effectively allowing you to have a
    maintainer than does _not_ want to maintain systemd whatsoever work
    on his ebuild without ever seeing systemd, whereas the developer
    that wants to contribute an optional systemd file can without a
    problem introduce it without bothering the maintainer.

    If a file does not contain a list of maintainers, it inherits the
    list of maintainers from the package; this allows the package
    maintainer itself to easily create a file without having to
    duplicate his own metadata all over the place.

    A file not containing a maintainer isn't a leeway for others to add
    themselves, files that are unmaintained should have
    maintainer-needed@g.o to prevent us from hurting the users, if bugs
    reveal a file is broken beyond repair it should be removed.

    So, there's one thing left; what about bugs filed?

    Easy, it could be made more clear in the build log which optional
    files were installed as well as list the list of maintainers for
    each optional file; that way, if the maintainers have the least
    thought that it is a problem caused by an optional file, they can
    easily assign it to those individuals maintaining that file.

    As a side benefit, optional files are separated from patches.

    What does everyone think about such approach?

> and put it in the hands of users.

-1 Not because I don't want users to be able to do this, but more
because I can't see a reasonable way for them to do this; for something
as widespread as this, there should at least be supervision. We can't
have a random user commit a random service unit for security reasons;
there has to be some kind of review, I don't see how though.

Based on that, I think the best place is the Portage tree; these files
are as small as patches, so infra and the community as a whole doesn't
really see a problem in placing it there.

> At one time there was a package of all possible systemd units that
> could be installed as one ebuild. [...SNIP...] I suggest a more
> targetted approach...

Agreed, if you don't tie them with packages, you get nasty clumps.

> * a script (or compiled program)

We can have the package managers do this instead, I think there is no
need for yet another separate script / utility to be ran; the logic
behind installing optional files that I have in mind doesn't introduce
too much complexity as far as I know.

> * that reads the output of "eix-installed -a"

We can't force such dependency; even better, we don't need such
dependency since the package manager is able to do this.

> * compares against a config file in /etc

Maybe, maybe not; I wonder if it is sufficient to just check if the
package in question is installed. Others could use INSTALL_MASK.

I mean, the percentage of people wanting to run an init script but not
its init scripts / unit files is extremely low I think; if anyone
knows of valid cases, feel free to elaborate upon them.

> * adds or deletes files based on the contents of the config file

I don't think deleting files is acceptable towards the maintainer; I
don't really see a need for this either, does anyone have an example?

>   I was originally thinking of systemd units, but this could be
> applied to initscripts or man files or info files or html docs or
> whatever.

Indeed, we should cover all optional files:

- OpenRC conf.d configuration files and init.d init scripts
- systemd service unit files, targets and similar files
- PAM files, desktop files, logrotate files, cron files, bash completion
- ...

> In addition to pulling in standard stuff, it could pull in
> custom units or docs from "personal overlay" sources.  It would
> usually be run once, right after an update.

When you let the PM do this, this is almost automatically covered.

>   IANACP (I Am Not A C Programmer), so I would probably do this in
> bash if I did it strictly for personal use.

I think I've repeated it enough above, this is more trivial in the PM.

> But I'm beginning to wonder if it might be a useful approach resolve
> some conflicts between various groups of users/developers.

Definitely, by designing an approach that uses a separate directory in a
package, you assign maintainers to individual files like eclasses do.

> end-users could easily customize their systems' *REGARDLESS OF HOW
> DEVELOPERS SET UP EBUILDS*.

Indeed, given the defined structure, users can hack things together.

> This might require a "systemd units herd" to supply a tarball with
> systemd units that would be selectively installed.  And possibly a
> "documentation herd", etc.

Without going to a specific example, some existing herds cover this.

-- 
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 --]

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Rich Freeman]

On Sun, Jun 16, 2013 at 6:21 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Sun, 16 Jun 2013 05:33:22 -0400
> "Walter Dnes" <waltdnes@waltdnes.org> wrote:
>
>> I think the best way to avoid maintainer conflicts is to take this
>> out of the hands of maintainers,
>
> +1 I was planning to write a GLEP for a concept where optional files
> would be maintained separately from packages, this could then be
> covered in later revisions of the PMS so that in a reasonable time from
> now we can properly support this and end to the rage and rage quits.

I have mixed feelings.  While on one hand it might be cleaner to be
able to separate upstream files from gentoo files (openrc scripts,
tmpreaper, logrotate, etc), the fact is that these options files do
introduce functional changes of some kind.  An optional file that 99%
of users get installed by default that is a cron script could have a
big impact on users of a package.  Do we really want stuff like that
happening with no maintainer involvement at all?

I think cooperation makes more sense than having people work around
each other deliberately ignoring things they don't like.

The logic around installing these files could get convoluted as well.
What if a line in the file has to be set dynamically based on
something detected at time of installation?  What if the file varies
by package version?  With an ebuild such things are straightforward -
do we need essentially a second src_install just to work around the
fact that somebody doesn't want us touching the main one?

If this were about cleaner separation/maintenance of upstream vs
gentoo stuff I could see the benefit (though it needs refinement).
However, this really seems like a technical workaround for a people
problem.

Also, I think that Douglas is right about something - this really
isn't THAT big of a problem.  It really only involves a few people and
a single issue.  I think the bigger barrier to getting systemd units
(or whatever) into the tree is people willing to do the work.  I
should have committed a systemd unit for mythtv ages ago, and I'm just
too lazy to get it done...  :)

Rich

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Tom Wijsman]

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

On Sun, 16 Jun 2013 06:53:07 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> I have mixed feelings.  While on one hand it might be cleaner to be
> able to separate upstream files from gentoo files (openrc scripts,
> tmpreaper, logrotate, etc), the fact is that these options files do
> introduce functional changes of some kind.  An optional file that 99%
> of users get installed by default that is a cron script could have a
> big impact on users of a package.  Do we really want stuff like that
> happening with no maintainer involvement at all?

Remember that those optional files are used to make the package work
for the user where it would otherwise not work. No maintainer
involvement for those is fine; since the optional files bring the
package from a not working state to a working state for the user.

We could make cron files an exception to this approach as they
introduce more behavior than just making the service work in general.

In most occasions I think optional files don't require the package
maintainer to do anything to the package itself, if however the package
itself doesn't support the optional file (eg. no means to start it as a
daemon) it is up to the package maintainer to decide whether or not to
patch that; note that this paragraph is different from the maintainer
involvement you had in mind, but I'm mentioned because it came to mind.

> I think cooperation makes more sense than having people work around
> each other deliberately ignoring things they don't like.

Cooperation that has lead to ~4 developers rage quitting, who's next?

What if all the threads we saw are a consequence of a bad pkg structure?

I think we should be able to implementing different not conflicting
choices instead of forcing the package maintainer to do something, the
current package structure doesn't really fit well for that as we saw;
people can't always happily cooperate on everything, that's by design...

> The logic around installing these files could get convoluted as well.

Maybe, maybe not; that's what we need to inspect over the days to come.

> What if a line in the file has to be set dynamically based on
> something detected at time of installation?

Is there an example of this?

Assuming there is a need for this, we could allow bash files to do
these kind of things, see it as some kind of mini ebuilds in the
optional directory; it's kind of like the idea of creating separate
X-SomeInitSystem packages, but then without cluttering the output of
search utilities (eg. emerge --search, eix) and the need to fork the
actual package logic itself, but rather just implement the diference. ;)

> What if the file varies by package version?

This could be covered using the installation conditionals.

> With an ebuild such things are straightforward - do we need
> essentially a second src_install just to work around the fact that
> somebody doesn't want us touching the main one?

Either you go for one end (above suggested approach), the other end (no
ownership of an ebuild) or in between (discussion, rage and quits).

I think it is now the right moment in time to decide whether we want to
go for a specific end or just rather stay where we are. I just hope to
not see all three approaches to be discussed to death in the future.

Neither do I want to see DevRel / CoC / Council kick people out of the
project that apart from the matter contribute just fine; however, I do
think they should deal with abusive / ignorant / ... behavior where
the necessary explanation behind silence or bold statements are missing.

> If this were about cleaner separation/maintenance of upstream vs
> gentoo stuff I could see the benefit (though it needs refinement).

Definitely needs refinement, I originally planned to carefully type
this out as a GLEP proposal; but given someone else mentioned it, I
decided to throw the reasoning in here to help the discussion that
might be about to start here and to see some useful feedback.

> However, this really seems like a technical workaround for a people
> problem.

Maybe, maybe not; I'm just bringing it to light to get people thinking
about the ideas behind this, maybe someone comes up with alternatives.

> Also, I think that Douglas is right about something - this really
> isn't THAT big of a problem. 

It definitely isn't, but if developers quit; it does bother them.

> It really only involves a few people and a single issue.

I'm not so sure about that; there will certainly me more issues in the
future, and there might be some people that haven't complained yet.

People not following the ML, people not reading systemd threads, ...

> I think the bigger barrier to getting systemd units (or whatever)
> into the tree is people willing to do the work. I should have
> committed a systemd unit for mythtv ages ago, and I'm just too lazy
> to get it done...  :)

If I learn how to write optional files properly; I would like to be able
to use that knowledge for more than the low amount of daemon packages I
maintain, but rather contribute to a larger share of packages.

If I can't go contribute to more packages, what would I learn it for?

I would only be lazy if I couldn't put my knowledge to better use.

Furthermore, I think endless discussions, rage and quits shouldn't be
part of the progress to sanely add optional files to the Portage tree.

-- 
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 --]

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/16/2013 01:51 PM, Tom Wijsman wrote:
> On Sun, 16 Jun 2013 06:53:07 -0400 Rich Freeman <rich0@gentoo.org>
> wrote:
> 
>> I have mixed feelings.  While on one hand it might be cleaner to
>> be able to separate upstream files from gentoo files (openrc
>> scripts, tmpreaper, logrotate, etc), the fact is that these
>> options files do introduce functional changes of some kind.  An
>> optional file that 99% of users get installed by default that is
>> a cron script could have a big impact on users of a package.  Do
>> we really want stuff like that happening with no maintainer
>> involvement at all?
> 
> Remember that those optional files are used to make the package
> work for the user where it would otherwise not work. No maintainer 
> involvement for those is fine; since the optional files bring the 
> package from a not working state to a working state for the user.
> 
> We could make cron files an exception to this approach as they 
> introduce more behavior than just making the service work in
> general.
> 
> In most occasions I think optional files don't require the package 
> maintainer to do anything to the package itself, if however the
> package itself doesn't support the optional file (eg. no means to
> start it as a daemon) it is up to the package maintainer to decide
> whether or not to patch that; note that this paragraph is different
> from the maintainer involvement you had in mind, but I'm mentioned
> because it came to mind.

All packages I maintain that either install openrc, systemd, logrotate
or cron script... work without ANY of them. Even ZFS does.

> 
>> I think cooperation makes more sense than having people work
>> around each other deliberately ignoring things they don't like.
> 
> Cooperation that has lead to ~4 developers rage quitting, who's
> next?
> 
> What if all the threads we saw are a consequence of a bad pkg
> structure?
> 
> I think we should be able to implementing different not
> conflicting choices instead of forcing the package maintainer to do
> something, the current package structure doesn't really fit well
> for that as we saw; people can't always happily cooperate on
> everything, that's by design...

That is vague.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRvavcAAoJEFpvPKfnPDWznGAH/jSwb61gLR84gLBGzAuXiPWq
FrPVPNS10qpskeviuGMzdVdK62IvmRRsFBCC93KWn0R4PzVG7U92foEvJv9Qt2ow
zA0xj8XZ8wFXtaJEuPqZNBiM3Ol/z6bPtf9bB5O4z+sKWzwN9Cs6c+qeCMe+KtqV
J2ewRTV6q/IsG56nmdCZK+HRstYPBO9XILtEWicqCDSQCK3QQqADp51wvtMqe+IU
4+2+EHl0SKPZm18q4+FeS2yOPv9afbKxDavTRGY6mWCN/FwEeTALs1r0GvpK6GY0
I+p7TQmhqSRd/YLm4LqYe4V2b3pAHWWj0WpAji3M/0WmhLejU85CQMa1DGYwhVY=
=sylV
-----END PGP SIGNATURE-----

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Tom Wijsman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 16 Jun 2013 14:13:16 +0200
hasufell <hasufell@gentoo.org> wrote:

> That is vague.

Clarifying below; if still vague, explain which parts are vague:

> > Cooperation that has lead to ~4 developers rage quitting, who's
> > next?

See the recent ML threads.

~ because it is not known if they quit, I won't mention names in public.

> > What if all the threads we saw are a consequence of a bad pkg
> > structure?

With a better structure, these threads wouldn't exist.

> > I think we should be able to implementing different not
> > conflicting choices instead of forcing the package maintainer to do
> > something, the current package structure doesn't really fit well
> > for that as we saw;

This is the idea of this sub thread put into different words.

> > people can't always happily cooperate on everything, that's by
> > design...

I think this part is clear; unless you think humans aren't designed to
pursue choices and be emotional, but that would be a whole new topic.

- -- 
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQEcBAEBAgAGBQJRvcbaAAoJEJWyH81tNOV9Y18IALF5LyYT3x5b0ZLNMmuU7Vsx
E2YG2wFXij+bj8zCYLp/E4JmjJqVmGGdpHNBmzffaUAP8uhg1kM74z6G4FDrh9WI
jLih1VwkvyZny7YfzJ+wvQeaIzMRM+9DGt1A9QZZvT8uNCioI09004FTiVPC45vd
CQel961k+2PVJezrQbUy3j0LGRRCKZe5a4vjAjWzEQm6ECBLIheG5UyA50982W59
XqIenBQtvmOp9lMR8wFR5/7PdnF+xUc4Hnolmg8ZQKfzm6UHDKX2Jv15bEXnJjYP
EBb0J8/n+u8Q2p66nLKUTk+wH/cXt/peB0prYYjgaSGgjALwP9keIKDFtSXN7ag=
=CuFS
-----END PGP SIGNATURE-----

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Tom Wijsman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 16 Jun 2013 14:13:16 +0200
hasufell <hasufell@gentoo.org> wrote:

> All packages I maintain that either install openrc, systemd, logrotate
> or cron script... work without ANY of them. Even ZFS does.

Depends on how you define "work"; the way you define it, it is like
saying you don't need these files at all and everyone should just hack
their own ways to automatically start the daemon or whatever.

I wouldn't call something working that isn't properly integrated; the
whole point of these optional files is to not come up with hacks,
otherwise we might as well remove all optional files out of the tree.

- -- 
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQEcBAEBAgAGBQJRvcg7AAoJEJWyH81tNOV95/gIALCm8o3RhNNHkob20eZ/s8GN
wMFqEWMHr31N951I1ha7ISisqjdEFeoKvbsQkHAxnDjk/Wz1XEZwPLYUmUbh6TNW
kpJMRTzNB9Ed8Nl5GIAtHGey7rX7oA6OlnD1rlg3Pjpd+YxdhPYXVmdkbUFus8my
m+Jl2x9YtkuEUQ6ZtfMJeWhUzrnxtzR0bRzqtX4ppVl2YlxGDbskHSuYu6/ORCqV
BSPaiJM5Amu3m5w/GVrBHA+zbGQ5Pv2MR8DKPqTKzTsVUQMc5RUsA0/mGuotw9vJ
csJ35P/ihBQ/issWAB7/2XBi90Y6pcT79wWetMvChs9O25R8el2PLPTCDh78qLc=
=hJis
-----END PGP SIGNATURE-----

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/16/2013 04:14 PM, Tom Wijsman wrote:
> On Sun, 16 Jun 2013 14:13:16 +0200 hasufell <hasufell@gentoo.org>
> wrote:
> 
>> All packages I maintain that either install openrc, systemd,
>> logrotate or cron script... work without ANY of them. Even ZFS
>> does.
> 
> Depends on how you define "work"; the way you define it, it is
> like saying you don't need these files at all and everyone should
> just hack their own ways to automatically start the daemon or
> whatever.
> 
> I wouldn't call something working that isn't properly integrated;
> the whole point of these optional files is to not come up with
> hacks, otherwise we might as well remove all optional files out of
> the tree.
> 
> 

I did not define "work".

But saying they don't work without those files is just not the case
most of the time. There is a fair number of packages where I don't use
any of those files or just a few of them.

Using INSTALL_MASK for all those occasions is a bit messy, because it
does not allow fine-graining configuration beforehand. It's rather
figuring out what you don't need after installation and then adding
INSTALL_MASK and removing the file manually.


Putting those files in seperate packages sucks even more and will lead
to frustrated devs and outdated files.

Doing it via regular useflags is just wrong.

Any other approach is too complex for my taste to be even considered
(like introducing a similar phase function like pkg_config()
controllable by useflags that don't trigger a rebuild?) and involves
PMS changes which is painful enough.

- From what you have described it is not clear to me at all how the user
will install the optional files.

I don't think it's worth much effort, but a solution would still be
nice. However, it's a ricer thing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRvdEEAAoJEFpvPKfnPDWzNZcIAJmMG5PYzZpG3Ofy6uyDUMgw
182Tb8MmOl+/gvWV51pKyrmmK9gMD0O5U9xd+QC+muUerIfeGAIGAJG78/P6At6F
7wLhKp9jU/4OvV0Ie+gOKem+t3x4NZ5KAeG+Em0PbG5FV1ch1J7lDPovc3kAI56P
oF7WTTXvkAcqlAtFscc/EAGKHitkUULNwStS/OAZb/2vMhRjJArpQ0U1l74DMdRy
XBGPl1tP3iUIZ/foOYergCyH3DZKD5ieDsP1X1qOsnmmat3fbIlBR4dQZWPXQAPr
NVRpK2iEcmP172hguKRFM2bh3cvFYU6hJ4Xzo9KDoyoJ1T0898xVD+p1pboLG5c=
=9Pnw
-----END PGP SIGNATURE-----

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Michał Górny]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Dnia 2013-06-16, o godz. 16:51:48
hasufell <hasufell@gentoo.org> napisał(a):

> Any other approach is too complex for my taste to be even considered
> (like introducing a similar phase function like pkg_config()
> controllable by useflags that don't trigger a rebuild?) and involves
> PMS changes which is painful enough.

And it won't work when files are installed/packaged upstream.

- -- 
Best regards,
Michał Górny
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQJ8BAEBCgBmBQJRvdKRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC
QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKwAQP/Rx15Eug+iZyqhFK44MEzLHk
mrWs1iSf2Jeba3CyrC/Im3O5q+GqBHjzL5NNo2pWRAi59iu4P0e9Re1yiZ1u1TxQ
UBO3gXBYn+OBb7ANfBa4AXN3C7ViG8yOlmQnAcRuolt6hP6zYyvBt/aFF5zVPOfb
FHruJ5n9V2ENCPd261/fl6ECXwJgez4LL66klHIiq4M0wY6G8kVAjs1wInRDtt3X
wNhs/z59DQqjuYmLpWLoA0h1w/o63bYdE5CRTCm3Gi2Wha+zTGIor41Rmm9ySuWK
jmHUlTRTtu6jD7/Vk9qbRfltuHzRdR6JMbUr/lDDdECMIwOpeOmL932HzptFkQ/O
Iw+W7mY2vozWVaiH/HUWztgq36J7L7d0rDtPuNbQJ0uwUbyi7W6EUT4iQA+ujT7Q
Ugnnj181C71Schg20McMbmR8Xp6R/4eHHZ5UfGTpYOgbolcn66OFsFoS2vty6mJY
sJdMhf2MDb7XrZp4nv8qwotS2ZgBAnxrqSxR0/q3ZCRzt6ciGo+Zr+qOPrLXm7Kl
uS11gHuh2VeGKU5xV/daKzhNq0JprFT96IzfZInHBwhl+i0ObCtl22odK5sgJ80I
VmDzaq/EWdqgOhT4oVZKRWjDMbIcBIPtFMNTfj8VulC8ZGeGOR6n8WDCHYcMdcxq
qnSlV8tgumtDEXEzYUHl
=N7q3
-----END PGP SIGNATURE-----

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Pandu Poluan]

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

On Jun 16, 2013 9:52 PM, "hasufell" <hasufell@gentoo.org> wrote:
>

--snip--

>
> Doing it via regular useflags is just wrong.
>

I'm sorry, but what's wrong with using USE flags?

I mean, some people have already been using USE="-*" because they don't
want portage to emerge something they don't want (of course, doing so ends
up in lots of teeth-gnashing, but that's beside the point).

I myself perused for whatever USE flags there is and manually disable
everything I don't want to get installed. Like, USE="-docs -examples"

So why not specify one or more additional USE flags which are by default
enabled, e.g., "openrc" and "systemd"; user not disabling them will get the
whole enchiladas. Yes, users disabling both of them (e.g., "-*") will end
up with a totally borked system, but that's the price one pays for
specifying "-*", and if a News item is pushed waay before we implement
these init-system-related flags, there should be much fewer caught
unaware...

Rgds,
--

[-- Attachment #2: Type: text/html, Size: 1309 bytes --]

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Canek Peláez Valdés]

On Sun, Jun 16, 2013 at 1:12 PM, Pandu Poluan <pandu@poluan.info> wrote:
>
> On Jun 16, 2013 9:52 PM, "hasufell" <hasufell@gentoo.org> wrote:
>>
>
> --snip--
>
>>
>> Doing it via regular useflags is just wrong.
>>
>
> I'm sorry, but what's wrong with using USE flags?

That you need to reemerge whole packages for tiny little files that
doesn't affect the programs at run time. At all.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[hasufell]

On 06/16/2013 08:12 PM, Pandu Poluan wrote:
> On Jun 16, 2013 9:52 PM, "hasufell" <hasufell@gentoo.org> wrote:
>>
> 
> --snip--
> 
>>
>> Doing it via regular useflags is just wrong.
>>
> 
> I'm sorry, but what's wrong with using USE flags?
> 

Use flags trigger rebuilds. Rebuild libreoffice for a doc useflag? Have fun.

If something changes the build procedure, then useflags are fine. But
they are often abused too.

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Tom Wijsman]

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

On Sun, 16 Jun 2013 20:20:53 +0200
hasufell <hasufell@gentoo.org> wrote:

> On 06/16/2013 08:12 PM, Pandu Poluan wrote:
> > On Jun 16, 2013 9:52 PM, "hasufell" <hasufell@gentoo.org> wrote:
> >>
> > 
> > --snip--
> > 
> >>
> >> Doing it via regular useflags is just wrong.
> >>
> > 
> > I'm sorry, but what's wrong with using USE flags?
> > 
> 
> Use flags trigger rebuilds. Rebuild libreoffice for a doc useflag?
> Have fun.

If you introduce a separate set of USE flags that only reinstall the
optional files and don't touch the rest, you don't have this problem.

-- 
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 --]

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Michał Górny]

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

Dnia 2013-06-16, o godz. 20:32:55
Tom Wijsman <TomWij@gentoo.org> napisał(a):

> On Sun, 16 Jun 2013 20:20:53 +0200
> hasufell <hasufell@gentoo.org> wrote:
> 
> > On 06/16/2013 08:12 PM, Pandu Poluan wrote:
> > > On Jun 16, 2013 9:52 PM, "hasufell" <hasufell@gentoo.org> wrote:
> > >>
> > > 
> > > --snip--
> > > 
> > >>
> > >> Doing it via regular useflags is just wrong.
> > >>
> > > 
> > > I'm sorry, but what's wrong with using USE flags?
> > > 
> > 
> > Use flags trigger rebuilds. Rebuild libreoffice for a doc useflag?
> > Have fun.
> 
> If you introduce a separate set of USE flags that only reinstall the
> optional files and don't touch the rest, you don't have this problem.

And how would you do that? Sounds like a heavy magic with a lot of
inconsistency and problems whenever things start to depend one
on another.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Tom Wijsman]

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

On Sun, 16 Jun 2013 20:41:05 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Dnia 2013-06-16, o godz. 20:32:55
> Tom Wijsman <TomWij@gentoo.org> napisał(a):
> 
> > On Sun, 16 Jun 2013 20:20:53 +0200
> > hasufell <hasufell@gentoo.org> wrote:
> > 
> > > Use flags trigger rebuilds. Rebuild libreoffice for a doc useflag?
> > > Have fun.
> > 
> > If you introduce a separate set of USE flags that only reinstall the
> > optional files and don't touch the rest, you don't have this
> > problem.
> 
> And how would you do that? Sounds like a heavy magic with a lot of
> inconsistency and problems whenever things start to depend one
> on another.

Either by denoting USE flags in USE as special _or_ introducing a
separate OUSE variable.

They don't have to be "openrc", "cron", "systemd" but could be like
"init-scripts", "cron-files", "systemd-units"; to not collide with any
existing USE flags, if any.

Do they start to depend on each other? Why?

-- 
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 --]

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Rich Freeman]

On Sun, Jun 16, 2013 at 3:22 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> Either by denoting USE flags in USE as special _or_ introducing a
> separate OUSE variable.
>
> They don't have to be "openrc", "cron", "systemd" but could be like
> "init-scripts", "cron-files", "systemd-units"; to not collide with any
> existing USE flags, if any.
>
> Do they start to depend on each other? Why?

Bottom line is that in order to accomplish any of this we need to
expand PMS to specify a syntax, implement this stuff in portage, and
then start modifying all our ebuilds so that heaven-forbid you don't
get an openrc script installed if you don't set USE=openrc.

I don't think any of this is worth it for a one block text file.

This is really one of those situations where any decision is better
than no decision.  The general consensus so far is that stuff like
this just gets installed and users/devs who don't like it can use
INSTALL_MASK.  I could care less whether we do it that way or via USE
flags, but it seems like we'll still be debating this when I retire.

If people are going to quit over this, then I suspect that we're just
going to have to deal with the inevitable - if 4 people are willing to
quit over the INSTALL_MASK approach then I'm sure as many will quit
over just about any approach...

Rich

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Tom Wijsman]

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

On Sun, 16 Jun 2013 15:31:10 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Sun, Jun 16, 2013 at 3:22 PM, Tom Wijsman <TomWij@gentoo.org>
> wrote:
> > Either by denoting USE flags in USE as special _or_ introducing a
> > separate OUSE variable.
> >
> > They don't have to be "openrc", "cron", "systemd" but could be like
> > "init-scripts", "cron-files", "systemd-units"; to not collide with
> > any existing USE flags, if any.
> >
> > Do they start to depend on each other? Why?
> 
> Bottom line is that in order to accomplish any of this we need to
> expand PMS to specify a syntax, implement this stuff in portage, and
> then start modifying all our ebuilds so that heaven-forbid you don't
> get an openrc script installed if you don't set USE=openrc.
> 
> I don't think any of this is worth it for a one block text file.

Agreed, I no longer stand behind my idea as originally proposed
since the efforts are much bigger than the need and the need is likely
to decay anyway; but was just enumerating an idea that applies as much
to an INSTALL_MASK approach [mgorny's version] as it did to mine.
 
> This is really one of those situations where any decision is better
> than no decision.  The general consensus so far is that stuff like
> this just gets installed and users/devs who don't like it can use
> INSTALL_MASK.  I could care less whether we do it that way or via USE
> flags, but it seems like we'll still be debating this when I retire.

INSTALL_MASK has broken my system for me in the past by trying to mask
build files, eg. if you mask Makefiles and their variants you'll break
compilations that need a Makefile that is present on the system, I
can't recall which package installs this, but I was unhappy; that's why
I'm not really a fan of using it in its current form.

Similarly, something like INSTALL_MASK="*.ext" can hurt packages that
don't use *.ext in the same way as the *.ext you intend to mask. I am
wondering, does INSTALL_MASK support some form of globs?

eg. INSTALL_MASK="/{usr/lib*,etc}/systemd/**/*.{service,target,wants}"

I don't see this work since Bash would expand this upon sourcing. :(

Is there an easy way (at least for Portage) for the user to hook his
own install mask functionality? Let's say I want to run some function
over the file to be installed, to more carefully check what kind of a
file it is; can I do something like that? I'd rather be safe than sorry.

> If people are going to quit over this, then I suspect that we're just
> going to have to deal with the inevitable - if 4 people are willing to
> quit over the INSTALL_MASK approach then I'm sure as many will quit
> over just about any approach...

True, trying to not make people quit could make more people quit. ;-/

Thank you, I'm certainly convinced my idea was a bit overzealous. :)

-- 
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 --]

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Markos Chandras]

On 16 June 2013 23:02, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Sun, 16 Jun 2013 15:31:10 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> On Sun, Jun 16, 2013 at 3:22 PM, Tom Wijsman <TomWij@gentoo.org>
>> wrote:
>> > Either by denoting USE flags in USE as special _or_ introducing a
>> > separate OUSE variable.
>> >
>> > They don't have to be "openrc", "cron", "systemd" but could be like
>> > "init-scripts", "cron-files", "systemd-units"; to not collide with
>> > any existing USE flags, if any.
>> >
>> > Do they start to depend on each other? Why?
>>
>> Bottom line is that in order to accomplish any of this we need to
>> expand PMS to specify a syntax, implement this stuff in portage, and
>> then start modifying all our ebuilds so that heaven-forbid you don't
>> get an openrc script installed if you don't set USE=openrc.
>>
>> I don't think any of this is worth it for a one block text file.
>

I believe this proposal aims to workaround the "we can't work
together" problem than actually providing
real benefit to the way we maintain packages.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[William Hubbs]

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

On Mon, Jun 17, 2013 at 02:38:00PM +0100, Markos Chandras wrote:
> On 16 June 2013 23:02, Tom Wijsman <TomWij@gentoo.org> wrote:
> > On Sun, 16 Jun 2013 15:31:10 -0400
> > Rich Freeman <rich0@gentoo.org> wrote:
> >
> >> On Sun, Jun 16, 2013 at 3:22 PM, Tom Wijsman <TomWij@gentoo.org>
> >> wrote:
> >> > Either by denoting USE flags in USE as special _or_ introducing a
> >> > separate OUSE variable.
> >> >
> >> > They don't have to be "openrc", "cron", "systemd" but could be like
> >> > "init-scripts", "cron-files", "systemd-units"; to not collide with
> >> > any existing USE flags, if any.
> >> >
> >> > Do they start to depend on each other? Why?
> >>
> >> Bottom line is that in order to accomplish any of this we need to
> >> expand PMS to specify a syntax, implement this stuff in portage, and
> >> then start modifying all our ebuilds so that heaven-forbid you don't
> >> get an openrc script installed if you don't set USE=openrc.
> >>
> >> I don't think any of this is worth it for a one block text file.
> >
> 
> I believe this proposal aims to workaround the "we can't work
> together" problem than actually providing
> real benefit to the way we maintain packages.

Yes, it sounds that way to me as well. We really need to find ways to
work together/compromise instead of using proposals like this one to get
around the fact that some of us don't want to work together.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1364 bytes --]

Am Sonntag, 16. Juni 2013, 21:22:44 schrieb Tom Wijsman:
> On Sun, 16 Jun 2013 20:41:05 +0200
> 
> Michał Górny <mgorny@gentoo.org> wrote:
> > Dnia 2013-06-16, o godz. 20:32:55
> > 
> > Tom Wijsman <TomWij@gentoo.org> napisał(a):
> > > On Sun, 16 Jun 2013 20:20:53 +0200
> > > 
> > > hasufell <hasufell@gentoo.org> wrote:
> > > > Use flags trigger rebuilds. Rebuild libreoffice for a doc useflag?
> > > > Have fun.
> > > 
> > > If you introduce a separate set of USE flags that only reinstall the
> > > optional files and don't touch the rest, you don't have this
> > > problem.
> > 
> > And how would you do that? Sounds like a heavy magic with a lot of
> > inconsistency and problems whenever things start to depend one
> > on another.
> 

The problem is that these files can depend on the build parameters. E.g., 
during build variables are filled in on file locations, use-flag settings etc. 
There are many ebuilds in the tree where configuration files are first sed'ed 
and then installed.

Effectively, you'd have to store the content of the file somewhere (in the 
package database) where it can be pulled out if it is needed. 

Notice something? We're only moving the files out of sight, they are still 
there! BAM!

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Tom Wijsman]

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

On Sun, 16 Jun 2013 20:20:53 +0200
hasufell <hasufell@gentoo.org> wrote:

> On 06/16/2013 08:12 PM, Pandu Poluan wrote:
> > On Jun 16, 2013 9:52 PM, "hasufell" <hasufell@gentoo.org> wrote:
> >>
> > 
> > --snip--
> > 
> >>
> >> Doing it via regular useflags is just wrong.
> >>
> > 
> > I'm sorry, but what's wrong with using USE flags?
> > 
> 
> Use flags trigger rebuilds. Rebuild libreoffice for a doc useflag?
> Have fun.

If you introduce a separate set of USE flags that only reinstall the
optional files and don't touch the rest, you don't have this problem.

-- 
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 --]

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Michał Górny]

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

Dnia 2013-06-16, o godz. 12:21:54
Tom Wijsman <TomWij@gentoo.org> napisał(a):

> On Sun, 16 Jun 2013 05:33:22 -0400
> "Walter Dnes" <waltdnes@waltdnes.org> wrote:
> 
> > I think the best way to avoid maintainer conflicts is to take this
> > out of the hands of maintainers, 
> 
> +1 I was planning to write a GLEP for a concept where optional files
> would be maintained separately from packages, this could then be
> covered in later revisions of the PMS so that in a reasonable time from
> now we can properly support this and end to the rage and rage quits.
> 
> But you were before me, so I might as well elaborate with thoughts so
> we can all end up improving the idea about how this ends up being.
> 
> [...]

No offense but I feel like you're wasting your time, and that would
result in wasting more time of others as well.

We're talking about tiny files which are usually installed by one- or
two-liner. And any solution that has been brought so far has either
severe issues or is simply overcomplex.

Seriously, you're talking about replacing 'dofoo ${FILESDIR}/bar' with
two pages of text. This whole thread is taking much more effort than
the actual issue, please just stop at this point.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/16/2013 06:21 AM, Tom Wijsman wrote:
> On Sun, 16 Jun 2013 05:33:22 -0400
> "Walter Dnes" <waltdnes@waltdnes.org> wrote:
> 
>> I think the best way to avoid maintainer conflicts is to take this
>> out of the hands of maintainers, 
> 
> +1 I was planning to write a GLEP for a concept where optional files
> would be maintained separately from packages, this could then be
> covered in later revisions of the PMS so that in a reasonable time from
> now we can properly support this and end to the rage and rage quits.
> 
> But you were before me, so I might as well elaborate with thoughts so
> we can all end up improving the idea about how this ends up being.
> 
> Basically, what I have in mind is something along the lines of:
> 
>     Package directories get an additional directory, let's call it
>     "optional", where you can put optional files in to be installed.
> 
>     eg. ${PORTDIR}/sys-apps/dbus/files/optional/
>     or  ${PORTDIR}/sys-apps/dbus/optional/
> 
>     Files in this directory have a special header, it should contain a
>     condition based on which to install (eg. package to be present) and

http://www.gentoo.org/proj/en/qa/automagic.xml

We have established policy against just this type of behavior.  I'm
sorry, automagic dependencies is not okay.

- -Zero

>     optionally a parsable list of maintainers maintaining the package.
> 
>     (The word "file" below refers to files in the above directory,
>     unless noted otherwise; just saying to avoid confusion)
> 
>     Since there is a condition based on which these files are to be
>     installed, there is no need to specify such thing in the ebuild;
>     this effectively separates the maintenance from the pkg maintainer.
> 
>     Since the files have their individual maintainers, different
>     maintainers can maintain the file without having to maintain the
>     pkg itself in question; effectively allowing you to have a
>     maintainer than does _not_ want to maintain systemd whatsoever work
>     on his ebuild without ever seeing systemd, whereas the developer
>     that wants to contribute an optional systemd file can without a
>     problem introduce it without bothering the maintainer.
> 
>     If a file does not contain a list of maintainers, it inherits the
>     list of maintainers from the package; this allows the package
>     maintainer itself to easily create a file without having to
>     duplicate his own metadata all over the place.
> 
>     A file not containing a maintainer isn't a leeway for others to add
>     themselves, files that are unmaintained should have
>     maintainer-needed@g.o to prevent us from hurting the users, if bugs
>     reveal a file is broken beyond repair it should be removed.
> 
>     So, there's one thing left; what about bugs filed?
> 
>     Easy, it could be made more clear in the build log which optional
>     files were installed as well as list the list of maintainers for
>     each optional file; that way, if the maintainers have the least
>     thought that it is a problem caused by an optional file, they can
>     easily assign it to those individuals maintaining that file.
> 
>     As a side benefit, optional files are separated from patches.
> 
>     What does everyone think about such approach?
> 
>> and put it in the hands of users.
> 
> -1 Not because I don't want users to be able to do this, but more
> because I can't see a reasonable way for them to do this; for something
> as widespread as this, there should at least be supervision. We can't
> have a random user commit a random service unit for security reasons;
> there has to be some kind of review, I don't see how though.
> 
> Based on that, I think the best place is the Portage tree; these files
> are as small as patches, so infra and the community as a whole doesn't
> really see a problem in placing it there.
> 
>> At one time there was a package of all possible systemd units that
>> could be installed as one ebuild. [...SNIP...] I suggest a more
>> targetted approach...
> 
> Agreed, if you don't tie them with packages, you get nasty clumps.
> 
>> * a script (or compiled program)
> 
> We can have the package managers do this instead, I think there is no
> need for yet another separate script / utility to be ran; the logic
> behind installing optional files that I have in mind doesn't introduce
> too much complexity as far as I know.
> 
>> * that reads the output of "eix-installed -a"
> 
> We can't force such dependency; even better, we don't need such
> dependency since the package manager is able to do this.
> 
>> * compares against a config file in /etc
> 
> Maybe, maybe not; I wonder if it is sufficient to just check if the
> package in question is installed. Others could use INSTALL_MASK.
> 
> I mean, the percentage of people wanting to run an init script but not
> its init scripts / unit files is extremely low I think; if anyone
> knows of valid cases, feel free to elaborate upon them.
> 
>> * adds or deletes files based on the contents of the config file
> 
> I don't think deleting files is acceptable towards the maintainer; I
> don't really see a need for this either, does anyone have an example?
> 
>>   I was originally thinking of systemd units, but this could be
>> applied to initscripts or man files or info files or html docs or
>> whatever.
> 
> Indeed, we should cover all optional files:
> 
> - OpenRC conf.d configuration files and init.d init scripts
> - systemd service unit files, targets and similar files
> - PAM files, desktop files, logrotate files, cron files, bash completion
> - ...
> 
>> In addition to pulling in standard stuff, it could pull in
>> custom units or docs from "personal overlay" sources.  It would
>> usually be run once, right after an update.
> 
> When you let the PM do this, this is almost automatically covered.
> 
>>   IANACP (I Am Not A C Programmer), so I would probably do this in
>> bash if I did it strictly for personal use.
> 
> I think I've repeated it enough above, this is more trivial in the PM.
> 
>> But I'm beginning to wonder if it might be a useful approach resolve
>> some conflicts between various groups of users/developers.
> 
> Definitely, by designing an approach that uses a separate directory in a
> package, you assign maintainers to individual files like eclasses do.
> 
>> end-users could easily customize their systems' *REGARDLESS OF HOW
>> DEVELOPERS SET UP EBUILDS*.
> 
> Indeed, given the defined structure, users can hack things together.
> 
>> This might require a "systemd units herd" to supply a tarball with
>> systemd units that would be selectively installed.  And possibly a
>> "documentation herd", etc.
> 
> Without going to a specific example, some existing herds cover this.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIbBAEBAgAGBQJRveHRAAoJEKXdFCfdEflKyoMP+LzhNJ3T6gRpso5ud5WojgaU
itospzwVQ1sR2Mwo83fSvV3lq1XciCLmbXXXaNHruqcrH5zhSRLUkHlUJz8S2AVF
mScdDSJ009Es9+kdiHN3fi/di8kqKUdSKVbCVf+VRh9a+OzvJ3MH8GJEMT8wpZsT
Z4z/BlWasJR7B0sJ4+Zb8czGgWqcEJFFLmCgx+IEkft+V3O5UoNe0+C7ZaKTQjAX
CHjrOhKrdNTfhc612NoI0TKO9p5i+LeCjX/D/7WJkvuQW6W7Sru4J2iKNKY2XbYD
Q1v2DKxmx8KuhCoyoKVysrGbpmAvdj3kY9AFOBc8wdE4UvmN9WTjpHoWeq4YHoZt
xjycvTQmrHj7m9dO1k/NkJnK/a9K7Zpg4ND5QzxHx42gdXWO/4eGkgTthPaxOxH3
kJNw/r6eT1yiFns0z7E+qEn019XR7FBVzYPOS0aX6G2CbL5rdBIYInhbz8KC5lJy
YLj5HMyNB9HgwU5+PZdkOkI8fYDR7CPKkSu3YHdnYabqac7ZE1gniP1QuPcXxgqg
sOGJyMaSJ04Ax5+RIiLPDLDT/j/wiQMBDMfe5jWTxfPNJdrYRv8xH1NmUUBfaoXR
EJhkFzmlSpTHF+gXMx43Y13n1cohXp/mb5LOyDwR3HwBphlYjnGTUBs6JXEKAQqV
kqWMrbLkL4yFiV5Ty5A=
=QDVG
-----END PGP SIGNATURE-----

Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Tom Wijsman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 16 Jun 2013 12:03:29 -0400
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:

> On 06/16/2013 06:21 AM, Tom Wijsman wrote:
> >     Files in this directory have a special header, it should
> > contain a condition based on which to install (eg. package to be
> > present) and
> 
> http://www.gentoo.org/proj/en/qa/automagic.xml
> 
> We have established policy against just this type of behavior.  I'm
> sorry, automagic dependencies is not okay.

The conditions don't have to be automatic, that was a mere example to
fill in the template of this idea; you could base it upon something
configurable by the user. Many of this isn't thought through; this is
why this is merely an idea and not a GLEP proposal, given the feedback
I'm not even sure whether I am still going to write one. If the need
for it drops over the next two weeks, that would be a waste of time...

- -- 
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQEcBAEBAgAGBQJRvfD0AAoJEJWyH81tNOV9vSEIALqJqJNfORPt6Pf7e29vRGaI
ZCawmB+EihUcYf+uF/wG/h8lh5muegVu13WbK43XAkao01bw+vZ97OMUkFZyUY/v
Spzn2wjbVEagWzxSQHaYJaRy0DyzEcJNoRqoziO5zi/BndgqnR9IaePqj9a/386Z
+fDebnuo5Xv/k4009M58KiQCpyqKfHswlGI3DyMEqR2POiPm7+Kd4ZFeTfy6W7IC
/jXlC52g5AW83Z9UIyqaIC/cqU4XRk3q2bnAEEnK3TXrJRTxO8GqGaQz0hBe/rBv
c/78vFeM+/Vik/9rbUrOnVqugph4hhLF05ECPdIhq/uTuN3jT7APFIflhB7fKHU=
=f19G
-----END PGP SIGNATURE-----

Re: [gentoo-project] Proposal for add-on file utility (run after emerge update)

[Canek Peláez Valdés]

On Sun, Jun 16, 2013 at 4:33 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Wed, Jun 12, 2013 at 07:05:55AM -0400, Rich Freeman wrote
>> Alas, I couldn't attend the council meeting in-person, but it seems
>> like council missed the point of my request RE commits against
>> maintainer wishes (or maybe not - if so I'll happily shut up as far as
>> persuading the council goes).  That said, I expressed it as a general
>> request in the hope to not have something systemd-specific, and it
>> sounds like that is not desired.
>
>   I think the best way to avoid maintainer conflicts is to take this out
> of the hands of maintainers, and put it in the hands of users.  At one
> time there was a package of all possible systemd units that could be
> installed as one ebuild.  Apparently, some "inode fundamentalists"
> objected to having a bunch of unnecessary files dumped on their hard
> drives (imagine that), so that package was removed.  I suggest a more
> targetted approach...
> * a script (or compiled program)
> * that reads the output of "eix-installed -a"
> * compares against a config file in /etc
> * adds or deletes files based on the contents of the config file
>
>   I was originally thinking of systemd units, but this could be applied
> to initscripts or man files or info files or html docs or whatever.  In
> addition to pulling in standard stuff, it could pull in custom units or
> docs from "personal overlay" sources.  It would usually be run once,
> right after an update.
>
>   IANACP (I Am Not A C Programmer), so I would probably do this in bash
> if I did it strictly for personal use.  But I'm beginning to wonder if
> it might be a useful approach resolve some conflicts between various
> groups of users/developers.  I.e. end-users could easily customize their
> systems' *REGARDLESS OF HOW DEVELOPERS SET UP EBUILDS*.  This might
> require a "systemd units herd" to supply a tarball with systemd units
> that would be selectively installed.  And possibly a "documentation
> herd", etc.

Really, it's that hard to use INSTALL_MASK?

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-project] Proposal for add-on file utility (run after emerge update)

[Ciaran McCreesh]

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

On Sun, 16 Jun 2013 05:33:22 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:
> On Wed, Jun 12, 2013 at 07:05:55AM -0400, Rich Freeman wrote
> > Alas, I couldn't attend the council meeting in-person, but it seems
> > like council missed the point of my request RE commits against
> > maintainer wishes (or maybe not - if so I'll happily shut up as far
> > as persuading the council goes).  That said, I expressed it as a
> > general request in the hope to not have something systemd-specific,
> > and it sounds like that is not desired.
> 
>   I think the best way to avoid maintainer conflicts is to take this
> out of the hands of maintainers, and put it in the hands of users.

You mean you want a technological solution to a social problem?

-- 
Ciaran McCreesh

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