[gentoo-dev] RFC: ban EAPI 1

[gentoo-dev] RFC: ban EAPI 1

[Ulrich Mueller]

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

Hi,
The number of EAPI 1 ebuilds in the Portage tree has decreased to
a total of 60, corresponding to 0.16 %.

We briefly discussed in the QA team if we should demote EAPI 1 in
layout.conf from "eapis-deprecated" to "eapis-banned". This would
have the consequence that repoman would refuse to commit packages
containing such ebuilds. AFAICS there would be no impact on users.

What do you think?

Ulrich

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

Re: [gentoo-dev] RFC: ban EAPI 1

[Pacho Ramos]

El mié, 10-06-2015 a las 22:43 +0200, Ulrich Mueller escribió:
> Hi,
> The number of EAPI 1 ebuilds in the Portage tree has decreased to
> a total of 60, corresponding to 0.16 %.
> 
> We briefly discussed in the QA team if we should demote EAPI 1 in
> layout.conf from "eapis-deprecated" to "eapis-banned". This would
> have the consequence that repoman would refuse to commit packages
> containing such ebuilds. AFAICS there would be no impact on users.
> 
> What do you think?
> 
> Ulrich

I agree

Re: [gentoo-dev] RFC: ban EAPI 1

[Aaron W. Swenson]

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

On 2015-06-10 22:43, Ulrich Mueller wrote:
> Hi,
> The number of EAPI 1 ebuilds in the Portage tree has decreased to
> a total of 60, corresponding to 0.16 %.
> 
> We briefly discussed in the QA team if we should demote EAPI 1 in
> layout.conf from "eapis-deprecated" to "eapis-banned". This would
> have the consequence that repoman would refuse to commit packages
> containing such ebuilds. AFAICS there would be no impact on users.
> 
> What do you think?
> 
> Ulrich

Agreed. Yes. +1. Green arrow.

What do you take as a vote to the affirmative?

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

Re: [gentoo-dev] RFC: ban EAPI 1

[Brian Dolbec]

On Wed, 10 Jun 2015 22:43:10 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> Hi,
> The number of EAPI 1 ebuilds in the Portage tree has decreased to
> a total of 60, corresponding to 0.16 %.
> 
> We briefly discussed in the QA team if we should demote EAPI 1 in
> layout.conf from "eapis-deprecated" to "eapis-banned". This would
> have the consequence that repoman would refuse to commit packages
> containing such ebuilds. AFAICS there would be no impact on users.
> 
> What do you think?
> 
> Ulrich

DDDDDDDDDDOOOOOOOOOOOOOOOOOOOOOO IIIIIIIIIIITTTTTTTTTTTTT  ;)

+++++++++++++++++++++

-- 
Brian Dolbec <dolsen>

Re: [gentoo-dev] RFC: ban EAPI 1

[Chris Reffett]

On 6/10/2015 4:43 PM, Ulrich Mueller wrote:
> Hi,
> The number of EAPI 1 ebuilds in the Portage tree has decreased to
> a total of 60, corresponding to 0.16 %.
> 
> We briefly discussed in the QA team if we should demote EAPI 1 in
> layout.conf from "eapis-deprecated" to "eapis-banned". This would
> have the consequence that repoman would refuse to commit packages
> containing such ebuilds. AFAICS there would be no impact on users.
> 
> What do you think?
> 
> Ulrich
> 
Make it so.

Re: [gentoo-dev] RFC: ban EAPI 1

[Michał Górny]

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

Dnia 2015-06-10, o godz. 22:43:10
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> Hi,
> The number of EAPI 1 ebuilds in the Portage tree has decreased to
> a total of 60, corresponding to 0.16 %.
> 
> We briefly discussed in the QA team if we should demote EAPI 1 in
> layout.conf from "eapis-deprecated" to "eapis-banned". This would
> have the consequence that repoman would refuse to commit packages
> containing such ebuilds. AFAICS there would be no impact on users.
> 
> What do you think?

So be it.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: ban EAPI 1

[James Le Cuirot]

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

