[gentoo-project] Call for agenda items - Council meeting 2014-03-11

[gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Anthony G. Basile]

Hi everyone,

I'm putting the call out there for any agenda items for the next Council 
meeting, which will be held on March 11, 2014 at 1900 UTC.  This is 
short notice but we got off track because of FOSDEM and we're going to 
try to get back on track.

So far, the only item is final ratification of glep 63 [1].

Ref.
[1] https://wiki.gentoo.org/wiki/GLEP:63

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Patrick Lauer]

On 02/27/2014 09:08 PM, Anthony G. Basile wrote:
> Hi everyone,
> 
> I'm putting the call out there for any agenda items for the next Council
> meeting, which will be held on March 11, 2014 at 1900 UTC.  This is
> short notice but we got off track because of FOSDEM and we're going to
> try to get back on track.
> 
> So far, the only item is final ratification of glep 63 [1].

Since it's still a bit cold I'd like to start a nice fire to warm us up:

I'd like QA and Council to figure out how much we care about FHS.

My main complaint is some projects (including e.g. systemd and
apparently now also udev) storing config files in /lib and/or /usr/lib.

From FHS' point of view this is totally wrong, config files go to /etc
Only libraries should be in /lib.
Moving things to /usr/lib adds the extra fun that /usr needs to be
mounted to acces *config files*. This is bad for our collective blood
pressure.

So I'd like to see config files stored in /etc again. Where they can be
properly tracked and versioned ...

(iow, storing config files in any other location than /etc is wrong;
storing example configs in e.g. /usr/share is fine too; storing config
in any other place is a valid bug that needs to be fixed)

For upstreams that insist on splitting configs in "system default" and
"local override" (which is rather nonsensical, but let them have some
fun) I would suggest a subfolder of /etc, maybe /etc/defaults or
/etc/systemdefaults or maybe /etc/lib/etc/usr/static if that's what
makes people happy


Enjoy the exothermic oxidation,

Patrick

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Patrick Lauer]

On 02/27/2014 09:08 PM, Anthony G. Basile wrote:
> Hi everyone,
> 
> I'm putting the call out there for any agenda items for the next Council
> meeting, which will be held on March 11, 2014 at 1900 UTC.  This is
> short notice but we got off track because of FOSDEM and we're going to
> try to get back on track.
> 
> So far, the only item is final ratification of glep 63 [1].

Apparently this one went under the radar, resending:


> Please respond to this message with agenda items. Do not hesitate to >
repeat your agenda item here with a pointer if you previously
> suggested one (since the last meeting).

Here's one thing that's low priority and still controversial:

(Since no one wants the QA team to actually *do* anything ... sigh)


Make all cosmetic repoman warnings fatal

Rationale: Either we care about things like whitespace and quoting, or
we don't.

If we care then we shouldn't allow anyone to commit a bad ebuild

If we don't care then repoman shouldn't annoy us with useless whining
that doesn't matter anyway


The affected repoman checks should be at least (but possibly not limited
to):

* unused local useflag descriptions in metadata.xml
* Whitespace, both at the beginning and the end of the line
	(this will need an improved repoman check to make sense
	as it currently has a few false positive matches)
* variable quoting (may have false positives too)


Thanks,

Patrick

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Ulrich Mueller]

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

>>>>> On Fri, 28 Feb 2014, Patrick Lauer wrote:

> * unused local useflag descriptions in metadata.xml

Agreed.

> * Whitespace, both at the beginning and the end of the line
> 	(this will need an improved repoman check to make sense
> 	as it currently has a few false positive matches)
> * variable quoting (may have false positives too)

As long as there are false positives (in my experience, they often
occur for here-documents inside of ebuilds), these checks cannot be
fatal.

Ulrich

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Samuli Suominen]

On 28/02/14 13:15, Patrick Lauer wrote:
> On 02/27/2014 09:08 PM, Anthony G. Basile wrote:
>> Hi everyone,
>>
>> I'm putting the call out there for any agenda items for the next Council
>> meeting, which will be held on March 11, 2014 at 1900 UTC.  This is
>> short notice but we got off track because of FOSDEM and we're going to
>> try to get back on track.
>>
>> So far, the only item is final ratification of glep 63 [1].
> Since it's still a bit cold I'd like to start a nice fire to warm us up:
>
> I'd like QA and Council to figure out how much we care about FHS.
>
> My main complaint is some projects (including e.g. systemd and
> apparently now also udev) storing config files in /lib and/or /usr/lib.
>
> From FHS' point of view this is totally wrong, config files go to /etc
> Only libraries should be in /lib.

