[gentoo-project] Call for agenda items - council meeting 2020-03-08

[gentoo-project] Call for agenda items - council meeting 2020-03-08

[Georgy Yakovlev]

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

Hello,

on 2020-03-08, the Gentoo council will meet at
19:00 UTC in the #gentoo-council channel on freenode.

Please reply to this message with any items you would like us to discuss
or vote on.

-- 
Georgy Yakovlev <gyakovlev@gentoo.org>

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

Re: [gentoo-project] Call for agenda items - council meeting 2020-03-08

[Michał Górny]

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

On Tue, 2020-02-25 at 19:59 -0800, Georgy Yakovlev wrote:
> Hello,
> 
> on 2020-03-08, the Gentoo council will meet at
> 19:00 UTC in the #gentoo-council channel on freenode.
> 
> Please reply to this message with any items you would like us to discuss
> or vote on.

Following the discussion within the QA team, I'd like to ask the Council
to clarify whether EAPI 4 ban applies to revision bumps as a result of
dependency changes?

I think the key point in banning EAPIs is that the maintainer (or
generally, someone caring about the package in question) should be
responsible for the EAPI bump.  I don't think anybody should be forced
to do that when in middle of large batch of changes (read: when I only
touch the package because it's blocking me).

In this particular case, I'm thinking of revbumps due to dependency
changes.  Say, if I do a change in a dependency *I* maintain, and have
to fix a large number of revdeps, I don't think it's fair to expect me
to EAPI-bump some packages I don't maintain.  The main difference is
that we're talking of dep change + revbump that can be linted via
pkgcheck/repoman vs. EAPI bump that needs full scale testing.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] Call for agenda items - council meeting 2020-03-08

[Raymond Jennings]

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

On Mon, Mar 2, 2020 at 3:57 AM Michał Górny <mgorny@gentoo.org> wrote:

> On Tue, 2020-02-25 at 19:59 -0800, Georgy Yakovlev wrote:
> > Hello,
> >
> > on 2020-03-08, the Gentoo council will meet at
> > 19:00 UTC in the #gentoo-council channel on freenode.
> >
> > Please reply to this message with any items you would like us to discuss
> > or vote on.
>
> Following the discussion within the QA team, I'd like to ask the Council
> to clarify whether EAPI 4 ban applies to revision bumps as a result of
> dependency changes?
>

Personally I don't think it should, especially if the change is just fixing
something that broke.