On Wed, 10 Jun 2015 22:43:10 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> We briefly discussed in the QA team if we should demote EAPI 1 in
> layout.conf from "eapis-deprecated" to "eapis-banned". This would
> have the consequence that repoman would refuse to commit packages
> containing such ebuilds. AFAICS there would be no impact on users.
> 
> What do you think?

Java team is fully aware that we make up the bulk of the remainder and
we are working to reduce it although other things have a habit of
jumping in front. I am due to remove all ia64 keywords from Java
packages and this change would mean that I have to address the EAPI of
5 ebuilds first but don't let that stop you.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

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

Re: [gentoo-dev] RFC: ban EAPI 1

[Andreas K. Huettel]

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

Am Mittwoch, 10. Juni 2015, 22:43:10 schrieb Ulrich Mueller:
> 
> We briefly discussed in the QA team if we should demote EAPI 1 in
> layout.conf from "eapis-deprecated" to "eapis-banned". This would
> have the consequence that repoman would refuse to commit packages
> containing such ebuilds. AFAICS there would be no impact on users.
> 

I was really looking forward to committing that :)))

Do it!!!

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJVeLBZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF
MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5nsMQALGeqB85oc+6zUoZ0/yalQAu
1liVvni0/qTbM5nsQXDE5bfHx8srhI5hzp9zo2veYTqc+MxdFYX2vuACyTaLZEjV
v2YtNVlVrildtw7HvIRVUQAeIO5zNlPo/wvtzrKobOwD4iEnC6snTnJbCB0KNBJM
kf7wlT57UM4sURt9vNtwkDz4BeAu/Z+hMAS3x2kDopoBfF1518xRLEJgEm3ODf9g
eglifcFRJHCvf1lCvZphvqO/zA8VLpPGNeYRjdqvoMRxnIEuTM82r3SnV5KPqJal
D9aiGwl+Sj2pK1ne2PLC25N9Q/hxB9V1KWHh2DAwOvRaVsEjOTwn1r2yxc4ngwXy
k1xIlRoRgH8x9mMceo4IvklI3O3vS1BBc3Wa1n2RJUDoqfy5SBIwfWEsauXu9xZY
mZUCTN5fWOSxDp+lOW7GcZzkzFgzCp7NxJfyLYxvBq2TX5R3LEnfniw3Wg/Boi9z
syms29sUa3k2s7Grcy8Gi9JfEjZaod2sq6KPPjhrwaM/zMrmzMdikZ/DGhdXl3rD
QHRpJfOGszEcK7TFf2Vkq7ofBeZqf63jtbt/+t935EspEpC/UjL/jgER5JML6GSl
2nJmnEQ8MQDUqNJbMoZyoBv516ftcsrcvQe3VfM0mHFJlClsHytSWHieptbutZZO
M1JXLbCfdK6cuamEs4Fx
=Vu8c
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: ban EAPI 1

[Daniel "zlg" Campbell]

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

On 06/10/2015 01:43 PM, Ulrich Mueller wrote:
> Hi, The number of EAPI 1 ebuilds in the Portage tree has decreased
> to a total of 60, corresponding to 0.16 %.
> 
> We briefly discussed in the QA team if we should demote EAPI 1 in 
> layout.conf from "eapis-deprecated" to "eapis-banned". This would 
> have the consequence that repoman would refuse to commit packages 
> containing such ebuilds. AFAICS there would be no impact on users.
> 
> What do you think?
> 
> Ulrich
> 