Wow.
What about libtool .la text files?
What about kernel modules?
What about the genereted modules.* data in /lib/modules/$version/ which
are used in early boot by eg. kmod-static-nodes?
What about the binaries of OpenRC in /lib/rc, they aren't libraries?
And what about vendor modprobe.d files in /lib/modprobe.d?
I could continue this all day. I'm just trying to point out "Only
libraries should be in /lib." is complete bs and does not work.
Does FHS really articulate it the way you said it, "Only libraries
should be in /lib." or was that your own interpretation of it?

I'm not really expecting an answer as I'm already convinced FHS is so
badly outdated it's sad it doesn't suit
modern systems.
I hope they will catch up at some point.

- Samuli

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Tom Wijsman]

On Fri, 28 Feb 2014 13:58:17 +0200
Samuli Suominen <ssuominen@gentoo.org> wrote:

> 
> On 28/02/14 13:15, Patrick Lauer wrote:
> > On 02/27/2014 09:08 PM, Anthony G. Basile wrote:
> >> Hi everyone,
> >>
> >> I'm putting the call out there for any agenda items for the next
> >> Council meeting, which will be held on March 11, 2014 at 1900
> >> UTC.  This is short notice but we got off track because of FOSDEM
> >> and we're going to try to get back on track.
> >>
> >> So far, the only item is final ratification of glep 63 [1].
> > Since it's still a bit cold I'd like to start a nice fire to warm
> > us up:
> >
> > I'd like QA and Council to figure out how much we care about FHS.
> >
> > My main complaint is some projects (including e.g. systemd and
> > apparently now also udev) storing config files in /lib
> > and/or /usr/lib.
> >
> > From FHS' point of view this is totally wrong, config files go
> > to /etc Only libraries should be in /lib.
> 
> Wow.
> What about libtool .la text files?
> What about kernel modules?
> What about the genereted modules.* data in /lib/modules/$version/
> which are used in early boot by eg. kmod-static-nodes?
> What about the binaries of OpenRC in /lib/rc, they aren't libraries?
> And what about vendor modprobe.d files in /lib/modprobe.d?
> I could continue this all day. I'm just trying to point out "Only
> libraries should be in /lib." is complete bs and does not work.
> Does FHS really articulate it the way you said it, "Only libraries
> should be in /lib." or was that your own interpretation of it?
> 
> I'm not really expecting an answer as I'm already convinced FHS is so
> badly outdated it's sad it doesn't suit
> modern systems.
> I hope they will catch up at some point.

That's like saying a new modern browser which doesn't follow the web
standards is to be used to form a new revision of those web standards.

Soon supported in a browser near you, later added in the web standards:

<head>
  <title>
    <marquee>
      Welcome to Gentoo is Rice, the Volume goes to 11 here.
    </marquee>
  </title>
</head>

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Rich Freeman]

On Fri, Feb 28, 2014 at 6:58 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> Wow.
> What about ...

This didn't get mentioned in the initial post, but can we get
discussion of individual agenda items in a separate thread?

I suspect that is how the repoman fatal request got missed last time
around - better to just have a "tracker thread" for initial mention of
topics, and move the debate into a separate thread.

That said, please do discuss agenda items - the council shouldn't be
the guys on the mountain who input questions and output seemingly
disconnected answers.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Ulrich Mueller]

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

>>>>> On Fri, 28 Feb 2014, Rich Freeman wrote:

> This didn't get mentioned in the initial post, but can we get
> discussion of individual agenda items in a separate thread?

+1

Also use the appropriate group for it, please. Technical topics should
be discussed in -dev.

Ulrich

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Anthony G. Basile]

