Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change (v4)
> On Thu, 11 Jan 2018, Aaron W Swenson wrote: > 2018-01-11-GnuCash-Breaking-Change.en.txt Since its last update, GLEP 42 strongly recommends using a very short name, with at most 20 characters for the short-name identifier [1] (whose main purpose is to keep the name unique if more than one news item is posted on the same day). Also, the git hook will reject names containing uppercase chars. So, could you use something like 2018-01-11-gnucash.en.txt for the name? Ulrich [1] https://www.gentoo.org/glep/glep-0042.html#news-item-identities pgpcnnEN9rlqC.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH v3] profiles.desc: Lower some profiles with broken depgraph from dev to exp
On 1/11/18 4:47 PM, Michał Górny wrote: > > I withdraw this since everyone obviously has his special workflow and we > can't touch anything. Now the CI report is 3.5M large and lists over 900 > broken packages. Please start looking into fixing your profiles. Thank > you. > Now that you explained the issue to me on IRC, I'm going to work towards restructuring the uclibc and musl profiles so that they inherit in a manner similar to hardened. I suspect this will clear out a lot of the issues reported at [1]. It should also give those profiles more longevity. Its a fair bit of work, so I'll ask for some patience. [1] https://qa-reports.gentoo.org/output/gentoo-ci/output.html -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change (v4)
Revision number 4. Title: GnuCash 2.7+ Breaking Change Author: Aaron W. Swenson Posted: 2018-01-11 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: gnucash-2.6.sql.xz For PostgreSQL: $ pg_dump -U gnucash_user -Z 5 gnucash_db > gnucash-2.6.sql.gz For SQLite: $ cp /path/to/sqlite.file.gnucash /path/to/sqlite.file.gnucash.bak [1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a Title: GnuCash 2.7+ Breaking Change Author: Aaron W. Swenson Posted: 2018-01-11 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: gnucash-2.6.sql.xz For PostgreSQL: $ pg_dump -U gnucash_user -Z 5 gnucash_db > gnucash-2.6.sql.gz For SQLite: $ cp /path/to/sqlite.file.gnucash /path/to/sqlite.file.gnucash.bak [1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH v3] profiles.desc: Lower some profiles with broken depgraph from dev to exp
W dniu czw, 11.01.2018 o godzinie 21∶40 +0100, użytkownik Michał Górny napisał: > --- > profiles/profiles.desc | 80 > +- > 1 file changed, 40 insertions(+), 40 deletions(-) > > diff --git a/profiles/profiles.desc b/profiles/profiles.desc > index 4e3223a76b14..13cb5d0922c0 100644 > --- a/profiles/profiles.desc > +++ b/profiles/profiles.desc > @@ -29,7 +29,7 @@ amd64 > default/linux/amd64/13.0/desktop/plasma/systemd stable > amd64 default/linux/amd64/13.0/developer > stable > amd64 default/linux/amd64/13.0/no-multilib > stable > amd64 default/linux/amd64/13.0/systemd > stable > -amd64 default/linux/amd64/13.0/x32dev > +amd64 default/linux/amd64/13.0/x32exp > amd64 default/linux/amd64/17.0 > stable > amd64 default/linux/amd64/17.0/selinuxdev > amd64 default/linux/amd64/17.0/hardened dev > @@ -44,7 +44,7 @@ amd64 default/linux/amd64/17.0/no-multilib > stable > amd64 default/linux/amd64/17.0/no-multilib/hardened dev > amd64 default/linux/amd64/17.0/no-multilib/hardened/selinux dev > amd64 default/linux/amd64/17.0/systemd > stable > -amd64 default/linux/amd64/17.0/x32dev > +amd64 default/linux/amd64/17.0/x32exp > > # Experimental SYMLINK_LIB=no profiles > # Run app-portage/unsymlink-lib *before* switching the profile. > @@ -240,22 +240,22 @@ x86 default/linux/x86/17.0/developer > stable > x86 default/linux/x86/17.0/systemd stable > > # Gentoo/FreeBSD Profiles > -amd64-fbsd default/bsd/fbsd/amd64/9.1 dev > -amd64-fbsd default/bsd/fbsd/amd64/11.1 dev > +amd64-fbsd default/bsd/fbsd/amd64/9.1 exp > +amd64-fbsd default/bsd/fbsd/amd64/11.1 exp > amd64-fbsd default/bsd/fbsd/amd64/9.1/clangexp > amd64-fbsd default/bsd/fbsd/amd64/11.1/clang exp > sparc-fbsd default/bsd/fbsd/sparc/8.2 exp > -x86-fbsd default/bsd/fbsd/x86/9.1dev > -x86-fbsd default/bsd/fbsd/x86/11.1 dev > +x86-fbsd default/bsd/fbsd/x86/9.1exp > +x86-fbsd default/bsd/fbsd/x86/11.1 exp > > # Hardened Profiles > amd64hardened/linux/amd64 > stable > amd64hardened/linux/amd64/selinux > stable > amd64hardened/linux/amd64/no-multilib > stable > amd64hardened/linux/amd64/no-multilib/selinux > stable > -amd64hardened/linux/amd64/x32 > dev > -arm hardened/linux/arm/armv7a dev > -arm hardened/linux/arm/armv6j dev > +amd64hardened/linux/amd64/x32 > exp > +arm hardened/linux/arm/armv7a exp > +arm hardened/linux/arm/armv6j exp > ia64 hardened/linux/ia64 dev > mips hardened/linux/mips/mipsel/multilib/n32 exp > mips hardened/linux/mips/mipsel/multilib/n64 exp > @@ -266,8 +266,8 @@ mips hardened/linux/mips/multilib/n64 > exp > mips hardened/linux/mips/n32 exp > mips hardened/linux/mips/n64 exp > ppc hardened/linux/powerpc/ppc32dev > -ppc hardened/linux/powerpc/ppc64/32bit-userland dev > -ppc64hardened/linux/powerpc/ppc64/64bit-userland > dev > +ppc hardened/linux/powerpc/ppc64/32bit-userland exp > +ppc64hardened/linux/powerpc/ppc64/64bit-userland > exp > x86 hardened/linux/x86 stable > x86 hardened/linux/x86/selinux stable > > @@ -290,37 +290,37 @@ x86 default/linux/musl/x86 > exp > x86 hardened/linux/musl/x86 exp > > # Non-embedded uclibc profiles > -amd64default/linux/uclibc/amd64 > dev > -amd64hardened/linux/uclibc/amd64
Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change (v3)
On 2018-01-11 19:02, Francesco Riosa wrote: > It could be wise to close GnuCash before backup Good point. Added a line. > also the choice of creating a copy of the database is a bit unusual, > an offline backup may be more appropriated, example for mysql: > mysqldump gnucash_db | xz > gnucash-2.6.sql.xz I thought it’d be nice to have the backup online, but this is probably better. I’ve change the PostgreSQL command as well. > It's ok to leave restore instruction out, since those are usually easy to > find and spending more time with it does not hurt I’m glad we agree. Thanks! signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH v2] profiles.desc: Lower profiles with broken depgraph from dev to exp
On 1/11/18 2:45 PM, Michał Górny wrote: > Lower those of dev profiles that currently have broken depgraph to exp > status. This will allow us to enable CI runs for dev profiles without > triggering new issues, and start actively pursing improving exp > profiles to dev one by one. > --- > profiles/profiles.desc | 104 > - > 1 file changed, 52 insertions(+), 52 deletions(-) > > diff --git a/profiles/profiles.desc b/profiles/profiles.desc > index 4e3223a76b14..d9bcb8b60e8b 100644 > --- a/profiles/profiles.desc > +++ b/profiles/profiles.desc > @@ -29,7 +29,7 @@ amd64 > default/linux/amd64/13.0/desktop/plasma/systemd stable > amd64 default/linux/amd64/13.0/developer > stable > amd64 default/linux/amd64/13.0/no-multilib > stable > amd64 default/linux/amd64/13.0/systemd > stable > -amd64 default/linux/amd64/13.0/x32dev > +amd64 default/linux/amd64/13.0/x32exp > amd64 default/linux/amd64/17.0 > stable > amd64 default/linux/amd64/17.0/selinuxdev > amd64 default/linux/amd64/17.0/hardened dev > @@ -44,7 +44,7 @@ amd64 default/linux/amd64/17.0/no-multilib > stable > amd64 default/linux/amd64/17.0/no-multilib/hardened dev > amd64 default/linux/amd64/17.0/no-multilib/hardened/selinux dev > amd64 default/linux/amd64/17.0/systemd > stable > -amd64 default/linux/amd64/17.0/x32dev > +amd64 default/linux/amd64/17.0/x32exp > > # Experimental SYMLINK_LIB=no profiles > # Run app-portage/unsymlink-lib *before* switching the profile. > @@ -90,14 +90,14 @@ arm > default/linux/arm/13.0/armv7a/desktop/gnome dev > arm default/linux/arm/13.0/armv7a/developer dev > > # ARM64 Profiles > -arm64 default/linux/arm64/13.0dev > +arm64 default/linux/arm64/13.0exp > arm64 default/linux/arm64/13.0/desktopexp > -arm64 default/linux/arm64/13.0/desktop/systemddev > +arm64 default/linux/arm64/13.0/desktop/systemdexp > arm64 default/linux/arm64/13.0/developer exp > arm64 default/linux/arm64/13.0/systemdexp > -arm64 default/linux/arm64/17.0dev > +arm64 default/linux/arm64/17.0exp > arm64 default/linux/arm64/17.0/desktopexp > -arm64 default/linux/arm64/17.0/desktop/systemddev > +arm64 default/linux/arm64/17.0/desktop/systemdexp > arm64 default/linux/arm64/17.0/developer exp > arm64 default/linux/arm64/17.0/systemdexp > > @@ -132,17 +132,17 @@ m68kdefault/linux/m68k/17.0/desktop/gnome > exp > m68kdefault/linux/m68k/17.0/developer exp > > # MIPS Profiles > -mipsdefault/linux/mips/13.0/o32 dev > -mipsdefault/linux/mips/13.0/n32 dev > +mipsdefault/linux/mips/13.0/o32 exp > +mipsdefault/linux/mips/13.0/n32 exp > mipsdefault/linux/mips/13.0/n64 exp > -mipsdefault/linux/mips/13.0/multilib/o32dev > -mipsdefault/linux/mips/13.0/multilib/n32dev > +mipsdefault/linux/mips/13.0/multilib/o32exp > +mipsdefault/linux/mips/13.0/multilib/n32exp > mipsdefault/linux/mips/13.0/multilib/n64exp > -mipsdefault/linux/mips/13.0/mipsel/o32 dev > -mipsdefault/linux/mips/13.0/mipsel/n32 dev > +mipsdefault/linux/mips/13.0/mipsel/o32 exp > +mipsdefault/linux/mips/13.0/mipsel/n32 exp > mipsdefault/linux/mips/13.0/mipsel/n64 exp > -mipsdefault/linux/mips/13.0/mipsel/multilib/o32 dev > -mipsdefault/linux/mips/13.0/mipsel/multilib/n32 dev > +mipsdefault/linux/mips/13.0/mipsel/multilib/o32 exp > +mipsdefault/linux/mips/13.0/mipsel/multilib/n32 exp > mipsdefault/linux/mips/13.0/mipsel/multilib/n64 exp > > # Nios II Profiles > @@ -240,22 +240,22 @@ x86 default/linux/x86/17.0/developer > stable > x86 default/linux/x86/17.0/systemd stable > > # Gentoo/FreeBSD Profiles > -amd6
Re: [gentoo-dev] [PATCH v2] profiles.desc: Lower profiles with broken depgraph from dev to exp
On Thu, 2018-01-11 at 21:35 +0100, Michał Górny wrote: > The point of dev is to bring staging warnings so that we can improve > the depgraph. If you really insist, we can start with dev status for > arm64 & mips. But it'd be more readable if we worked on only one arch > simultaneously. Keep 17.0 ones that were dev as dev then for arm64; 13.0 can all go to exp. The latest arm64 stage3 is 17.0 already. For all of those musl profiles should be fixed by their maintainer (which isn't the arch team). It generates all that noise and it's the main reason I had to do a separation of exp and dev for arm64 and mips, so I can have any sort of readable repoman output whatsoever. Albeit speed helps as well by only checking a subset of all arch profiles, especially for mips. mips we can move a couple back to dev once I revive the glibc on it and can actually do work on it again, but it's lower priority. Meanwhile mips "repoman -e y --include-arches mips" output is useless with musl, unless doing some creative grep -v'ing...
[gentoo-dev] [PATCH v3] profiles.desc: Lower some profiles with broken depgraph from dev to exp
--- profiles/profiles.desc | 80 +- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/profiles/profiles.desc b/profiles/profiles.desc index 4e3223a76b14..13cb5d0922c0 100644 --- a/profiles/profiles.desc +++ b/profiles/profiles.desc @@ -29,7 +29,7 @@ amd64 default/linux/amd64/13.0/desktop/plasma/systemd stable amd64 default/linux/amd64/13.0/developer stable amd64 default/linux/amd64/13.0/no-multilibstable amd64 default/linux/amd64/13.0/systemdstable -amd64 default/linux/amd64/13.0/x32dev +amd64 default/linux/amd64/13.0/x32exp amd64 default/linux/amd64/17.0stable amd64 default/linux/amd64/17.0/selinuxdev amd64 default/linux/amd64/17.0/hardened dev @@ -44,7 +44,7 @@ amd64 default/linux/amd64/17.0/no-multilib stable amd64 default/linux/amd64/17.0/no-multilib/hardened dev amd64 default/linux/amd64/17.0/no-multilib/hardened/selinux dev amd64 default/linux/amd64/17.0/systemdstable -amd64 default/linux/amd64/17.0/x32dev +amd64 default/linux/amd64/17.0/x32exp # Experimental SYMLINK_LIB=no profiles # Run app-portage/unsymlink-lib *before* switching the profile. @@ -240,22 +240,22 @@ x86 default/linux/x86/17.0/developer stable x86default/linux/x86/17.0/systemd stable # Gentoo/FreeBSD Profiles -amd64-fbsd default/bsd/fbsd/amd64/9.1 dev -amd64-fbsd default/bsd/fbsd/amd64/11.1 dev +amd64-fbsd default/bsd/fbsd/amd64/9.1 exp +amd64-fbsd default/bsd/fbsd/amd64/11.1 exp amd64-fbsd default/bsd/fbsd/amd64/9.1/clangexp amd64-fbsd default/bsd/fbsd/amd64/11.1/clang exp sparc-fbsd default/bsd/fbsd/sparc/8.2 exp -x86-fbsd default/bsd/fbsd/x86/9.1dev -x86-fbsd default/bsd/fbsd/x86/11.1 dev +x86-fbsd default/bsd/fbsd/x86/9.1exp +x86-fbsd default/bsd/fbsd/x86/11.1 exp # Hardened Profiles amd64 hardened/linux/amd64stable amd64 hardened/linux/amd64/selinuxstable amd64 hardened/linux/amd64/no-multilibstable amd64 hardened/linux/amd64/no-multilib/selinuxstable -amd64 hardened/linux/amd64/x32dev -armhardened/linux/arm/armv7a dev -armhardened/linux/arm/armv6j dev +amd64 hardened/linux/amd64/x32exp +armhardened/linux/arm/armv7a exp +armhardened/linux/arm/armv6j exp ia64 hardened/linux/ia64 dev mips hardened/linux/mips/mipsel/multilib/n32 exp mips hardened/linux/mips/mipsel/multilib/n64 exp @@ -266,8 +266,8 @@ mipshardened/linux/mips/multilib/n64 exp mips hardened/linux/mips/n32 exp mips hardened/linux/mips/n64 exp ppchardened/linux/powerpc/ppc32dev -ppchardened/linux/powerpc/ppc64/32bit-userland dev -ppc64 hardened/linux/powerpc/ppc64/64bit-userland dev +ppchardened/linux/powerpc/ppc64/32bit-userland exp +ppc64 hardened/linux/powerpc/ppc64/64bit-userland exp x86hardened/linux/x86 stable x86hardened/linux/x86/selinux stable @@ -290,37 +290,37 @@ x86 default/linux/musl/x86 exp x86hardened/linux/musl/x86 exp # Non-embedded uclibc profiles -amd64 default/linux/uclibc/amd64 dev -amd64 hardened/linux/uclibc/amd64 dev -armdefault/linux/uclibc/arm/armv7a dev -armhardened/linux/uclibc/arm/armv7adev -mips default/linux/uclibc/mips dev -mips hardened/linux/ucli
Re: [gentoo-dev] [PATCH v2] profiles.desc: Lower profiles with broken depgraph from dev to exp
W dniu czw, 11.01.2018 o godzinie 22∶30 +0200, użytkownik Mart Raudsepp napisał: > On Thu, 2018-01-11 at 21:27 +0100, Michał Górny wrote: > > W dniu czw, 11.01.2018 o godzinie 22∶17 +0200, użytkownik Mart > > Raudsepp > > napisał: > > > On Thu, 2018-01-11 at 20:45 +0100, Michał Górny wrote: > > > > # ARM64 Profiles > > > > -arm64 default/linux/arm64/13.0 > > > > dev > > > > +arm64 default/linux/arm64/13.0 > > > > exp > > > > arm64 default/linux/arm64/13.0/desktop > > > > exp > > > > -arm64 default/linux/arm64/13.0/desktop/systemd > > > > dev > > > > +arm64 default/linux/arm64/13.0/desktop/systemd > > > > exp > > > > arm64 default/linux/arm64/13.0/developer > > > > exp > > > > arm64 default/linux/arm64/13.0/systemd > > > > exp > > > > -arm64 default/linux/arm64/17.0 > > > > dev > > > > +arm64 default/linux/arm64/17.0 > > > > exp > > > > arm64 default/linux/arm64/17.0/desktop > > > > exp > > > > -arm64 default/linux/arm64/17.0/desktop/systemd > > > > dev > > > > +arm64 default/linux/arm64/17.0/desktop/systemd > > > > exp > > > > arm64 default/linux/arm64/17.0/developer > > > > exp > > > > arm64 default/linux/arm64/17.0/systemd > > > > exp > > > > > > With this I'll need to run through all of these profiles with > > > repoman -e=y and wait a long time, instead of just the two (well, > > > with > > > 17.0 now 4) profiles that I actually care about and checks enough. > > > I > > > also will see a TON of issues from the musl profiles down below > > > that > > > main block (it doesn't inherit base or something). > > > > > > This would make arm64 work completely impossible, so NAK from me. > > > > repoman has --include-arches option for a reason. Profile statuses > > are > > not your private convenience. > > That doesn't help whatsoever due to musl. Also not for running things > on a slower arch (mips in this case). > > > > Additionally if depgraph wouldn't be broken anymore, we would be > > > moving > > > them to stable, not some separate "dev" step. > > > > > > Same goes for the mips main block changes. > > > > But it is broken, and it won't become less broken if we keep ignoring > > the fact and not reporting new breakages just because one developer > > can't fix his workflow. > > Your patch simply removes dev completely, with no reason for it to > exist anymore then. If depgraph isn't broken, it'd be stable. There'd > be no reason for dev. Dev is dev BECAUSE it has a broken depgraph, but > is aspiring towards not. > My workflow is just fine. > The point of dev is to bring staging warnings so that we can improve the depgraph. If you really insist, we can start with dev status for arm64 & mips. But it'd be more readable if we worked on only one arch simultaneously. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH v2] profiles.desc: Lower profiles with broken depgraph from dev to exp
On Thu, 2018-01-11 at 21:27 +0100, Michał Górny wrote: > W dniu czw, 11.01.2018 o godzinie 22∶17 +0200, użytkownik Mart > Raudsepp > napisał: > > On Thu, 2018-01-11 at 20:45 +0100, Michał Górny wrote: > > > # ARM64 Profiles > > > -arm64 default/linux/arm64/13.0 > > > dev > > > +arm64 default/linux/arm64/13.0 > > > exp > > > arm64 default/linux/arm64/13.0/desktop > > > exp > > > -arm64 default/linux/arm64/13.0/desktop/systemd > > > dev > > > +arm64 default/linux/arm64/13.0/desktop/systemd > > > exp > > > arm64 default/linux/arm64/13.0/developer > > > exp > > > arm64 default/linux/arm64/13.0/systemd > > > exp > > > -arm64 default/linux/arm64/17.0 > > > dev > > > +arm64 default/linux/arm64/17.0 > > > exp > > > arm64 default/linux/arm64/17.0/desktop > > > exp > > > -arm64 default/linux/arm64/17.0/desktop/systemd > > > dev > > > +arm64 default/linux/arm64/17.0/desktop/systemd > > > exp > > > arm64 default/linux/arm64/17.0/developer > > > exp > > > arm64 default/linux/arm64/17.0/systemd > > > exp > > > > With this I'll need to run through all of these profiles with > > repoman -e=y and wait a long time, instead of just the two (well, > > with > > 17.0 now 4) profiles that I actually care about and checks enough. > > I > > also will see a TON of issues from the musl profiles down below > > that > > main block (it doesn't inherit base or something). > > > > This would make arm64 work completely impossible, so NAK from me. > > repoman has --include-arches option for a reason. Profile statuses > are > not your private convenience. That doesn't help whatsoever due to musl. Also not for running things on a slower arch (mips in this case). > > Additionally if depgraph wouldn't be broken anymore, we would be > > moving > > them to stable, not some separate "dev" step. > > > > Same goes for the mips main block changes. > > But it is broken, and it won't become less broken if we keep ignoring > the fact and not reporting new breakages just because one developer > can't fix his workflow. Your patch simply removes dev completely, with no reason for it to exist anymore then. If depgraph isn't broken, it'd be stable. There'd be no reason for dev. Dev is dev BECAUSE it has a broken depgraph, but is aspiring towards not. My workflow is just fine.
Re: [gentoo-dev] [PATCH v2] profiles.desc: Lower profiles with broken depgraph from dev to exp
On Thu, 2018-01-11 at 22:17 +0200, Mart Raudsepp wrote: > On Thu, 2018-01-11 at 20:45 +0100, Michał Górny wrote: > > # ARM64 Profiles > > -arm64 default/linux/arm64/13.0 > > dev > > +arm64 default/linux/arm64/13.0 > > exp > > arm64 default/linux/arm64/13.0/desktop > > exp > > -arm64 default/linux/arm64/13.0/desktop/systemd > > dev > > +arm64 default/linux/arm64/13.0/desktop/systemd > > exp > > arm64 default/linux/arm64/13.0/developer > > exp > > arm64 default/linux/arm64/13.0/systemd > > exp > > -arm64 default/linux/arm64/17.0 > > dev > > +arm64 default/linux/arm64/17.0 > > exp > > arm64 default/linux/arm64/17.0/desktop > > exp > > -arm64 default/linux/arm64/17.0/desktop/systemd > > dev > > +arm64 default/linux/arm64/17.0/desktop/systemd > > exp > > arm64 default/linux/arm64/17.0/developer > > exp > > arm64 default/linux/arm64/17.0/systemd > > exp > > With this I'll need to run through all of these profiles with > repoman -e=y and wait a long time, instead of just the two (well, > with > 17.0 now 4) profiles that I actually care about and checks enough. I > also will see a TON of issues from the musl profiles down below that > main block (it doesn't inherit base or something). To clarify, they don't inherit from profiles/arch/, so all the package.use.stable.mask, package.use.mask, use.mask and other stuff is broken, which I've fixed in main thing, so repoman -e y is still impossibly noisy, even with --include-arches arm64, despite my fixes in the proper place. > This would make arm64 work completely impossible, so NAK from me. > > Additionally if depgraph wouldn't be broken anymore, we would be > moving > them to stable, not some separate "dev" step. > > Same goes for the mips main block changes.
Re: [gentoo-dev] [PATCH v2] profiles.desc: Lower profiles with broken depgraph from dev to exp
W dniu czw, 11.01.2018 o godzinie 22∶17 +0200, użytkownik Mart Raudsepp napisał: > On Thu, 2018-01-11 at 20:45 +0100, Michał Górny wrote: > > # ARM64 Profiles > > -arm64 default/linux/arm64/13.0dev > > +arm64 default/linux/arm64/13.0exp > > arm64 default/linux/arm64/13.0/desktopexp > > -arm64 default/linux/arm64/13.0/desktop/systemddev > > +arm64 default/linux/arm64/13.0/desktop/systemdexp > > arm64 default/linux/arm64/13.0/developer exp > > arm64 default/linux/arm64/13.0/systemdexp > > -arm64 default/linux/arm64/17.0dev > > +arm64 default/linux/arm64/17.0exp > > arm64 default/linux/arm64/17.0/desktopexp > > -arm64 default/linux/arm64/17.0/desktop/systemddev > > +arm64 default/linux/arm64/17.0/desktop/systemdexp > > arm64 default/linux/arm64/17.0/developer exp > > arm64 default/linux/arm64/17.0/systemdexp > > With this I'll need to run through all of these profiles with > repoman -e=y and wait a long time, instead of just the two (well, with > 17.0 now 4) profiles that I actually care about and checks enough. I > also will see a TON of issues from the musl profiles down below that > main block (it doesn't inherit base or something). > > This would make arm64 work completely impossible, so NAK from me. repoman has --include-arches option for a reason. Profile statuses are not your private convenience. > Additionally if depgraph wouldn't be broken anymore, we would be moving > them to stable, not some separate "dev" step. > > Same goes for the mips main block changes. But it is broken, and it won't become less broken if we keep ignoring the fact and not reporting new breakages just because one developer can't fix his workflow. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH v2] profiles.desc: Lower profiles with broken depgraph from dev to exp
On Thu, 2018-01-11 at 20:45 +0100, Michał Górny wrote: > # ARM64 Profiles > -arm64 default/linux/arm64/13.0 dev > +arm64 default/linux/arm64/13.0 exp > arm64 default/linux/arm64/13.0/desktop exp > -arm64 default/linux/arm64/13.0/desktop/systemd dev > +arm64 default/linux/arm64/13.0/desktop/systemd exp > arm64 default/linux/arm64/13.0/developer exp > arm64 default/linux/arm64/13.0/systemd exp > -arm64 default/linux/arm64/17.0 dev > +arm64 default/linux/arm64/17.0 exp > arm64 default/linux/arm64/17.0/desktop exp > -arm64 default/linux/arm64/17.0/desktop/systemd dev > +arm64 default/linux/arm64/17.0/desktop/systemd exp > arm64 default/linux/arm64/17.0/developer exp > arm64 default/linux/arm64/17.0/systemd exp With this I'll need to run through all of these profiles with repoman -e=y and wait a long time, instead of just the two (well, with 17.0 now 4) profiles that I actually care about and checks enough. I also will see a TON of issues from the musl profiles down below that main block (it doesn't inherit base or something). This would make arm64 work completely impossible, so NAK from me. Additionally if depgraph wouldn't be broken anymore, we would be moving them to stable, not some separate "dev" step. Same goes for the mips main block changes. Mart
Re: [gentoo-dev] Re: [gentoo-dev-announce] Upcoming posting restrictions on the gentoo-dev mailing list
On Thu, Jan 11, 2018 at 12:22:17PM +0900, Benda Xu wrote: > Hi, > > "Andreas K. Huettel" writes: > > > If, as a non-developer, you want to participate in a discussion on > > gentoo-dev, > > - either reply directly to the author of a list mail and ask him/her to > > forward your message, > > With this item in mind, shall we set the default "Reply-To:" to the > author instead of the list? +1 Technically, lists should never mess with the reply-to header since the author of the email should set it. I have said multiple times that we should stopp munging reply-to on all of our lists, and the IETF has defined reply-to as a field the author should set. William signature.asc Description: Digital signature
[gentoo-dev] [PATCH v2] profiles.desc: Lower profiles with broken depgraph from dev to exp
Lower those of dev profiles that currently have broken depgraph to exp status. This will allow us to enable CI runs for dev profiles without triggering new issues, and start actively pursing improving exp profiles to dev one by one. --- profiles/profiles.desc | 104 - 1 file changed, 52 insertions(+), 52 deletions(-) diff --git a/profiles/profiles.desc b/profiles/profiles.desc index 4e3223a76b14..d9bcb8b60e8b 100644 --- a/profiles/profiles.desc +++ b/profiles/profiles.desc @@ -29,7 +29,7 @@ amd64 default/linux/amd64/13.0/desktop/plasma/systemd stable amd64 default/linux/amd64/13.0/developer stable amd64 default/linux/amd64/13.0/no-multilibstable amd64 default/linux/amd64/13.0/systemdstable -amd64 default/linux/amd64/13.0/x32dev +amd64 default/linux/amd64/13.0/x32exp amd64 default/linux/amd64/17.0stable amd64 default/linux/amd64/17.0/selinuxdev amd64 default/linux/amd64/17.0/hardened dev @@ -44,7 +44,7 @@ amd64 default/linux/amd64/17.0/no-multilib stable amd64 default/linux/amd64/17.0/no-multilib/hardened dev amd64 default/linux/amd64/17.0/no-multilib/hardened/selinux dev amd64 default/linux/amd64/17.0/systemdstable -amd64 default/linux/amd64/17.0/x32dev +amd64 default/linux/amd64/17.0/x32exp # Experimental SYMLINK_LIB=no profiles # Run app-portage/unsymlink-lib *before* switching the profile. @@ -90,14 +90,14 @@ arm default/linux/arm/13.0/armv7a/desktop/gnome dev arm default/linux/arm/13.0/armv7a/developer dev # ARM64 Profiles -arm64 default/linux/arm64/13.0dev +arm64 default/linux/arm64/13.0exp arm64 default/linux/arm64/13.0/desktopexp -arm64 default/linux/arm64/13.0/desktop/systemddev +arm64 default/linux/arm64/13.0/desktop/systemdexp arm64 default/linux/arm64/13.0/developer exp arm64 default/linux/arm64/13.0/systemdexp -arm64 default/linux/arm64/17.0dev +arm64 default/linux/arm64/17.0exp arm64 default/linux/arm64/17.0/desktopexp -arm64 default/linux/arm64/17.0/desktop/systemddev +arm64 default/linux/arm64/17.0/desktop/systemdexp arm64 default/linux/arm64/17.0/developer exp arm64 default/linux/arm64/17.0/systemdexp @@ -132,17 +132,17 @@ m68kdefault/linux/m68k/17.0/desktop/gnome exp m68kdefault/linux/m68k/17.0/developer exp # MIPS Profiles -mipsdefault/linux/mips/13.0/o32 dev -mipsdefault/linux/mips/13.0/n32 dev +mipsdefault/linux/mips/13.0/o32 exp +mipsdefault/linux/mips/13.0/n32 exp mipsdefault/linux/mips/13.0/n64 exp -mipsdefault/linux/mips/13.0/multilib/o32dev -mipsdefault/linux/mips/13.0/multilib/n32dev +mipsdefault/linux/mips/13.0/multilib/o32exp +mipsdefault/linux/mips/13.0/multilib/n32exp mipsdefault/linux/mips/13.0/multilib/n64exp -mipsdefault/linux/mips/13.0/mipsel/o32 dev -mipsdefault/linux/mips/13.0/mipsel/n32 dev +mipsdefault/linux/mips/13.0/mipsel/o32 exp +mipsdefault/linux/mips/13.0/mipsel/n32 exp mipsdefault/linux/mips/13.0/mipsel/n64 exp -mipsdefault/linux/mips/13.0/mipsel/multilib/o32 dev -mipsdefault/linux/mips/13.0/mipsel/multilib/n32 dev +mipsdefault/linux/mips/13.0/mipsel/multilib/o32 exp +mipsdefault/linux/mips/13.0/mipsel/multilib/n32 exp mipsdefault/linux/mips/13.0/mipsel/multilib/n64 exp # Nios II Profiles @@ -240,22 +240,22 @@ x86 default/linux/x86/17.0/developer stable x86default/linux/x86/17.0/systemd stable # Gentoo/FreeBSD Profiles -amd64-fbsd default/bsd/fbsd/amd64/9.1 dev -amd64-fbsd default/bsd/fbsd/amd64/11.1 dev +amd64-fbsd default/bsd/fbsd/amd64/9.1 exp +amd64-fbsd default/bsd
Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change (v3)
2018-01-11 17:27 GMT+01:00 Aaron W. Swenson : > This time with a version constrain that should allow this to expire at > some point in the future. > > Title: GnuCash 2.7+ Breaking Change > Author: Aaron W. Swenson > Posted: 2018-01-11 > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: > Along with changes to use modern libraries, GnuCash 2.7+ has changed the > schema [1] it uses for both databases and files. GnuCash will > automatically modify the file or database in place upon open. > > Therefore, it is imperative that you back up any files or databases > before using GnuCash 2.7 in case you run into an issue and want or need > to revert back to 2.6. > > Instructions for backing up are as follows: > > For XML (plain files): > $ cp /path/to/file.gnucash /path/to/file.gnucash.bak > > For MySQL: > $ mysqldump gnucash_db | mysql gnucash_db_bak > > For PostgreSQL: > $ createdb -U dbadmin -T gnucash_db -O gnucash_user gnucash_db_bak > > For SQLite: > $ cp /path/to/gnucash/sqlite.file.gnucash /path/to/gnucash/sqlite.file. > gnucash.bak > > [1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a > It could be wise to close GnuCash before backup, also the choice of creating a copy of the database is a bit unusual, an offline backup may be more appropriated, example for mysql: mysqldump gnucash_db | xz > gnucash-2.6.sql.xz It's ok to leave restore instruction out, since those are usually easy to find and spending more time with it does not hurt
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On Thu, Jan 11, 2018, at 11:34 CST, Rich Freeman wrote: > It is kind of hard to get new people interested in fixing bugs when > half the traffic is complaining because the people doing the work > aren't doing it in a way that makes the people not doing the work feel > important. ++
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On Thu, Jan 11, 2018 at 12:07 PM, Peter Stuge wrote: > Maybe this is a discussion for -project, then? > Getting these kinds of non-technical discussions off of -dev is most of the point of this. The purpose of this list is discussion of things like eclass changes, fixing bugs, and so on. It is kind of hard to get new people interested in fixing bugs when half the traffic is complaining because the people doing the work aren't doing it in a way that makes the people not doing the work feel important. -- Rich
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
Maybe this is a discussion for -project, then? Andreas K. Huettel wrote: > a few outside trolls who > * keep pushing their personal agenda in endless threads, > * confuse their own inability to contribute with being a mistreated underdog, > * and keep commenting opinionated on technical things they plainly have no > clue about (while whining when are told they sprout bulls##t). .. > Andreas K. Hüttel .. > (council, toolchain, perl, libreoffice, comrel) You Sir are IMHO neither fit for the office of council nor of comrel, solely based on your communication style in that one mail. I would not vote for you, and would vote against you if that's even possible. //Peter
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
Michał Górny schrieb: I guess you should have voiced your opinion back when discussion was taking place instead of being hostile *now* because the Council listened to what the developers requested. The arguments why these posting restrictions are a pretty bad idea have all been voiced back then already. So no point in posting them again each time. But of course it is also true that Council is elected by and acts on behalf of the developers. So my suggestion for developers who heavily disagree with this decision is to look at who voted which way in the public logs. Then read carefully who in their next Council election manifesto plans to lift this restriction again. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change (v3)
This time with a version constrain that should allow this to expire at some point in the future. Title: GnuCash 2.7+ Breaking Change Author: Aaron W. Swenson Posted: 2018-01-11 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: https://github.com/Gnucash/gnucash/releases/tag/2.7.0a Title: GnuCash 2.7+ Breaking Change Author: Aaron W. Swenson Posted: 2018-01-11 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: https://github.com/Gnucash/gnucash/releases/tag/2.7.0a signature.asc Description: Digital signature
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On Wed, Jan 10, 2018 at 3:53 AM, Michał Górny wrote: > I guess you should have voiced your opinion back when discussion was > taking place instead of being hostile *now* because the Council listened > to what the developers requested. > > And if you are curious, then I've been asked by multiple developers > (and a few users) requesting the restriction, and I haven't been > contacted by a single one who asked otherwise. > My initial concern was related to what you are seeing now. Mailing list participation is very relaxed. What is likely to happen is some day a user will have cause to send a message and won't be able to, because they don't know what is going on or why the list does not work like most lists they interact with. I am not sure it is wise to speak for those that are not present, because whether someone responds or not does not tell you anything about their opinion. Respectfully, R0b0t1
[gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
On Wednesday, January 10, 2018, Benda Xu wrote: > Hi MJ, > > "M. J. Everitt" writes: > >> Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the >> different between 2.6.16+ and 2.6.32+ .. should this potentially be >> 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me, >> and more confusing to others > > 2.6.16+ means that it can be used in any cases when the kernel is newer > than 2.6.16. For example, you can use it on linux-4.14, just with > unnecessary backward compatibility code. > > Besides, with the newest profile, kernel-3.2+, the ending kernel version > is not known. We will have to rename it when glibc jumps if the profile > is named with a version range. > I don't want to just comment on naming, but: It might be more natural to go the other way. Split profiles off based on version when breakage occurs, and otherwise do not reference a specific version. Then, the name indicates the most recent kernel supported by the profile. So remove the plus and (I think) shift all of the names "forward." So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name. This seems more natural but does change the semantics of the name. Would that be a problem? Is it expected people would want to use the profiles with compatibility features on newer kernels? This setup would prevent having to verify that old code works on new systems, which is implied to be supported.by the + naming (again, not sure if it matters). Cheers, R0b0t1
Re: [gentoo-dev] Improving the support for minor arches and less common profiles in CI
W dniu nie, 07.01.2018 o godzinie 21∶25 +0100, użytkownik Michał Górny napisał: > W dniu sob, 06.01.2018 o godzinie 12∶10 +0100, użytkownik Michał Górny > napisał: > > So I'm thinking of an alternate idea: to start adding staging warnings > > for additional profile class, combined with arch restriction. In other > > words, change CI from: > > > > -p stable > > > > to: > > > > -p stable,something -a alpha,amd64,...,mips,... > > > > with a separate class for NonSolvableDeps in non-stable profiles (like > > repoman's badindev/badinexp) that triggers only a staging-class warning. > > > > However, this means that: > > > > ১. We need to settle for either dev or exp being 'more' supported, > > and drop all unsupported profiles to the other group. > > > > ২. We need to fix the appropriate class of profiles for stable arches > > (or move them to the other group). > > > > ৩. The arches in question still need to generate reasonably low number > > of warnings. > > > > I'd like to follow this with a more precise proposal. Namely, redefine > the current profile statuses to apply the following: > > a. stable -> fully tested, all depgraph breakages are errors, > > b. exp -> fully tested, all depgraph breakages are warnings, > > c. dev -> developer's playground, not tested. > > > This would specifically mean that: > > 1. Any 'exp' profiles with serious breakage will temporarily be > downgraded to 'dev'. > > 2. A 'dev' profile can be upgraded to 'exp' if its scale of depgraph > breakage is reasonable (i.e. doesn't clutter the QA report with too many > warnings). > > 3. A 'exp' profile can be upgraded to 'stable' only if it has no > depgraph breakages. > Following the explanation from Ulrich Müller, I'm correcting this proposal by swapping exp and dev, that is: a. stable -> fully tested, all depgraph breakages are errors, b. dev -> fully tested, all depgraph breakages are warnings, c. exp -> not tested. I will post updated patches shortly. -- Best regards, Michał Górny
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On 2018.01.11 01:03, Andreas K. Huettel wrote: > > Does being 'struck off' the list in this way apply to devs, > including > > Council and comrel members? > > So far noone has even considered "striking" devs off the list. If this > even > were to happen ever, it would have to be backed by a full comrel team > decision > / vote. And these don't happen often, don't happen quickly, and don't > happen > lightly. (I much prefer fixing the glibc ebuilds, horrible as these > may be.) > > We have now an imperfect solution to an unneccessary problem. If > anyone can > come up with a better solution (that is still an improvement over > doing > nothing), I'm all ears. List moderation is not one, since a) it still > hasn't > been implemented technically, b) even if that were done, we would > still > require an active moderation team, and c) then we start bikeshedding > about the > moderation rules. > > > -- > Andreas K. Hüttel > dilfri...@gentoo.org > Gentoo Linux developer > (council, toolchain, perl, libreoffice, comrel) Andreas, Does removing non @gentoo.org email address from the ML not require that process too? Gentoo does not have any other disiplinary process than the action by comrel that you describe. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgp0aZ8m0b6IP.pgp Description: PGP signature
Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change
On Wed, 2018-01-10 at 20:00 -0500, Aaron W. Swenson wrote: > On 2018-01-10 22:53, Ciaran McCreesh wrote: > > On Wed, 10 Jan 2018 17:48:32 -0500 > > "Aaron W. Swenson" wrote: > > > Modified a bit. This should show for anyone who has GnuCash > > > installed. > > > > For anyone who has any version of GnuCash installed, either now or > > at > > any point in the future. (See the recent thread on expiring news > > items...) Are you sure you don't just want to target this at people > > who > > have the old version installed, instead? > > As mentioned, the concern is that someone will try to use a new > version > and old version simultaneously. > > How about “ after > quite some time. At least past the point that we'd be concerned > about, > I'm sure. That sounds good to me. The background here is, that once 2.7 is released as stable, it'll be released as version 3.0, so 4 is after that. And then if they keep doing 3.2, 3.4 and so on for a long time instead, you can try to remember to tweak the news item to expire before, e.g to a version that drops forward migration support from 2.6. This is all on the premise, that it's a leaf package and only kept shown to those that have it. Mart
Re: [gentoo-dev] about stable, dev and exp profile status
January 11, 2018 9:52 AM, "Paweł Hajdan, Jr." wrote: > On 11/01/2018 08:43, Fabian Groffen wrote: > >> I always was under the impression the following order (and explanation) >> was the case: >> >> stable -> development -> experimental >> >> For this reason, e.g. Prefix profiles are (still) experimental, which >> means they really shouldn't bother non-Prefix people. Prefix users and >> developers work on an environment where those profiles are promoted to >> development ones, such that repoman kicks in for their work. (At least >> that was the idea.) >> >> I see you (re-)define dev as "developer's playground", and I wonder if >> in that case it wouldn't be better to introduce a new one instead? >> >> Maybe I'm just one of a few who thinks the order is reversed now. > > The stable -> dev -> exp order also feels more natural to me. > > I don't have a strong opinion on this though. > > Paweł I got the impression that it was indeed stable -> development -> experimental with dev as in development, it seemed logical to put it between stable and experimental. But now that I read these comments I wonder if it wasnt supposed to be called 'developers' and then the other way round makes sense too. -- Corentin “Nado” Pazdera
Re: [gentoo-dev] about stable, dev and exp profile status
Dnia 11 stycznia 2018 08:43:32 CET, Fabian Groffen napisał(a): >On 07-01-2018 21:25:28 +0100, Michał Górny wrote: >> I'd like to follow this with a more precise proposal. Namely, >redefine >> the current profile statuses to apply the following: >> >> a. stable -> fully tested, all depgraph breakages are errors, >> >> b. exp -> fully tested, all depgraph breakages are warnings, >> >> c. dev -> developer's playground, not tested. > >I always was under the impression the following order (and explanation) >was the case: > >stable -> development -> experimental > >For this reason, e.g. Prefix profiles are (still) experimental, which >means they really shouldn't bother non-Prefix people. Prefix users and >developers work on an environment where those profiles are promoted to >development ones, such that repoman kicks in for their work. (At least >that was the idea.) > >I see you (re-)define dev as "developer's playground", and I wonder if >in that case it wouldn't be better to introduce a new one instead? > >Maybe I'm just one of a few who thinks the order is reversed now. Ulrich has pointed out good enough proof that the ordering should be as you say, so I'll correct my proposal. > >Thanks, >Fabian -- Best regards, Michał Górny (by phone)
Re: [gentoo-dev] about stable, dev and exp profile status
On 11/01/2018 08:43, Fabian Groffen wrote: > I always was under the impression the following order (and explanation) > was the case: > > stable -> development -> experimental > > For this reason, e.g. Prefix profiles are (still) experimental, which > means they really shouldn't bother non-Prefix people. Prefix users and > developers work on an environment where those profiles are promoted to > development ones, such that repoman kicks in for their work. (At least > that was the idea.) > > I see you (re-)define dev as "developer's playground", and I wonder if > in that case it wouldn't be better to introduce a new one instead? > > Maybe I'm just one of a few who thinks the order is reversed now. The stable -> dev -> exp order also feels more natural to me. I don't have a strong opinion on this though. Paweł
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On Thu, 11 Jan 2018 10:03:54 +0300 Eray Aslan wrote: >On Wed, Jan 10, 2018 at 08:55:11AM +0100, Lars Wendler wrote: >> Seems we're turning into an elitist club or something... > >Elitist seems too kind a word. Knee-jerk reaction, petty vendetta, >impulsive emotional reaction comes to mind - instead of articulating >and implementing a vision for the distribution, principled action, >making all devs work together towards the goals that have been set. >Not day to day reactions and bad ones at that. Council is failing its >one main task - it prolly has been for some time, this one also fails >"first, do no harm" test. A german term comes to my mind which applies perfectly to this: "Blinder Aktionismus" which roughly translates to "blind actionism". >Mind you they are not harming willingly. I am pretty sure they are all >well intentioned. They, as a group, just do not have, I dont know, the >vision, the experience, the personality to lead a distro. > >We need a change as otherwise I am afraid the future is not bright. I >think with this last straw I lost faith in the current setup. Death by >a committee. Yey. > I'm totally baffled that few people seem to know how to filter trolls out of their inboxes. In the past such trolls were treated with a "plonk" and all was good. But nowadays everything has to be ruled somehow. Ah well, it's only a disservice to our users. Nothing the council needs to worry about as they seem to have forgotten that they once were users as well... -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgpQsMGd7Cdiy.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
On 11/01/18 03:18, Benda Xu wrote: > Hi MJ, > > "M. J. Everitt" writes: > >> Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the >> different between 2.6.16+ and 2.6.32+ .. should this potentially be >> 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me, >> and more confusing to others > 2.6.16+ means that it can be used in any cases when the kernel is newer > than 2.6.16. For example, you can use it on linux-4.14, just with > unnecessary backward compatibility code. > > Besides, with the newest profile, kernel-3.2+, the ending kernel version > is not known. We will have to rename it when glibc jumps if the profile > is named with a version range. > > > Hope this addresses your concern. > > Cheers, > Benda Thanks, that does make sense! MJE signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Upcoming posting restrictions on the gentoo-dev mailing list
Hi Gordon, On Wed, 10 Jan 2018 23:37:39 -0600 Gordon Pettey wrote: >On Wed, Jan 10, 2018 at 10:22 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> Andreas K. Huettel posted on Thu, 11 Jan 2018 02:12:47 +0100 as >> excerpted: >>> Am Mittwoch, 10. Januar 2018, 18:16:33 CET schrieb Vincent-Xavier >>> JUMEL: Le 2018-01-10 10:53, Michał Górny a écrit : > Last I checked, Gentoo was a Linux distribution. However, some > people prefer to turn it into open discussion forum that has > nothing to do with making a distribution. No it has. Giving power to a subset of users, denying interaction with future contributors unless they enroll is the eaxct way to kill Gentoo as a community ! >>> >>> We wouldn't have needed to go this far if not for a few outside >>> trolls who >>> * keep pushing their personal agenda in endless threads, >>> * confuse their own inability to contribute with being a mistreated >>> underdog, >>> * and keep commenting opinionated on technical things they >>> plainly have no clue about (while whining when are told they sprout >>> bulls##t). >>> >>> We do not have a problem with "future contributors". I wager those >>> will rather increase in numbers once the list spam is gone. >> >> >> This has been my biggest concern about the whole thing: >> >> Are we going to be nipping future devs in the bud because there's >> now too many hoops to jump thru too early, and it's simply not worth >> the trouble when they can (and will) go elsewhere where it's easier, >> >> OR >> >> Are we going to be lowering the unwelcoming noise, confusion and >> name- calling threshold and making the community more welcoming for >> those who have a serious interest, clearing out some of the stuff >> that could otherwise discourage them. >> >> >> It's pretty clear that council believes it's the latter, at least to >> the degree that they're willing to try it for a time, effectively a >> wager of sorts, but I don't believe anyone can honestly say what the >> real effect one way or the other will be until it /is/ tried. >> >> >> Personally, my viewpoint is that while over the last year or so there >> were some 1-2 level frustrating posters on a 5-point scale, it's >> nothing compared to the level-4 (direct name calling, just short of >> physical threats that justify getting the law involved) stuff that >> I've seen on this list in the some-years-distant past. In my mind, >> unquestionably that level-4 stuff required action, and it was taken. >> >> The recent stuff seems so much milder in comparison that IMO it's >> hard to see what the hubbub is all about, but there's certainly an >> argument to be made that the previous experience simply desensitized >> our detection meters, and that were it not for that, the recent >> stuff would seem rather more shocking and horrible than it does, and >> that even if it's /less/ horrible, it's horrible /enough/ that it >> remains unacceptable in a civilized society, and if we /do/ accept >> it, we're effectively pushing others that won't, out. > >Given the quantity of relevant problem-mail that came from >@gentoo.org, maybe the glass house dwellers should be careful where >they aim their stones. I considered taking the dev quiz and everything >instead of just posting a few ebuilds on bugzilla years ago, but the >elitist, as Alex labelled it, voices from @gentoo.org are what made me >decide not to, and my decision keeps getting reinforced. That >impression has been there for years, and it's not getting better by >this. > very sad you got that impression. And unfortunately, I cannot even wholeheartedly deny that this is true. Given the fact that we are severely understaffed when it comes to active developers, I hope you will reconsider your decision at some point and start doing the quizzes. Kind regards -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgpFHcQ4Bo_xI.pgp Description: Digitale Signatur von OpenPGP