Please do!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVeTxMAAoJEAEkDpRQOeFwpWwP/0bVT7SLSx+yVmPETeoxQzXM
SNrLFZVTxWpgFVqE62Bq3IH5POqmchDcShUaOWp3hstn6Q8A3dkn6H7h/jMlkLDw
9kNUoKc6A7Lg9wbjsM7EkPoWinZL6GYhUbrEd/R9eO7DEq7GXFmMa5bfaJ2mseWn
fHHRzxULU7A5BpCcDOdVWaEbkSHwU5n+yH03bYT0f6JWt5YdB5WiGPzXIdA9pcc6
oLcZrvd073PSPn4ASo8D4qHtIB/LRt9yd8wQbWpMNPMFOZ/YWY5JpS8ILoaXOMvF
cJleYVaFPPECCejcOanNgG3OB2KLmLMYzuzxkSfo1TKyHe4gD+X4ssL/UDNEerAc
A/7RWVR52wZMIpXinFjvPwjJ6TfCBroL/phxXCwjEvgtunxzp0y928/dK6PQOard
f4cd7BGqPeOa9bEl1THniPnEAwCmy9Nh81+1JxTePwuoBGeaPyIPtDtgdR8yEJ3h
MGk3GUvJrprXbGJGERJcnnsNjTczjUzjjC7Dp4BHCdflrUzwifc+XQp9uhnFnhem
v0bY+93YtOsYHiOcZy4JyPvmtMdvbklul2ybd7vbsUoHHsLu1rg3WUFB8yLVG/M5
9h/rzL2PKngqAwnISE9Aa6atfR5K5oeKeLcn/SJBp/IiCN9aXpgTcvA+AWkEfrgj
sm/NkzYStkbwbwJvauQG
=9VeC
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: ban EAPI 1

[Jason Zaman]

On Wed, Jun 10, 2015 at 10:43:10PM +0200, Ulrich Mueller wrote:
> Hi,
> The number of EAPI 1 ebuilds in the Portage tree has decreased to
> a total of 60, corresponding to 0.16 %.
> 
> We briefly discussed in the QA team if we should demote EAPI 1 in
> layout.conf from "eapis-deprecated" to "eapis-banned". This would
> have the consequence that repoman would refuse to commit packages
> containing such ebuilds. AFAICS there would be no impact on users.
> 
> What do you think?
> 
> Ulrich

This would be great! Do we have a list somewhere of ebuilds that are
still EAPI1? and which of those have a newer version that is a higher
EAPI for the same keywords? IE how many of the EAPI1 ebuilds cant just
be dropped?

-- Jason

Re: [gentoo-dev] RFC: ban EAPI 1

[Patrice Clement]

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

Wednesday 10 Jun 2015 22:43:10, Ulrich Mueller wrote :
> Hi,
> The number of EAPI 1 ebuilds in the Portage tree has decreased to
> a total of 60, corresponding to 0.16 %.
> 
> We briefly discussed in the QA team if we should demote EAPI 1 in
> layout.conf from "eapis-deprecated" to "eapis-banned". This would
> have the consequence that repoman would refuse to commit packages
> containing such ebuilds. AFAICS there would be no impact on users.
> 
> What do you think?
> 
> Ulrich

Make it happen!

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

Re: [gentoo-dev] RFC: ban EAPI 1

[Alexis Ballier]

On Wed, 10 Jun 2015 22:43:10 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> Hi,
> The number of EAPI 1 ebuilds in the Portage tree has decreased to
> a total of 60, corresponding to 0.16 %.
> 
> We briefly discussed in the QA team if we should demote EAPI 1 in
> layout.conf from "eapis-deprecated" to "eapis-banned". This would
> have the consequence that repoman would refuse to commit packages
> containing such ebuilds. AFAICS there would be no impact on users.
> 
> What do you think?


are those 60 ebuilds best visible ones ?
better convert the last few remaining so that best visible one is not
eapi1 before banning it

my bet would be that those 60 ebuilds are from packages barely
maintained, and i doubt banning their eapi will improve that, rather
the contrary

Alexis.

Re: [gentoo-dev] RFC: ban EAPI 1

[Manuel Rüger]

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

On 11.06.2015 11:16, Alexis Ballier wrote:
> On Wed, 10 Jun 2015 22:43:10 +0200 Ulrich Mueller <ulm@gentoo.org>
> wrote:
> 
>> Hi, The number of EAPI 1 ebuilds in the Portage tree has
>> decreased to a total of 60, corresponding to 0.16 %.
>> 
>> We briefly discussed in the QA team if we should demote EAPI 1
>> in layout.conf from "eapis-deprecated" to "eapis-banned". This
>> would have the consequence that repoman would refuse to commit
>> packages containing such ebuilds. AFAICS there would be no impact
>> on users.
>> 
>> What do you think?
> 
> 
> are those 60 ebuilds best visible ones ? better convert the last
> few remaining so that best visible one is not eapi1 before banning
> it
> 
> my bet would be that those 60 ebuilds are from packages barely 
> maintained, and i doubt banning their eapi will improve that,
> rather the contrary
> 
> Alexis.
> 