On 02/28/2014 06:15 AM, Patrick Lauer wrote:
> On 02/27/2014 09:08 PM, Anthony G. Basile wrote:
>> Hi everyone,
>>
>> I'm putting the call out there for any agenda items for the next Council
>> meeting, which will be held on March 11, 2014 at 1900 UTC.  This is
>> short notice but we got off track because of FOSDEM and we're going to
>> try to get back on track.
>>
>> So far, the only item is final ratification of glep 63 [1].
> Since it's still a bit cold I'd like to start a nice fire to warm us up:
>
> I'd like QA and Council to figure out how much we care about FHS.
>
> My main complaint is some projects (including e.g. systemd and
> apparently now also udev) storing config files in /lib and/or /usr/lib.
>
>  From FHS' point of view this is totally wrong, config files go to /etc
> Only libraries should be in /lib.
> Moving things to /usr/lib adds the extra fun that /usr needs to be
> mounted to acces *config files*. This is bad for our collective blood
> pressure.
>
> So I'd like to see config files stored in /etc again. Where they can be
> properly tracked and versioned ...
>
> (iow, storing config files in any other location than /etc is wrong;
> storing example configs in e.g. /usr/share is fine too; storing config
> in any other place is a valid bug that needs to be fixed)
>
> For upstreams that insist on splitting configs in "system default" and
> "local override" (which is rather nonsensical, but let them have some
> fun) I would suggest a subfolder of /etc, maybe /etc/defaults or
> /etc/systemdefaults or maybe /etc/lib/etc/usr/static if that's what
> makes people happy
>
>
> Enjoy the exothermic oxidation,
>
> Patrick
>
>
Speaking as a council member and the next chair: Patrick, how would you 
pose this as a motion?  As stated, the council should "discuss FHS" but 
how would you word this as a policy that we can rule on?  I have an idea 
but would like to hear what you want.

Speaking as a gentoo dev: This is one of my objections with systemd and 
the whole / + /usr merge.  It violates a standard which is assumed in 
many setups, namely FHS.  Another is that systemd violates the "one 
thing well" principle.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Samuli Suominen]

On 28/02/14 17:34, Anthony G. Basile wrote:
> On 02/28/2014 06:15 AM, Patrick Lauer wrote:
>> On 02/27/2014 09:08 PM, Anthony G. Basile wrote:
>>> Hi everyone,
>>>
>>> I'm putting the call out there for any agenda items for the next
>>> Council
>>> meeting, which will be held on March 11, 2014 at 1900 UTC.  This is
>>> short notice but we got off track because of FOSDEM and we're going to
>>> try to get back on track.
>>>
>>> So far, the only item is final ratification of glep 63 [1].
>> Since it's still a bit cold I'd like to start a nice fire to warm us up:
>>
>> I'd like QA and Council to figure out how much we care about FHS.
>>
>> My main complaint is some projects (including e.g. systemd and
>> apparently now also udev) storing config files in /lib and/or /usr/lib.
>>
>>  From FHS' point of view this is totally wrong, config files go to /etc
>> Only libraries should be in /lib.
>> Moving things to /usr/lib adds the extra fun that /usr needs to be
>> mounted to acces *config files*. This is bad for our collective blood
>> pressure.
>>
>> So I'd like to see config files stored in /etc again. Where they can be
>> properly tracked and versioned ...
>>
>> (iow, storing config files in any other location than /etc is wrong;
>> storing example configs in e.g. /usr/share is fine too; storing config
>> in any other place is a valid bug that needs to be fixed)
>>
>> For upstreams that insist on splitting configs in "system default" and
>> "local override" (which is rather nonsensical, but let them have some
>> fun) I would suggest a subfolder of /etc, maybe /etc/defaults or
>> /etc/systemdefaults or maybe /etc/lib/etc/usr/static if that's what
>> makes people happy
>>
>>
>> Enjoy the exothermic oxidation,
>>
>> Patrick
>>
>>
> Speaking as a council member and the next chair: Patrick, how would
> you pose this as a motion?  As stated, the council should "discuss
> FHS" but how would you word this as a policy that we can rule on?  I
> have an idea but would like to hear what you want.
>
> Speaking as a gentoo dev: This is one of my objections with systemd
> and the whole / + /usr merge.  It violates a standard which is assumed
> in many setups, namely FHS.  Another is that systemd violates the "one
> thing well" principle.
>

That isn't true; systemd has dozens of sep. executables and each of them
do one'ish task, and do it well. The one running in PID 1 has very
little to do with them.
So by your definition, it completely follows the "one thing well" principle.
Futher, 'assumed in many setups', / + /usr, from which hat you pulled
that rabbit out of? Merging the directories would propably bring in
better compability, as
it wouldnt matter anymore if something is hardcoding /bin/foo or
/usr/bin/foo or even /usr/sbin/foo.