> I think the key point in banning EAPIs is that the maintainer (or
> generally, someone caring about the package in question) should be
> responsible for the EAPI bump.  I don't think anybody should be forced
> to do that when in middle of large batch of changes (read: when I only
> touch the package because it's blocking me).
>

Seconded.


> In this particular case, I'm thinking of revbumps due to dependency
> changes.  Say, if I do a change in a dependency *I* maintain, and have
> to fix a large number of revdeps, I don't think it's fair to expect me
> to EAPI-bump some packages I don't maintain.  The main difference is
> that we're talking of dep change + revbump that can be linted via
> pkgcheck/repoman vs. EAPI bump that needs full scale testing.
>

I second the motion.

I think that certain changes can be "grandfathered" if they can be done
without breaking anything

> --
> Best regards,
> Michał Górny
>
>

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

Re: [gentoo-project] Call for agenda items - council meeting 2020-03-08

[Ulrich Mueller]

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

>>>>> On Mon, 02 Mar 2020, Michał Górny wrote:

> Following the discussion within the QA team, I'd like to ask the Council
> to clarify whether EAPI 4 ban applies to revision bumps as a result of
> dependency changes?

> I think the key point in banning EAPIs is that the maintainer (or
> generally, someone caring about the package in question) should be
> responsible for the EAPI bump.  I don't think anybody should be forced
> to do that when in middle of large batch of changes (read: when I only
> touch the package because it's blocking me).

> In this particular case, I'm thinking of revbumps due to dependency
> changes.  Say, if I do a change in a dependency *I* maintain, and have
> to fix a large number of revdeps, I don't think it's fair to expect me
> to EAPI-bump some packages I don't maintain.  The main difference is
> that we're talking of dep change + revbump that can be linted via
> pkgcheck/repoman vs. EAPI bump that needs full scale testing.

EAPIs are being banned after a deprecation period, which typically is
two years. So I guess one can expect packages that run into the ban not
to be very actively maintained.

Looking at the plots [1] (especially the third plot from the top),
I don't see any change in slope for EAPI 0 in 2016-01 or for EAPI 4
in 2018-04. So arguably, the "banned" state doesn't give any additional
incentive to update an ebuild, as compared to the "deprecated" state.
After your proposed change, the difference between the two states would
be even more blurred.

Maybe we should revisit the concept, and ban EAPIs only when their last
ebuild has left the tree, i.e., when the EAPI is added to eapis-banned
in layout.conf?

Ulrich

[1] https://www.akhuettel.de/~huettel/plots/eapi.php

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

Re: [gentoo-project] Call for agenda items - council meeting 2020-03-08

[Michał Górny]

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

On Mon, 2020-03-02 at 13:38 +0100, Ulrich Mueller wrote:
> > > > > > On Mon, 02 Mar 2020, Michał Górny wrote:
> > Following the discussion within the QA team, I'd like to ask the Council
> > to clarify whether EAPI 4 ban applies to revision bumps as a result of
> > dependency changes?
> > I think the key point in banning EAPIs is that the maintainer (or
> > generally, someone caring about the package in question) should be
> > responsible for the EAPI bump.  I don't think anybody should be forced
> > to do that when in middle of large batch of changes (read: when I only
> > touch the package because it's blocking me).
> > In this particular case, I'm thinking of revbumps due to dependency
> > changes.  Say, if I do a change in a dependency *I* maintain, and have
> > to fix a large number of revdeps, I don't think it's fair to expect me
> > to EAPI-bump some packages I don't maintain.  The main difference is
> > that we're talking of dep change + revbump that can be linted via
> > pkgcheck/repoman vs. EAPI bump that needs full scale testing.
> 
> EAPIs are being banned after a deprecation period, which typically is
> two years. So I guess one can expect packages that run into the ban not
> to be very actively maintained.
> 
> Looking at the plots [1] (especially the third plot from the top),
> I don't see any change in slope for EAPI 0 in 2016-01 or for EAPI 4
> in 2018-04. So arguably, the "banned" state doesn't give any additional
> incentive to update an ebuild, as compared to the "deprecated" state.
> After your proposed change, the difference between the two states would
> be even more blurred.
> 
> Maybe we should revisit the concept, and ban EAPIs only when their last
> ebuild has left the tree, i.e., when the EAPI is added to eapis-banned
> in layout.conf?
> 

Not sure if this is practically able but technically I see an advantage
from having three distinct states:

1. Deprecation -- tooling warns about them but there are no consequences
for adding new ebuilds.

2. Ban I -- tooling errors out, if developers add new ebuilds
(as in real new ebuilds), we pursue it.

3. Ban II -- no ebuilds left, CI fatal, immediate revert.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] Call for agenda items - council meeting 2020-03-08

[Ulrich Mueller]

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

>>>>> On Mon, 02 Mar 2020, Michał Górny wrote:

> Not sure if this is practically able but technically I see an advantage
> from having three distinct states:

> 1. Deprecation -- tooling warns about them but there are no consequences
> for adding new ebuilds.

> 2. Ban I -- tooling errors out, if developers add new ebuilds
> (as in real new ebuilds), we pursue it.

Does this really occur at a scale that should bother us? The main
blocker for removal of old EAPIs are unmaintained ebuilds, and for
these any levels of more fine-grained bans won't help.

> 3. Ban II -- no ebuilds left, CI fatal, immediate revert.

Ulrich

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

Re: [gentoo-project] Call for agenda items - council meeting 2020-03-08

[Michał Górny]

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

On Mon, 2020-03-02 at 14:51 +0100, Ulrich Mueller wrote:
> > > > > > On Mon, 02 Mar 2020, Michał Górny wrote:
> > Not sure if this is practically able but technically I see an advantage
> > from having three distinct states:
> > 1. Deprecation -- tooling warns about them but there are no consequences
> > for adding new ebuilds.
> > 2. Ban I -- tooling errors out, if developers add new ebuilds
> > (as in real new ebuilds), we pursue it.
> 
> Does this really occur at a scale that should bother us? The main
> blocker for removal of old EAPIs are unmaintained ebuilds, and for
> these any levels of more fine-grained bans won't help.
> 

Probably not.  FWICS during the ban period there was only one commit
revbumping EAPI=4 ebuild and adding Prefix support.  All other cases
of adding EAPI=4 were just reverts of depgraph-breaking commits.

I used:

$ git log -p --diff-filter=A --since=2018-04-08

and grepped it for EAPI=.*4

-- 
Best regards,
Michał Górny


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