Here's a list of all remaining ebuilds:
https://bpaste.net/show/dca95bc1e22b

There's also a tracking bug available:
https://bugs.gentoo.org/show_bug.cgi?id=512122

Cheers,

Manuel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJVeWtDXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcr9oP/A8zz9fR1T7ezZwpAzQyTRi2
DfRg9RVMOZUcmOkysFulgQ0kDXiYqXExJuakt7TjKyeLLS+0/I+jMlG8flsBK5/K
zvuYxncNhOBq1LRpEu9g9+XisH05EzQUksNNd9732eozbUbNjmHSO3d3oOmmr4qK
RHVYy5EM3MKHfQVrbjsMDjH/a51rARBYdh4u2Fao5lWYZbH8hsCdreHswI2C8VgQ
t+TMMW+KQMqG3cs30o/pcuoc/JckBstJ67R5qqmo0GCAfSaWLgOioPsCQKnhYt7J
bpo2khdx2O0ncUULmnEtQ1+V/LYzUdnXHU8QIKBEIhvmJKt+RLVKFAvQZ4h0CpPL
szKuxcomI5rHDq1kTWp+CLECVRbb8bQTpRvdWFo68qbDJnoUfyog+2h6wmrtRLVK
G1zeO9rlGhtqa1EAdnSwOwWOnIPnDP4sx5pev1A9GfVjz7/jdlCceZahJsVHS6xG
Iy+gnKqF2gAVXV2DWwbXTQsDoHGrfIwO0Tk3wU+03XBTishYBTsNmDpZYAWHNCaJ
fmq1nF3MvSiVBG5cCy7RcMgRADh2Qmc5TwyqSRH/O5XmQS3/q6BNlMr53ErCYD+I
UFYPhZ/dzlUDjfJ9W7Ibrh3gTzPmK6AJdKx9rMMuzxzhn4qcgC6aPGRUCPfzrKRk
9/hQW9JSVVbr1CE4YReN
=iC5/
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: ban EAPI 1

[Ulrich Mueller]

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

>>>>> On Thu, 11 Jun 2015, Jason Zaman wrote:

> This would be great! Do we have a list somewhere of ebuilds that are
> still EAPI1? and which of those have a newer version that is a
> higher EAPI for the same keywords? IE how many of the EAPI1 ebuilds
> cant just be dropped?

>>>>> On Thu, 11 Jun 2015, Alexis Ballier wrote:

> are those 60 ebuilds best visible ones ?
> better convert the last few remaining so that best visible one is
> not eapi1 before banning it