I'd like the council to stick to facts when discussing the topic,
please. And remember, I'm not anykind of pro-systemd advocate, AT ALL.

And sorry for jumping in on the thread, but I couldn't help it, when
people spread these things.

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Rich Freeman]

On Fri, Feb 28, 2014 at 10:34 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
> Speaking as a council member and the next chair: Patrick, how would you pose
> this as a motion?  As stated, the council should "discuss FHS" but how would
> you word this as a policy that we can rule on?  I have an idea but would
> like to hear what you want.

I don't think it hurts to just have discussion topics, but I agree
that I wouldn't expect anything decisive to come out of it.  In theory
we can just as easily discuss on a list.

I think we probably need some kind of discussion before we really
consider motions, unless we just want to see them not pass.  Any kind
of policy in this area is potentially very far-reaching.

In this thread I'm just going to stick to talking about the agenda,
and not the topics themselves...

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Patrick Lauer]

On Friday 28 February 2014 10:34:32 Anthony G. Basile wrote:
> On 02/28/2014 06:15 AM, Patrick Lauer wrote:
> > On 02/27/2014 09:08 PM, Anthony G. Basile wrote:
> >> Hi everyone,
> >> 
> >> I'm putting the call out there for any agenda items for the next Council
> >> meeting, which will be held on March 11, 2014 at 1900 UTC.  This is
> >> short notice but we got off track because of FOSDEM and we're going to
> >> try to get back on track.
> >> 
> >> So far, the only item is final ratification of glep 63 [1].
> > 
> > Since it's still a bit cold I'd like to start a nice fire to warm us up:
> > 
> > I'd like QA and Council to figure out how much we care about FHS.
> > 
> > My main complaint is some projects (including e.g. systemd and
> > apparently now also udev) storing config files in /lib and/or /usr/lib.
> > 
> >  From FHS' point of view this is totally wrong, config files go to /etc
> > 
> > Only libraries should be in /lib.
> > Moving things to /usr/lib adds the extra fun that /usr needs to be
> > mounted to acces *config files*. This is bad for our collective blood
> > pressure.
> > 
> > So I'd like to see config files stored in /etc again. Where they can be
> > properly tracked and versioned ...
> > 
> > (iow, storing config files in any other location than /etc is wrong;
> > storing example configs in e.g. /usr/share is fine too; storing config
> > in any other place is a valid bug that needs to be fixed)
> > 
> > For upstreams that insist on splitting configs in "system default" and
> > "local override" (which is rather nonsensical, but let them have some
> > fun) I would suggest a subfolder of /etc, maybe /etc/defaults or
> > /etc/systemdefaults or maybe /etc/lib/etc/usr/static if that's what
> > makes people happy
> > 
> > 
> > Enjoy the exothermic oxidation,
> > 
> > Patrick
> 
> Speaking as a council member and the next chair: Patrick, how would you
> pose this as a motion?  As stated, the council should "discuss FHS" but
> how would you word this as a policy that we can rule on?  I have an idea
> but would like to hear what you want.

I don't think we should aim at strict FHS adherence - as far as I remember the 
last time people looked at it we figured out that e.g. slotted KDE would be 
"invalid". So strict adherence was never considered sane anyway.

Restricting the discussion to "Config files go to /etc with examples in 
/usr/share" might work - I'm not offended by kernel modules or python libraries 
in /lib, but putting *config* there is just ....aaaaugh 

(And putting boot-relevant config files in /usr, that is just hilarious - now 
you MUST HAVE an initrd so that you can even have a chance at booting, because 
your config files are not visible in the rootfs. The lesson why /etc appears to 
have been lost)

> 
> Speaking as a gentoo dev: This is one of my objections with systemd and
> the whole / + /usr merge.  It violates a standard which is assumed in
> many setups, namely FHS.  Another is that systemd violates the "one
> thing well" principle.

I disagree with the rather random nature of the change, so now basically /usr 
is the new / (why not move everything to / and save 4 characters on each path 
name?) and you need an initrd to boot (which has to replicate all of the 
rootfs just to have a chance to mount /usr)

Y'know, maybe I've turned into a conservative greybeard, but moving rootfs 
into an initrd just doesn't add up :) 

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Patrick Lauer]