Here is the list, with the second column indicating if the ebuild in
question is the best version of its package (or of its slot).

    app-i18n/atokx2-17.0                    no
    app-i18n/atokx2-17.0-r2                 yes
    app-i18n/im-freewnn-0.0.2-r1            yes
    app-i18n/scim-input-pad-0.1.1           no
    app-i18n/x-unikey-1.0.4-r1              no
    dev-java/aspectwerkz-2.0_rc2-r3         no
    dev-java/bcmail-1.38-r3                 in slot
    dev-java/bsf-2.4.0-r1                   yes
    dev-java/burlap-3.0.8-r3                yes
    dev-java/caucho-services-3.0.8-r2       yes
    dev-java/commons-configuration-1.6      no
    dev-java/commons-configuration-1.6-r1   yes
    dev-java/commons-jxpath-1.3             no
    dev-java/commons-lang-2.6               in slot
    dev-java/commons-logging-1.1.1          no
    dev-java/commons-modeler-2.0.1          yes
    dev-java/dom4j-1.6.1-r3                 no
    dev-java/exolabcore-0.3.7_p20050205-r2  yes
    dev-java/hessian-3.0.8-r5               in slot
    dev-java/hessian-3.0.20                 in slot
    dev-java/hessian-3.1.6                  in slot
    dev-java/hessian-4.0.3                  yes
    dev-java/java-dep-check-0.3             yes
    dev-java/jaxb-2.1.2-r1                  yes
    dev-java/jaxb-tools-2.1.2               yes
    dev-java/jax-ws-tools-2.0.1-r1          yes
    dev-java/jcs-1.2.7.9-r1                 in slot
    dev-java/jcs-1.3-r1                     yes
    dev-java/jpf-1.5.1                      yes
    dev-java/jpfcodegen-0.4                 yes
    dev-java/jsr101-1.4-r1                  no
    dev-java/jython-2.2.1-r1                no
    dev-java/msv-20050627-r2                no
    dev-java/msv-20050627-r3                yes
    dev-java/mx4j-3.0.1-r4                  no
    dev-java/mx4j-tools-3.0.1-r2            no
    dev-java/mx4j-tools-3.0.2               yes
    dev-java/pdfbox-0.7.3-r3                in slot
    dev-java/poi-3.0.2-r1                   in slot
    dev-java/poi-3.2                        yes
    dev-java/rhino-1.7.2-r2                 yes
    dev-java/ws-commons-util-1.0.1          yes
    dev-java/wstx-3.2.8                     no
    dev-java/xalan-2.7.1                    yes
    dev-java/xmlgraphics-commons-1.3.1      in slot
    dev-java/xpp2-2.1.10-r1                 yes
    dev-java/xstream-1.3.1-r1               no
    dev-lang/ocaml-3.12.1                   in slot
    dev-scheme/gauche-gtk-0.4.1             no
    gpe-base/gpe-icons-0.25                 masked for removal
    gpe-base/libgpepimc-0.9                 masked for removal
    media-sound/audacious-2.4.4             no
    media-tv/xawtv-3.95-r2                  no
    net-ftp/gftp-2.0.19-r1                  no
    net-ftp/gproftpd-8.3.2                  no
    sci-biology/emboss-6.0.1                no
    x11-misc/matchbox-panel-manager-0.1     yes
    x11-misc/pathfinder-1.6.36              no
    x11-misc/shutterbug-1.6.36              no

This leaves us with 4 ebuilds outside of the dev-java category which
are the newest of their package or slot. Since chewi has acknowledged
it for dev-java, I have committed the change to layout.conf now.

> my bet would be that those 60 ebuilds are from packages barely
> maintained, and i doubt banning their eapi will improve that, rather
> the contrary

Maintainers can still use --force if there is no other way.

Ulrich

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

Re: [gentoo-dev] RFC: ban EAPI 1

[Mikle Kolyada]

10.06.2015 23:43, Ulrich Mueller пишет:
> Hi,
> The number of EAPI 1 ebuilds in the Portage tree has decreased to
> a total of 60, corresponding to 0.16 %.
>
> We briefly discussed in the QA team if we should demote EAPI 1 in
> layout.conf from "eapis-deprecated" to "eapis-banned". This would
> have the consequence that repoman would refuse to commit packages
> containing such ebuilds. AFAICS there would be no impact on users.
>
> What do you think?
>
> Ulrich

lets do it quick. :)

Re: [gentoo-dev] RFC: ban EAPI 1

[Alexis Ballier]

On Thu, 11 Jun 2015 13:13:18 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Thu, 11 Jun 2015, Jason Zaman wrote:

>     dev-lang/ocaml-3.12.1                   in slot

in subslot not slot, but more importantly in stable

> > my bet would be that those 60 ebuilds are from packages barely
> > maintained, and i doubt banning their eapi will improve that, rather
> > the contrary
> 
> Maintainers can still use --force if there is no other way.

i'm definitely not convinced it is good practice to encourage people to
do that ;)

also, it seems eapis-banned is not just about new ebuilds but also when
there happens to be an ancient ebuild in the same directory

Re: [gentoo-dev] RFC: ban EAPI 1

[Ulrich Mueller]

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

>>>>> On Thu, 11 Jun 2015, Alexis Ballier wrote:

>> dev-lang/ocaml-3.12.1                   in slot

> in subslot not slot, but more importantly in stable

Right, there are newer ebuilds in slot 0 for dev-lang/ocaml. I've
double-checked the list now; for all other packages the "in slot" was
accurate.

>> Maintainers can still use --force if there is no other way.

> i'm definitely not convinced it is good practice to encourage people
> to do that ;)

People are strongly encouraged to update their ebuilds to a newer
EAPI. ;) There are few EAPI 1 ebuilds left and the point is to prevent
adding new ones accidentally.

> also, it seems eapis-banned is not just about new ebuilds but also
> when there happens to be an ancient ebuild in the same directory

Yes, and that repoman behaves this way is the very reason why EAPIs
1 and 2 haven't been banned already one year ago. After all, this was
a council decision:
https://projects.gentoo.org/council/meeting-logs/20140225.txt

Ulrich

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

Re: [gentoo-dev] RFC: ban EAPI 1

[Alexis Ballier]

On Thu, 11 Jun 2015 18:33:36 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >> Maintainers can still use --force if there is no other way.
> 
> > i'm definitely not convinced it is good practice to encourage people
> > to do that ;)
> 
> People are strongly encouraged to update their ebuilds to a newer
> EAPI. ;) There are few EAPI 1 ebuilds left and the point is to prevent
> adding new ones accidentally.
> 
> > also, it seems eapis-banned is not just about new ebuilds but also
> > when there happens to be an ancient ebuild in the same directory
> 
> Yes, and that repoman behaves this way is the very reason why EAPIs
> 1 and 2 haven't been banned already one year ago. After all, this was
> a council decision:
> https://projects.gentoo.org/council/meeting-logs/20140225.txt


i agree, but what worries me is that you suddenly introduced repoman
errors for a bunch of packages for which there is no clear ETA on when
these can be fixed (i think qa policy is to not bump eapi in place)

this is not just about "fixing" a line in an ebuild, it is about proper
testing for stabilization and e.g. ocaml is definitely not a package
whose stabilization should be done lightly

Re: [gentoo-dev] RFC: ban EAPI 1

[Rich Freeman]

On Thu, Jun 11, 2015 at 12:55 PM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Thu, 11 Jun 2015 18:33:36 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
>
>> >> Maintainers can still use --force if there is no other way.
>>
>> > i'm definitely not convinced it is good practice to encourage people
>> > to do that ;)
>>
>> People are strongly encouraged to update their ebuilds to a newer
>> EAPI. ;) There are few EAPI 1 ebuilds left and the point is to prevent
>> adding new ones accidentally.
>>
>> > also, it seems eapis-banned is not just about new ebuilds but also
>> > when there happens to be an ancient ebuild in the same directory
>>
>> Yes, and that repoman behaves this way is the very reason why EAPIs
>> 1 and 2 haven't been banned already one year ago. After all, this was
>> a council decision:
>> https://projects.gentoo.org/council/meeting-logs/20140225.txt
>
>
> i agree, but what worries me is that you suddenly introduced repoman
> errors for a bunch of packages for which there is no clear ETA on when
> these can be fixed (i think qa policy is to not bump eapi in place)
>
> this is not just about "fixing" a line in an ebuild, it is about proper
> testing for stabilization and e.g. ocaml is definitely not a package
> whose stabilization should be done lightly
>

These errors are not user-visible. I really don't have a problem with
repoman errors for deprecated features.

We've been discouraging EAPI 1 for a while now.  This just raises the
volume a bit, while still not creating any hard problems during the
transition.

Sure, it would be nice if repoman only complained for new ebuilds,
since that is the policy, but honestly making noise about old ones is
probably useful, just so that we can keep their removal on the radar.

Also, EAPI 1 and 2 WERE banned by the Council.  Whether or not
repoman's settings were adjusted has nothing to do with the fact that
they were banned for new ebuilds.

-- 
Rich

Re: [gentoo-dev] RFC: ban EAPI 1

[Alexis Ballier]

On Thu, 11 Jun 2015 14:38:35 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> 
> These errors are not user-visible. I really don't have a problem with
> repoman errors for deprecated features.
> 

I don't have a problem with always using --force either. But then the
distinction between warnings and errors becomes much less clear.

Re: [gentoo-dev] RFC: ban EAPI 1

[Rich Freeman]