On Friday 28 February 2014 17:56:06 Samuli Suominen wrote:
> On 28/02/14 17:34, Anthony G. Basile wrote:
> > On 02/28/2014 06:15 AM, Patrick Lauer wrote:
> >> On 02/27/2014 09:08 PM, Anthony G. Basile wrote:
> >>> Hi everyone,
> >>> 
> >>> I'm putting the call out there for any agenda items for the next
> >>> Council
> >>> meeting, which will be held on March 11, 2014 at 1900 UTC.  This is
> >>> short notice but we got off track because of FOSDEM and we're going to
> >>> try to get back on track.
> >>> 
> >>> So far, the only item is final ratification of glep 63 [1].
> >> 
> >> Since it's still a bit cold I'd like to start a nice fire to warm us up:
> >> 
> >> I'd like QA and Council to figure out how much we care about FHS.
> >> 
> >> My main complaint is some projects (including e.g. systemd and
> >> apparently now also udev) storing config files in /lib and/or /usr/lib.
> >> 
> >>  From FHS' point of view this is totally wrong, config files go to /etc
> >> 
> >> Only libraries should be in /lib.
> >> Moving things to /usr/lib adds the extra fun that /usr needs to be
> >> mounted to acces *config files*. This is bad for our collective blood
> >> pressure.
> >> 
> >> So I'd like to see config files stored in /etc again. Where they can be
> >> properly tracked and versioned ...
> >> 
> >> (iow, storing config files in any other location than /etc is wrong;
> >> storing example configs in e.g. /usr/share is fine too; storing config
> >> in any other place is a valid bug that needs to be fixed)
> >> 
> >> For upstreams that insist on splitting configs in "system default" and
> >> "local override" (which is rather nonsensical, but let them have some
> >> fun) I would suggest a subfolder of /etc, maybe /etc/defaults or
> >> /etc/systemdefaults or maybe /etc/lib/etc/usr/static if that's what
> >> makes people happy
> >> 
> >> 
> >> Enjoy the exothermic oxidation,
> >> 
> >> Patrick
> > 
> > Speaking as a council member and the next chair: Patrick, how would
> > you pose this as a motion?  As stated, the council should "discuss
> > FHS" but how would you word this as a policy that we can rule on?  I
> > have an idea but would like to hear what you want.
> > 
> > Speaking as a gentoo dev: This is one of my objections with systemd
> > and the whole / + /usr merge.  It violates a standard which is assumed
> > in many setups, namely FHS.  Another is that systemd violates the "one
> > thing well" principle.
> 
> That isn't true; systemd has dozens of sep. executables and each of them
> do one'ish task, and do it well. The one running in PID 1 has very
> little to do with them.

Bad troll is bad - half the bits rely on PID1, e.g. logind is basically a 
convoluted dbus proxy into PID1.

If you can show logind or journald running with sysvinit as PID1 your argument 
has a chance ...

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Ulrich Mueller]

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

>>>>> On Thu, 27 Feb 2014, Anthony G Basile wrote:

> I'm putting the call out there for any agenda items for the next
> Council meeting, which will be held on March 11, 2014 at 1900 UTC.
> This is short notice but we got off track because of FOSDEM and
> we're going to try to get back on track.

In February we have voted to "ban new EAPI 1 and 2 ebuilds". Now I've
seen some commits where ebuilds were changed in place from EAPI 0 to
EAPI 1.

Can we clarify that the ban includes updating the EAPI in existing
ebuilds?

Ulrich

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Michał Górny]

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

Dnia 2014-03-03, o godz. 12:14:13
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >>>>> On Thu, 27 Feb 2014, Anthony G Basile wrote:
> 
> > I'm putting the call out there for any agenda items for the next
> > Council meeting, which will be held on March 11, 2014 at 1900 UTC.
> > This is short notice but we got off track because of FOSDEM and
> > we're going to try to get back on track.
> 
> In February we have voted to "ban new EAPI 1 and 2 ebuilds". Now I've
> seen some commits where ebuilds were changed in place from EAPI 0 to
> EAPI 1.
> 
> Can we clarify that the ban includes updating the EAPI in existing
> ebuilds?