On Thu, Jun 11, 2015 at 3:12 PM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Thu, 11 Jun 2015 14:38:35 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>>
>> These errors are not user-visible. I really don't have a problem with
>> repoman errors for deprecated features.
>>
>
> I don't have a problem with always using --force either. But then the
> distinction between warnings and errors becomes much less clear.
>

In general I'd tend to agree, but we're talking about a very limited
pool of 70 packages, whose maintainers should always be aware of the
issue, and the number of affected packages should constantly decline.

If we were talking about something that wasn't on its way out I'd be
more concerned.

-- 
Rich

Re: [gentoo-dev] RFC: ban EAPI 1

[Michał Górny]

Dnia 2015-06-11, o godz. 21:12:00
Alexis Ballier <aballier@gentoo.org> napisał(a):

> On Thu, 11 Jun 2015 14:38:35 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
> > 
> > These errors are not user-visible. I really don't have a problem with
> > repoman errors for deprecated features.
> > 
> 
> I don't have a problem with always using --force either. But then the
> distinction between warnings and errors becomes much less clear.

Also --force disables expensive checks such as profile deptree checks.

--
Best regards,
Michał Górny

Re: [gentoo-dev] RFC: ban EAPI 1

[Alexis Ballier]

On Thu, 11 Jun 2015 15:15:42 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Thu, Jun 11, 2015 at 3:12 PM, Alexis Ballier <aballier@gentoo.org>
> wrote:
> > On Thu, 11 Jun 2015 14:38:35 -0400
> > Rich Freeman <rich0@gentoo.org> wrote:
> >>
> >> These errors are not user-visible. I really don't have a problem
> >> with repoman errors for deprecated features.
> >>
> >
> > I don't have a problem with always using --force either. But then
> > the distinction between warnings and errors becomes much less clear.
> >
> 
> In general I'd tend to agree, but we're talking about a very limited
> pool of 70 packages, whose maintainers should always be aware of the
> issue, and the number of affected packages should constantly decline.
> 
> If we were talking about something that wasn't on its way out I'd be
> more concerned.
> 

When will it be out?

From previous ocaml stabilizations, I'd say that I'll have to use
--force for at least two months before it can be removed. I might get
bored and alias --force :)

Re: [gentoo-dev] RFC: ban EAPI 1

[Ulrich Mueller]

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

>>>>> On Thu, 11 Jun 2015, Alexis Ballier wrote:

> On Thu, 11 Jun 2015 15:15:42 -0400
> Rich Freeman <rich0@gentoo.org> wrote:

>> In general I'd tend to agree, but we're talking about a very
>> limited pool of 70 packages,

49 packages with 58 ebuilds, to be precise.

>> whose maintainers should always be aware of the issue, and the
>> number of affected packages should constantly decline.
>> 
>> If we were talking about something that wasn't on its way out I'd
>> be more concerned.

+1

> When will it be out?

>> From previous ocaml stabilizations, I'd say that I'll have to use
> --force for at least two months before it can be removed. I might
> get bored and alias --force :)

Unless the commit rate in dev-lang/ocaml (which was a total of five
commits during last year) would raise by at least an order of
magnitude, I'd say that it's not much of a hardship.

But if you insist, feel free to revert my change to layout.conf until
newer ocaml is stable.

Ulrich

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

Re: [gentoo-dev] RFC: ban EAPI 1

[Alexis Ballier]

On Thu, 11 Jun 2015 21:55:14 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> >> From previous ocaml stabilizations, I'd say that I'll have to use
> > --force for at least two months before it can be removed. I might
> > get bored and alias --force :)
> 
> Unless the commit rate in dev-lang/ocaml (which was a total of five
> commits during last year) would raise by at least an order of
> magnitude, I'd say that it's not much of a hardship.

(this depends on upstream release rate mostly)

> But if you insist, feel free to revert my change to layout.conf until
> newer ocaml is stable.

Nah, may the --force be with you :)

However, I always saw repoman errors as 'must be fixed before
committing'; but in this case, any fix (removal or in place eapi
change) is worse than the error itself; that's why I insisted in getting
things fixed beforehand. I guess repoman errors are not that important
after all.