So how we are supposed to handle updating rev-deps to use proper slot?
Convert ancient versions to a new EAPI or just drop them completely?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/03/14 02:43 PM, Michał Górny wrote:
> Dnia 2014-03-03, o godz. 12:14:13 Ulrich Mueller <ulm@gentoo.org>
> napisał(a):
> 
>>>>>>> On Thu, 27 Feb 2014, Anthony G Basile wrote:
>> 
>>> I'm putting the call out there for any agenda items for the
>>> next Council meeting, which will be held on March 11, 2014 at
>>> 1900 UTC. This is short notice but we got off track because of
>>> FOSDEM and we're going to try to get back on track.
>> 
>> In February we have voted to "ban new EAPI 1 and 2 ebuilds". Now
>> I've seen some commits where ebuilds were changed in place from
>> EAPI 0 to EAPI 1.
>> 
>> Can we clarify that the ban includes updating the EAPI in
>> existing ebuilds?
> 
> So how we are supposed to handle updating rev-deps to use proper
> slot? Convert ancient versions to a new EAPI or just drop them
> completely?
> 

That's up to you, as maintainer, isn't it?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlMU4HgACgkQ2ugaI38ACPAVOgEAk+b6FA2990/5Z1zzxmSYSXWF
N6OM6hHFlSRU9YJHFIoA+wS+mlB8HC+suUknx3+mQze7SM2GMxfqIJaUjSyHiud+
=StYV
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Michał Górny]

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

Dnia 2014-03-03, o godz. 15:05:12
Ian Stakenvicius <axs@gentoo.org> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 03/03/14 02:43 PM, Michał Górny wrote:
> > Dnia 2014-03-03, o godz. 12:14:13 Ulrich Mueller <ulm@gentoo.org>
> > napisał(a):
> > 
> >>>>>>> On Thu, 27 Feb 2014, Anthony G Basile wrote:
> >> 
> >>> I'm putting the call out there for any agenda items for the
> >>> next Council meeting, which will be held on March 11, 2014 at
> >>> 1900 UTC. This is short notice but we got off track because of
> >>> FOSDEM and we're going to try to get back on track.
> >> 
> >> In February we have voted to "ban new EAPI 1 and 2 ebuilds". Now
> >> I've seen some commits where ebuilds were changed in place from
> >> EAPI 0 to EAPI 1.
> >> 
> >> Can we clarify that the ban includes updating the EAPI in
> >> existing ebuilds?
> > 
> > So how we are supposed to handle updating rev-deps to use proper
> > slot? Convert ancient versions to a new EAPI or just drop them
> > completely?
> > 
> 
> That's up to you, as maintainer, isn't it?

If I am fixing a few dozen ebuilds due to change in dependency package,
I'm not the maintainer.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Rich Freeman]

On Mon, Mar 3, 2014 at 3:13 PM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2014-03-03, o godz. 15:05:12
> Ian Stakenvicius <axs@gentoo.org> napisał(a):
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On 03/03/14 02:43 PM, Michał Górny wrote:
>> > Dnia 2014-03-03, o godz. 12:14:13 Ulrich Mueller <ulm@gentoo.org>
>> > napisał(a):
>> >
>> >> Can we clarify that the ban includes updating the EAPI in
>> >> existing ebuilds?
>> >
>> > So how we are supposed to handle updating rev-deps to use proper
>> > slot? Convert ancient versions to a new EAPI or just drop them
>> > completely?
>> >
>>
>> That's up to you, as maintainer, isn't it?
>
> If I am fixing a few dozen ebuilds due to change in dependency package,
> I'm not the maintainer.

I think we do need to be careful about not creating barriers to
maintenance like this.  If people are given the choice of doing a lot
of work to make a small improvement vs not doing an improvement at
all, they'll often pick the latter.

We definitely want to phase out the old EAPIs, but changes to existing
ebuilds shouldn't require bringing them fully up-to-date.  It should
be done if it makes sense, however (at the discretion of the person
doing the work).

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Ulrich Mueller]

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

>>>>> On Mon, 3 Mar 2014, Rich Freeman wrote:

> I think we do need to be careful about not creating barriers to
> maintenance like this. If people are given the choice of doing a lot
> of work to make a small improvement vs not doing an improvement at
> all, they'll often pick the latter.

> We definitely want to phase out the old EAPIs, but changes to
> existing ebuilds shouldn't require bringing them fully up-to-date.
> It should be done if it makes sense, however (at the discretion of
> the person doing the work).

If changing ebuilds to a banned EAPI is allowed, then we can as well
lift the ban altogether: I could create a new ebuild under some
allowed EAPI, then change it to a banned one, and it would still be
within the rules.

That's not what I would call a consistent policy. In this case, we
should better revert our decision from February.

Ulrich

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Rich Freeman]

On Tue, Mar 4, 2014 at 3:13 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
> If changing ebuilds to a banned EAPI is allowed, then we can as well
> lift the ban altogether: I could create a new ebuild under some
> allowed EAPI, then change it to a banned one, and it would still be
> within the rules.

In this case it was changed from 0 to 1.  I could see this argument if
it was changed from 5 to 1.  This also wasn't some attempt to find
loopholes in the rules.  If it were I'd recommend issuing a clear
declaration that the developer followed all the rules to the letter
and then punishing them for it anyway to make an example out of them.
If we're going to rely exclusively on rules to prevent antisocial
behavior I can guarantee that we're going to fail miserably, kind of
like the mortgage market in 2008.  Intent matters far more than
compliance.

Some EAPI changes are easier than others.  This one was only from
non-banned to banned because we haven't gotten around to banning EAPI
0 yet.  I'm all for doing that for non-toolchain ebuilds until we
figure out what to do with the toolchain.

There also isn't any deadline I can see for getting rid of EAPI
1/2/etc.  We're just trying to speed the process up so that it doesn't
take a decade (which is basically the current trend).

I guess I just don't see this as something likely to become a major
problem.  If it becomes one we can deal with it.

Don't get me wrong - I'm fine with clarifying rules/etc.  I just want
to avoid chasing after the perfect set of rules, because they'll never
be perfect, and that really isn't the source of problems in a
community.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Ralph Sennhauser]

On Tue, 4 Mar 2014 06:12:06 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> Some EAPI changes are easier than others.  This one was only from
> non-banned to banned because we haven't gotten around to banning EAPI
> 0 yet.  I'm all for doing that for non-toolchain ebuilds until we
> figure out what to do with the toolchain.

What toolchain is allowed to do the rest of the tree is as well.

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Patrick Lauer]

On Tuesday 04 March 2014 14:16:11 Ralph Sennhauser wrote:
> On Tue, 4 Mar 2014 06:12:06 -0500
> 
> Rich Freeman <rich0@gentoo.org> wrote:
> > Some EAPI changes are easier than others.  This one was only from
> > non-banned to banned because we haven't gotten around to banning EAPI
> > 0 yet.  I'm all for doing that for non-toolchain ebuilds until we
> > figure out what to do with the toolchain.
> 
> What toolchain is allowed to do the rest of the tree is as well.

Well, we can mask/remove/modify "everything else" without too much horrible 
stuff happening, but e.g. masking all of gcc because "ebuild doesn't follow 
policy" will not have any reasonable results.

So for now we have the toolchain exception, until we can get things patched up 
and tested enough.

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Rich Freeman]

On Tue, Mar 4, 2014 at 8:16 AM, Ralph Sennhauser <sera@gentoo.org> wrote:
> On Tue, 4 Mar 2014 06:12:06 -0500
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> Some EAPI changes are easier than others.  This one was only from
>> non-banned to banned because we haven't gotten around to banning EAPI
>> 0 yet.  I'm all for doing that for non-toolchain ebuilds until we
>> figure out what to do with the toolchain.
>
> What toolchain is allowed to do the rest of the tree is as well.
>

No reason it has to be that way, but we're not in a rush here.  Let's
just figure out the most sensible path forward.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-03-11

[Anthony G. Basile]

On 02/27/2014 08:08 AM, Anthony G. Basile wrote:
> Hi everyone,
>
> I'm putting the call out there for any agenda items for the next Council
> meeting, which will be held on March 11, 2014 at 1900 UTC.  This is
> short notice but we got off track because of FOSDEM and we're going to
> try to get back on track.
>
> So far, the only item is final ratification of glep 63 [1].
>
> Ref.
> [1] https://wiki.gentoo.org/wiki/GLEP:63
>

One week until the council meeting.  Just to make sure I'm not missing 
any issues and we don't have a last minute rush, here's the agenda so far:

http://dev.gentoo.org/~blueness/council/council_agenda_20140311.txt

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197