The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired.
Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/<pkgname>
Full report available at: https://churchyard.fedorapeople.org/orphans-2021-07-07.txt grep it for your FAS username and follow the dependency chain.
For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan
Package (co)maintainers Status Change ================================================================================ 8sync orphan 1 weeks ago HdrHistogram acaringi, almac, hhorak, 2 weeks ago jvanek, orphan JSCookMenu orphan 2 weeks ago WebCalendar orphan 2 weeks ago automaton orphan 4 weeks ago biboumi louizatakk, orphan 2 weeks ago dpsearch codeblock, jam3s, orphan 5 weeks ago erlang-riak_pipe bowlofeggs, erlang-maint-sig, 3 weeks ago orphan git-cal codeblock, orphan 5 weeks ago golang-github-atotto-clipboard orphan 0 weeks ago guile22 mlichvar, orphan 1 weeks ago java-atk-wrapper omajid, orphan 3 weeks ago jboss-annotations-1.2-api cfu, cipherboy, ckelley, 2 weeks ago dmoluguw, jmagne, mharmsen, orphan jboss-logmanager cipherboy, dmoluguw, gil, 4 weeks ago jmagne, lef, orphan jmc almac, orphan, sasiddiq 2 weeks ago jmc-core almac, orphan, sasiddiq 2 weeks ago js-gl-matrix orphan 1 weeks ago luit ajax, ofourdan, orphan 4 weeks ago lz4-java orphan 2 weeks ago mate-applet-softupd orphan 2 weeks ago mvel orphan 2 weeks ago owasp-java-encoder almac, orphan, sasiddiq 2 weeks ago perl-Debug-Client orphan, ppisar 4 weeks ago perl-MooX-Types-MooseLike orphan 1 weeks ago perl-Padre orphan, ppisar 4 weeks ago php-PHPMailer orphan, remi 2 weeks ago php-captchaphp orphan 2 weeks ago php-hkit orphan 2 weeks ago php-pear-Auth-Yubico orphan 2 weeks ago php-rmccue-requests orphan 3 weeks ago python-aiozmq orphan 1 weeks ago python-fn codeblock, orphan 5 weeks ago python-glusterfs-api humble, orphan 3 weeks ago python-jsonrpcserver orphan 1 weeks ago python-nose-cov orphan 1 weeks ago python-nss jmagne, orphan 2 weeks ago python-pytest-helpers-namespace orion, orphan, python-sig 0 weeks ago python-pytest-relaxed orphan 3 weeks ago python-setuptools-lint orphan 1 weeks ago python-tempita kylev, orphan 2 weeks ago python-urlobject orphan 1 weeks ago qtile cicku, orphan 1 weeks ago qtpass marcindulak, orphan, vascom 6 weeks ago rubygem-ditz orphan 5 weeks ago rubygem-expression_parser orphan 1 weeks ago rubygem-fssm orphan 1 weeks ago rubygem-mono_logger orphan 5 weeks ago rubygem-redis-namespace orphan 5 weeks ago rubygem-resque orphan 5 weeks ago rubygem-sdoc orphan 4 weeks ago rubygem-thin mmagr, orphan, valtri, 4 weeks ago vondruch rubygem-trollop orphan 5 weeks ago rubygem-vegas orphan 5 weeks ago stax2-api cfu, ckelley, java-maint-sig, 2 weeks ago jmagne, mharmsen, mizdebsk, orphan vim-syntastic orphan 2 weeks ago woodstox-core cfu, ckelley, java-maint-sig, 3 weeks ago jmagne, mharmsen, mizdebsk, orphan
The following packages require above mentioned packages: Report too long, see the full version at https://churchyard.fedorapeople.org/orphans-2021-07-07.txt
See dependency chains of your packages at https://packager-dashboard.fedoraproject.org/ See all orphaned packages at https://packager-dashboard.fedoraproject.org/orphan
Affected (co)maintainers (either directly or via packages' dependencies): abbra: rubygem-thin, guile22, python-tempita abompard: python-tempita acardace: guile22 acaringi: HdrHistogram, guile22 adalloz: guile22 adeza: python-tempita adrian: guile22 aegorenk: guile22 aglitke: rubygem-thin ahughes: HdrHistogram, jmc, owasp-java-encoder, jmc-core ajax: luit akurtakov: HdrHistogram, jmc, owasp-java-encoder, jmc-core alakatos: guile22 alexl: guile22 alexlan: guile22 almac: HdrHistogram, jmc, owasp-java-encoder, jmc-core amerey: rubygem-thin andreamanzi: python-tempita andymenderunix: guile22 ankursinha: guile22 anoopcs: rubygem-thin, guile22, python-tempita ansasaki: guile22 aperezbios: guile22 apevec: python-tempita arobinso: HdrHistogram, jmc, owasp-java-encoder, jmc-core asn: rubygem-thin, guile22, python-tempita asosedkin: jmc-core, HdrHistogram, jmc, guile22, owasp-java-encoder asrob: guile22 athmane: guile22 atikhonov: guile22 atim: HdrHistogram, jmc, owasp-java-encoder, jmc-core avagin: guile22 bbockelm: rubygem-thin bcl: guile22 bcotton: rubygem-thin bengal: guile22 berrange: rubygem-thin, guile22, python-tempita besser82: guile22, python-tempita bkearney: rubygem-thin bonzini: rubygem-thin, guile22, python-tempita bowlofeggs: erlang-riak_pipe bpepple: guile22 branto: python-tempita buc: guile22 caillon: guile22 caniszczyk: HdrHistogram, jmc, owasp-java-encoder, jmc-core caolanm: guile22 catanzaro: guile22 cfeist: rubygem-thin cfu: stax2-api, jboss-annotations-1.2-api, woodstox-core cheeselee: guile22 chkr: guile22 cicku: guile22, qtile cipherboy: jboss-annotations-1.2-api, jboss-logmanager ckelley: stax2-api, jboss-annotations-1.2-api, woodstox-core clalance: rubygem-thin, guile22, python-tempita clumens: guile22 cockpit: rubygem-thin, guile22 codeblock: git-cal, python-fn, dpsearch corsepiu: perl-MooX-Types-MooseLike cosimoc: guile22 cra: guile22 crobinso: rubygem-thin, guile22, python-tempita crypto-team: jmc-core, HdrHistogram, jmc, guile22, owasp-java-encoder cverna: python-tempita cwickert: guile22 czanik: guile22 dang: rubygem-thin, python-tempita danw: guile22 davidsch: guile22 dbhole: HdrHistogram, jmc, owasp-java-encoder, jmc-core dcallagh: python-tempita dcavalca: jmc-core, HdrHistogram, jmc, guile22, owasp-java-encoder dcbw: guile22 deamn: HdrHistogram, jmc, owasp-java-encoder, jmc-core defolos: guile22 deji: guile22 devos: rubygem-thin, guile22, python-tempita djdelorie: guile22 dmick: python-tempita dmoluguw: jboss-annotations-1.2-api, jboss-logmanager dns-sig: guile22 dperpeet: guile22 drsmith2: rubygem-thin dwmw2: rubygem-thin, guile22, python-tempita dyfet: guile22 dyoung: guile22 ebaron: HdrHistogram, jmc, owasp-java-encoder, jmc-core eclipse-sig: HdrHistogram, jmc, owasp-java-encoder, jmc-core eclipseo: rubygem-thin, golang-github-atotto-clipboard, guile22, python-tempita eerlands: rubygem-thin ehabkost: rubygem-thin, guile22, python-tempita ekkis: guile22 ellert: python-tempita, php-PHPMailer elmarco: rubygem-thin, guile22 enslaver: guile22 erack: guile22 ericb: rubygem-thin, guile22 erlang-maint-sig: erlang-riak_pipe eseyman: perl-MooX-Types-MooseLike f1ash: rubygem-thin fab: rubygem-thin, guile22 fale: guile22 fbo: python-tempita fche: rubygem-thin feborges: rubygem-thin fgiudici: guile22 fidencio: rubygem-thin, guile22 filbranden: guile22 filiperosset: jmc-core, HdrHistogram, jmc, guile22, owasp-java-encoder fjanus: guile22 flepied: guile22 fschwarz: guile22 galileo: HdrHistogram, jmc, owasp-java-encoder, jmc-core gbcox: guile22 gchamoul: guile22, python-tempita gd: rubygem-thin, guile22, python-tempita giallu: python-tempita, php-PHPMailer gil: jboss-logmanager gnat: guile22 gnome-sig: rubygem-thin, guile22 go-sig: golang-github-atotto-clipboard, python-tempita green: guile22 grover: rubygem-thin, python-tempita guidograzioli: guile22 harald: guile22 herrold: guile22 hguemar: guile22 hhorak: jmc-core, HdrHistogram, jmc, guile22, owasp-java-encoder hubbitus: guile22 humble: rubygem-thin, python-glusterfs-api huzaifas: guile22 iarnell: perl-MooX-Types-MooseLike iboukris: rubygem-thin, guile22, python-tempita idevat: rubygem-thin ignatenkobrain: guile22, python-tempita imcleod: rubygem-thin infra-sig: python-tempita isimluk: guile22 iucar: HdrHistogram, jmc, owasp-java-encoder, jmc-core ixs: guile22 jadahl: guile22 jam3s: dpsearch janfrode: guile22 jarrpa: rubygem-thin, guile22, python-tempita java-maint-sig: woodstox-core, jmc-core, HdrHistogram, jmc, stax2-api, owasp-java-encoder java-sig: woodstox-core, jmc-core, HdrHistogram, jmc, stax2-api, owasp-java-encoder jaymzh: golang-github-atotto-clipboard jcaratzas: python-tempita jenslody: HdrHistogram, jmc, owasp-java-encoder, jmc-core jerboaa: HdrHistogram, jmc, owasp-java-encoder, jmc-core jforbes: rubygem-thin, guile22, python-tempita jgorig: guile22 jgrulich: guile22 jgu: guile22 jhrozek: guile22 jiffintt: rubygem-thin, python-tempita jistone: rubygem-thin jjanco: HdrHistogram, jmc, owasp-java-encoder, jmc-core jjelen: guile22 jjohnstn: HdrHistogram, jmc, owasp-java-encoder, jmc-core jkastner: guile22 jklimes: guile22 jlayton: rubygem-thin, guile22, python-tempita jmagne: woodstox-core, python-nss, stax2-api, jboss-annotations-1.2-api, jboss-logmanager jorton: guile22 jpacner: guile22 jpena: python-tempita jplesnik: rubygem-thin, perl-MooX-Types-MooseLike jpokorny: guile22 jruzicka: guile22 jskala: guile22 jskarvad: guile22 jsteffan: rubygem-thin jstephen: rubygem-thin, guile22, python-tempita jstribny: rubygem-thin jsynacek: guile22 jtaylor: guile22 jvanek: woodstox-core, jmc-core, HdrHistogram, jmc, stax2-api, owasp-java-encoder jwrdegoede: guile22 kalev: guile22 kdaniel: HdrHistogram, jmc, owasp-java-encoder, jmc-core kde-sig: rubygem-thin kdudka: guile22 ke4qqq: python-tempita kengert: HdrHistogram, jmc, owasp-java-encoder, jmc-core kevin: rubygem-thin, guile22, python-tempita, python-nss kkeithle: rubygem-thin, python-tempita kkoukiou: rubygem-thin ktdreyer: python-tempita kwenning: guile22 kwizart: guile22 kylev: python-tempita laine: rubygem-thin, guile22, python-tempita landgraf: guile22 lbazan: python-tempita lberk: rubygem-thin lef: jmc-core, HdrHistogram, jmc, owasp-java-encoder, jboss-logmanager lennart: guile22 libvirt-maint: rubygem-thin, guile22, python-tempita limb: guile22 ljavorsk: jmc-core, HdrHistogram, jmc, guile22, owasp-java-encoder lkundrak: rubygem-thin, guile22, python-tempita lmacken: python-tempita lnie: rubygem-thin lnykryn: guile22 lon: guile22 louizatakk: biboumi lslebodn: guile22 lupinix: guile22 maha: guile22 marcindulak: qtpass martinkg: guile22 martinpitt: rubygem-thin, guile22 marx: rubygem-thin, guile22 matt: rubygem-thin matyas: rubygem-thin mbacovsk: python-tempita mbarnes: guile22 mbooth: HdrHistogram, jmc, owasp-java-encoder, jmc-core mcermak: rubygem-thin mclasen: guile22 mdarade: guile22 mdbooth: rubygem-thin mharmsen: stax2-api, jboss-annotations-1.2-api, woodstox-core mhlavink: rubygem-thin, guile22 michaelc: rubygem-thin, python-tempita michalvala: HdrHistogram, jmc, owasp-java-encoder, jmc-core michich: guile22 mikep: jmc-core, HdrHistogram, jmc, rubygem-thin, owasp-java-encoder mitr: python-nss mizdebsk: woodstox-core, jmc-core, HdrHistogram, jmc, stax2-api, owasp-java-encoder mjakubicek: jmc-core, HdrHistogram, jmc, guile22, owasp-java-encoder mjw: rubygem-thin mkrizek: rubygem-thin mlichvar: guile22 mlisik: rubygem-thin mlombard: rubygem-thin, python-tempita mmagr: rubygem-thin mmarusak: rubygem-thin, guile22 mmuzila: guile22 moceap: guile22 moezroy: guile22 mohammedisam: HdrHistogram, jmc, owasp-java-encoder, jmc-core monnerat: guile22 mooninite: guile22 mrunge: python-tempita mruprich: guile22 mschorm: jmc-core, HdrHistogram, jmc, guile22, owasp-java-encoder mschwendt: guile22 msekleta: guile22 msivak: rubygem-thin mstevens: guile22 mtasaka: guile22 myoung: guile22 mzidek: guile22 nalin: guile22 nb: guile22 neuro-sig: python-tempita ngompa: rubygem-thin, guile22, python-tempita niveusluna: guile22 nmav: guile22 nonamedotc: guile22 notting: guile22 nucleo: guile22 oalbrigt: rubygem-thin, guile22 obnox: rubygem-thin, guile22, python-tempita odubaj: HdrHistogram, jmc, owasp-java-encoder, jmc-core ofourdan: luit oget: HdrHistogram, jmc, owasp-java-encoder, jmc-core oliver: HdrHistogram, jmc, owasp-java-encoder, jmc-core omajid: jmc-core, java-atk-wrapper, jmc, HdrHistogram, owasp-java-encoder omular: rubygem-thin ondrejj: python-tempita openstack-sig: python-tempita orion: python-pytest-helpers-namespace, guile22 osier: rubygem-thin, guile22, python-tempita otaylor: guile22 panovotn: guile22 pawsa: guile22 pbrezina: guile22 pemensik: guile22 peter: erlang-riak_pipe, guile22 pfrankli: guile22 pghmcfc: guile22 phatina: guile22 phracek: guile22 phrdina: rubygem-thin pmikova: HdrHistogram, jmc, owasp-java-encoder, jmc-core pmkovar: guile22 ppisar: guile22, perl-Debug-Client, perl-Padre, perl-MooX-Types-MooseLike praiskup: guile22 psabata: guile22 pwalter: guile22 pwouters: guile22 python-sig: python-pytest-helpers-namespace qa-tools-sig: rubygem-thin quintela: rubygem-thin, guile22, python-tempita radekmanak: HdrHistogram, jmc, owasp-java-encoder, jmc-core radez: python-tempita rakesh: guile22 ralph: guile22, python-tempita raphgro: rubygem-thin rathann: guile22 rdieter: guile22 remi: php-PHPMailer reznik: guile22 rgrunber: HdrHistogram, jmc, owasp-java-encoder, jmc-core rhughes: guile22 richardfearn: HdrHistogram, jmc, owasp-java-encoder, jmc-core ricky: python-tempita rishi: guile22 rjones: rubygem-thin, guile22, python-tempita rlescak: guile22 robert: guile22 rombobeorn: guile22 rrankin: guile22 rrelyea: jmc-core, HdrHistogram, jmc, guile22, owasp-java-encoder rsroka: guile22 rstrode: guile22 rtcm: guile22 ruben: rubygem-thin ruby-packagers-sig: rubygem-thin sagitter: jmc-core, HdrHistogram, jmc, guile22, owasp-java-encoder sailer: guile22 salimma: guile22 sandeen: python-tempita sasiddiq: jmc, owasp-java-encoder, HdrHistogram, jmc-core sbonazzo: rubygem-thin sbose: guile22 scottt: HdrHistogram, jmc, owasp-java-encoder, jmc-core scox: rubygem-thin sergiodj: guile22 sergiomb: guile22 sgallagh: guile22 sgordon: guile22 sgros: guile22 sgrubb: guile22 sham1: guile22 sharkcz: guile22 shlomif: perl-MooX-Types-MooseLike simo: rubygem-thin, guile22, python-tempita simonm: python-tempita skoduri: rubygem-thin, python-tempita slaanesh: guile22, perl-MooX-Types-MooseLike smakarov: rubygem-thin smani: guile22, perl-MooX-Types-MooseLike smilner: python-tempita spot: jmc-core, HdrHistogram, jmc, guile22, owasp-java-encoder ssahani: guile22 ssp: guile22 sssd-maintainers: guile22 stefanb: guile22 stefanberger: guile22 stefw: guile22 steve: rubygem-thin, guile22, python-tempita, perl-MooX-Types-MooseLike steved: guile22 stevetraylen: rubygem-thin stingray: guile22, python-tempita svashisht: guile22 swt2c: guile22 systemd-maint: guile22 tartare: guile22 tbabej: guile22 tdawson: rubygem-thin, rubygem-trollop tdecacqu: python-tempita terjeros: rubygem-thin, python-tempita teuf: rubygem-thin, guile22 tflink: rubygem-thin thaller: guile22 thozza: guile22 timn: guile22 tkorbar: guile22 tkrizek: guile22 tmraz: jmc-core, HdrHistogram, jmc, guile22, owasp-java-encoder tojeline: rubygem-thin totol: guile22 tpopela: jmc-core, HdrHistogram, jmc, guile22, owasp-java-encoder tstclair: rubygem-thin ttheisen: rubygem-thin twaugh: guile22 ueno: guile22 ultrafredde: guile22 uraeus: guile22 uwog: guile22 valtri: rubygem-thin, rubygem-trollop vascom: rubygem-thin, qtpass vcrhonek: rubygem-thin veillard: rubygem-thin, guile22, python-tempita victortoso: rubygem-thin virtmaint-sig: rubygem-thin, guile22, python-tempita volter: guile22 vondruch: rubygem-thin, rubygem-trollop wakko666: guile22 wart: guile22 wcohen: rubygem-thin wef: guile22 wolfy: guile22 wtaymans: guile22 xaeth: rubygem-thin xavierb: perl-MooX-Types-MooseLike xiubli: rubygem-thin yaneti: guile22 yuwata: guile22 zbyszek: guile22 zdohnal: guile22 zeenix: rubygem-thin zfridric: guile22 zuul: python-tempita
Hi,
On 7/7/21 11:18 AM, Miro Hrončok wrote:
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired.
Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/<pkgname>
Full report available at: https://churchyard.fedorapeople.org/orphans-2021-07-07.txt grep it for your FAS username and follow the dependency chain.
For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan
Package (co)maintainers Status Change
<snip>
guile22 mlichvar, orphan 1 weeks ago
<snip>
Does anyone know what is going on here / I was sorta surprised to learn that ATM we have 2 guile packages:
[hans@x1 ~]$ rpm -q guile guile22 guile-2.0.14-24.fc34.x86_64 guile22-2.2.7-2.fc34.x86_64
Note that guile22 actually is the newer version of guile. And it seems that most of the packages which use guile are actually using guile22.
So is the plan to make the "guile" packages contain guile-2.2 now and is that why guile22 is going away? Or ... ?
Regards,
Hans
On Wed, Jul 07, 2021 at 11:18:04AM +0200, Miro Hrončok wrote:
guile22 mlichvar, orphan 1 weeks ago
There's a dependency chain going from guile22 -> gnutls-devel -> lots of virtualization packages.
This dependency provides gnutls bindings for guile programs.
In Fedora, gnutls's dependency on guile22 is compile-time optional. Enabled for Fedora and disabled for RHEL.
The latest gnutls sources seem to be insistent on requiring guile 2.2 specifically.
Guile upstream maintains 3.0 and 2.2 ("legacy 2.2.x series"). Fedora's packaging of Guile seems confusing to say the least. We have "guile" (2.0.14), "guile22" (2.2.7 - orphaned), and I cannot find guile 3.0 packaged at all. Sorry if I missed something.
I'd say the easiest way out here is to disable gnutls's dependency on guile22 in Fedora (so it's like RHEL).
Rich.
On Wed, Jul 7, 2021 at 6:08 AM Richard W.M. Jones rjones@redhat.com wrote:
On Wed, Jul 07, 2021 at 11:18:04AM +0200, Miro Hrončok wrote:
guile22 mlichvar, orphan 1 weeks ago
There's a dependency chain going from guile22 -> gnutls-devel -> lots of virtualization packages.
This dependency provides gnutls bindings for guile programs.
In Fedora, gnutls's dependency on guile22 is compile-time optional. Enabled for Fedora and disabled for RHEL.
The latest gnutls sources seem to be insistent on requiring guile 2.2 specifically.
Guile upstream maintains 3.0 and 2.2 ("legacy 2.2.x series"). Fedora's packaging of Guile seems confusing to say the least. We have "guile" (2.0.14), "guile22" (2.2.7 - orphaned), and I cannot find guile 3.0 packaged at all. Sorry if I missed something.
I'd say the easiest way out here is to disable gnutls's dependency on guile22 in Fedora (so it's like RHEL).
Wait, why don't we have guile 3.0?
On Wed, Jul 7, 2021 at 7:08 AM Florian Weimer fweimer@redhat.com wrote:
- Neal Gompa:
Wait, why don't we have guile 3.0?
We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult.
Are you telling me that GNU Make doesn't support GNU Guile 3.0? Because that's definitely not true: https://git.savannah.gnu.org/cgit/make.git/tree/configure.ac#n182
* Neal Gompa:
On Wed, Jul 7, 2021 at 7:08 AM Florian Weimer fweimer@redhat.com wrote:
- Neal Gompa:
Wait, why don't we have guile 3.0?
We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult.
Are you telling me that GNU Make doesn't support GNU Guile 3.0? Because that's definitely not true: https://git.savannah.gnu.org/cgit/make.git/tree/configure.ac#n182
No, Guile is just a core toolchain package, so it's difficult to update.
I think it would be much easier (and self-contained) if it weren't a required part of the toolchain.
Thanks, Florian
On Wed, Jul 7, 2021 at 7:18 AM Florian Weimer fweimer@redhat.com wrote:
- Neal Gompa:
On Wed, Jul 7, 2021 at 7:08 AM Florian Weimer fweimer@redhat.com wrote:
- Neal Gompa:
Wait, why don't we have guile 3.0?
We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult.
Are you telling me that GNU Make doesn't support GNU Guile 3.0? Because that's definitely not true: https://git.savannah.gnu.org/cgit/make.git/tree/configure.ac#n182
No, Guile is just a core toolchain package, so it's difficult to update.
I think it would be much easier (and self-contained) if it weren't a required part of the toolchain.
You already have the toolchain update change[1], just do it as part of that.
[1]: https://fedoraproject.org/wiki/Changes/GNUToolchainF35
-- 真実はいつも一つ！/ Always, there's only one truth!
Hi,
On 7/7/21 1:33 PM, Neal Gompa wrote:
On Wed, Jul 7, 2021 at 7:18 AM Florian Weimer fweimer@redhat.com wrote:
- Neal Gompa:
On Wed, Jul 7, 2021 at 7:08 AM Florian Weimer fweimer@redhat.com wrote:
- Neal Gompa:
Wait, why don't we have guile 3.0?
We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult.
Are you telling me that GNU Make doesn't support GNU Guile 3.0? Because that's definitely not true: https://git.savannah.gnu.org/cgit/make.git/tree/configure.ac#n182
No, Guile is just a core toolchain package, so it's difficult to update.
I think it would be much easier (and self-contained) if it weren't a required part of the toolchain.
You already have the toolchain update change[1], just do it as part of that.
Ugh, please see my other long reply in this thread (probably best to reply there)
I felt that I must respond here too, because "just do it as part of that" is again you (a Fesco member) telling others what to do, or at least sound a lot like you are telling others what to do, which completely rubs me the wrong way.
Last time I checked Fesco's role was to set policy, not to dictate how other Fedora project members spend there time. So this very nicely illustrates the point which I'm trying to make in my other email/
Regards,
Hans
Hi,
On 7/7/21 1:08 PM, Florian Weimer wrote:
- Neal Gompa:
Wait, why don't we have guile 3.0?
We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult.
So I've gone and checked the Fesco issue where dropping guile support from make + gdb was discussed:
https://pagure.io/fesco/issue/2558
And I must say that I find the argumentation for rejecting the change very very weak. I would really expect Fesco to make better motivated decisions then this one.
I'm especially shocked about how Fesco is in essence mandating a group of maintainers to spend time maintaining a feature where they clearly have indicated they don't want to maintain that feature.
My being shocked here is not so much about the guile issue, but about a IMHO much bigger issue underlying this decision:
Since when does Fesco get to mandate on which features our volunteer maintainers get to spend there time ?
I understand there need to be rules and I can understand Fesco denying approval for enabling / adding certain features for a wide set of reasons, thus in essence blocking volunteers from spending time on something because that something is deemed undesirable for Fedora.
But this is different here Fesco is telling a group of maintainers that they must maintain a feature even though they have indicated that they find the benefits of that feature not worth the amount of time it costs to maintain support for that feature. So in essence Fesco is telling the maintainers that they MUST spend time maintaining this even though they don't want this.
IMHO this is just outrageous and goes way way beyond the purview of Fesco.
Now if dropping this feature would cause major breakage this would a different story, But in the whole discussion about this, at least as documented in the Fesco issue, no actual users of this feature have been indentified and nothing will break by disabling this as far is is known. So since there is no known breakage caused by this, I end up circling back to this basically telling Fesco that the make/gdb timers MUST spend them on maintaining this even though they don't want to (and have good reasons for not wanting to).
Which again, is IHMO pretty outrageous really.
Sorry Fesco, I know that you all do a lot of (hard) work as Fesco members and do your best when making decisions like this; and I don't doubt that your intentions where well, but you made a big booboo here (IMHO).
I urge Fesco to reconsider this and I suggest that we (Fedora) take another serious look at implementing: https://fedoraproject.org/wiki/Changes/RemoveGuileFromToolchain for Fedora 35.
Regards,
Hans
On Wed, Jul 7, 2021 at 7:38 AM Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 7/7/21 1:08 PM, Florian Weimer wrote:
- Neal Gompa:
Wait, why don't we have guile 3.0?
We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult.
So I've gone and checked the Fesco issue where dropping guile support from make + gdb was discussed:
https://pagure.io/fesco/issue/2558
And I must say that I find the argumentation for rejecting the change very very weak. I would really expect Fesco to make better motivated decisions then this one.
I'm especially shocked about how Fesco is in essence mandating a group of maintainers to spend time maintaining a feature where they clearly have indicated they don't want to maintain that feature.
My being shocked here is not so much about the guile issue, but about a IMHO much bigger issue underlying this decision:
Since when does Fesco get to mandate on which features our volunteer maintainers get to spend there time ?
I understand there need to be rules and I can understand Fesco denying approval for enabling / adding certain features for a wide set of reasons, thus in essence blocking volunteers from spending time on something because that something is deemed undesirable for Fedora.
But this is different here Fesco is telling a group of maintainers that they must maintain a feature even though they have indicated that they find the benefits of that feature not worth the amount of time it costs to maintain support for that feature. So in essence Fesco is telling the maintainers that they MUST spend time maintaining this even though they don't want this.
IMHO this is just outrageous and goes way way beyond the purview of Fesco.
Now if dropping this feature would cause major breakage this would a different story, But in the whole discussion about this, at least as documented in the Fesco issue, no actual users of this feature have been indentified and nothing will break by disabling this as far is is known. So since there is no known breakage caused by this, I end up circling back to this basically telling Fesco that the make/gdb timers MUST spend them on maintaining this even though they don't want to (and have good reasons for not wanting to).
Which again, is IHMO pretty outrageous really.
Sorry Fesco, I know that you all do a lot of (hard) work as Fesco members and do your best when making decisions like this; and I don't doubt that your intentions where well, but you made a big booboo here (IMHO).
I urge Fesco to reconsider this and I suggest that we (Fedora) take another serious look at implementing: https://fedoraproject.org/wiki/Changes/RemoveGuileFromToolchain for Fedora 35.
If you want to be outraged at FESCo about this, then read the meeting log first[1].
My main point then is that *all* of the Change authors are upstream developers in the GNU Toolchain, meaning that they have to do maintenance effort around Guile support upstream anyway. If they want to remove a feature that makes Fedora the best place to use the GNU Toolchain, they should do it upstream first.
I did not find their argumentation persuasive because they used arguments that should be applied upstream and Fedora is not a special case for any of those.
I don't personally *care* much about Guile support beyond the fact I have a few private projects that use it in Makefiles, so it'd be annoying if it was gone. And I was comfortable with being overruled in my objections. I stated as much in the meeting even!
The fact was, the GNU Toolchain developers:
1. Did not show up to that FESCo meeting to try to persuade the rest of the group to vote against me. 2. Did not consider either alternative I proposed (remove it upstream, split guile support out in some way)
It was *barely* rejected by virtue of not reaching a majority vote to pass. If they want to propose it again, then be my guest.
[1]: https://meetbot.fedoraproject.org/teams/fesco/fesco.2021-02-03-15.00.log.htm...
-- 真実はいつも一つ！/ Always, there's only one truth!
Hi,
On 7/7/21 1:53 PM, Neal Gompa wrote:
On Wed, Jul 7, 2021 at 7:38 AM Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 7/7/21 1:08 PM, Florian Weimer wrote:
- Neal Gompa:
Wait, why don't we have guile 3.0?
We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult.
So I've gone and checked the Fesco issue where dropping guile support from make + gdb was discussed:
https://pagure.io/fesco/issue/2558
And I must say that I find the argumentation for rejecting the change very very weak. I would really expect Fesco to make better motivated decisions then this one.
I'm especially shocked about how Fesco is in essence mandating a group of maintainers to spend time maintaining a feature where they clearly have indicated they don't want to maintain that feature.
My being shocked here is not so much about the guile issue, but about a IMHO much bigger issue underlying this decision:
Since when does Fesco get to mandate on which features our volunteer maintainers get to spend there time ?
I understand there need to be rules and I can understand Fesco denying approval for enabling / adding certain features for a wide set of reasons, thus in essence blocking volunteers from spending time on something because that something is deemed undesirable for Fedora.
But this is different here Fesco is telling a group of maintainers that they must maintain a feature even though they have indicated that they find the benefits of that feature not worth the amount of time it costs to maintain support for that feature. So in essence Fesco is telling the maintainers that they MUST spend time maintaining this even though they don't want this.
IMHO this is just outrageous and goes way way beyond the purview of Fesco.
Now if dropping this feature would cause major breakage this would a different story, But in the whole discussion about this, at least as documented in the Fesco issue, no actual users of this feature have been indentified and nothing will break by disabling this as far is is known. So since there is no known breakage caused by this, I end up circling back to this basically telling Fesco that the make/gdb timers MUST spend them on maintaining this even though they don't want to (and have good reasons for not wanting to).
Which again, is IHMO pretty outrageous really.
Sorry Fesco, I know that you all do a lot of (hard) work as Fesco members and do your best when making decisions like this; and I don't doubt that your intentions where well, but you made a big booboo here (IMHO).
I urge Fesco to reconsider this and I suggest that we (Fedora) take another serious look at implementing: https://fedoraproject.org/wiki/Changes/RemoveGuileFromToolchain for Fedora 35.
If you want to be outraged at FESCo about this, then read the meeting log first[1].
My main point then is that *all* of the Change authors are upstream developers in the GNU Toolchain, meaning that they have to do maintenance effort around Guile support upstream anyway.
That is not how upstreams work, I'm an upstream kernel maintainer that does not mean that I'm responsible for every feature which the kernel has. Just become some upstream make maintainers care about guile support enough to keep it alive upstream does not mean that the Fedora toolchain people work on it upstream.
Also upstream maintenance != package maintenance. AFAIK having the guile dep in make leads to circular deps causing a whole bunch of work to update to a version which breaks the soname/ABI, as well as causing pain for bootstrapping. IOW even if the feature is 100% ready to go upstream there still is a downstream price to pay for enabling it.
If they want to remove a feature that makes Fedora the best place to use the GNU Toolchain, they should do it upstream first.
And again you are telling other people what they should do, last time I checked Fesco was supposed to be about policy, not telling other people what they should do.
With this same logic the Fedora kernel MUST support every feature which the upstream kernel supports, even features which the Fedora kernel maintainers explicitly do not want to support. Or for that matter every Fedora package MUST support every feature which upstream of that package support. Last time I checked we left such decisions to the package-maintainers.
I did not find their argumentation persuasive because they used arguments that should be applied upstream and Fedora is not a special case for any of those.
I don't personally *care* much about Guile support beyond the fact I have a few private projects that use it in Makefiles, so it'd be annoying if it was gone. And I was comfortable with being overruled in my objections. I stated as much in the meeting even!
The fact was, the GNU Toolchain developers:
- Did not show up to that FESCo meeting to try to persuade the rest
of the group to vote against me. 2. Did not consider either alternative I proposed (remove it upstream, split guile support out in some way)
It was *barely* rejected by virtue of not reaching a majority vote to pass. If they want to propose it again, then be my guest.
Maybe if the GNU Toolchain developers did not show up and there was no majority, then the right thing to do for Fesco would have been to postpone the decision and invite them to join the next meeting to discuss this? That would have been a much better decision then rejecting based on there not being a majority for approving.
Actually it seems to me that that would have been the only right thing to do. Rejecting by default when there is no quorum seems like a weird thing to do for Change proposals.
In my experience with the change process Fesco does not pro-activily invite Change proposal owners to show up during the meeting where discussing the Change has been put on the agenda, combining not actively inviting them with blaming change owners for not being there as you do above seems weird.
Regards,
Hans
On Wed, 7 Jul 2021 at 08:54, Hans de Goede hdegoede@redhat.com wrote:
Hi,
Maybe if the GNU Toolchain developers did not show up and there was no majority, then the right thing to do for Fesco would have been to postpone the decision and invite them to join the next meeting to discuss this? That would have been a much better decision then rejecting based on there not being a majority for approving.
Actually it seems to me that that would have been the only right thing to do. Rejecting by default when there is no quorum seems like a weird thing to do for Change proposals.
In my experience with the change process Fesco does not pro-activily invite Change proposal owners to show up during the meeting where discussing the Change has been put on the agenda, combining not actively inviting them with blaming change owners for not being there as you do above seems weird.
I believe there is an 'unspoken' expectation that if you propose a change, you are responsible for that change and go to various FESCO meetings until the change is acted on. I don't like 'unspoken/unwritten' expectations but I am guessing it has worked for FESCO because it is rare when I have sat in on Change Requests that the people proposing things aren't there. It would be better if
A) Expectations and responsibilities of change owners were written out. B) Powers of FESCO to tell or not tell people what they are to work on were written out. C) This proposal was reviewed and pushed again for F35 even if it is 'too late' because well this just doesn't sit well.
* Stephen John Smoogen:
C) This proposal was reviewed and pushed again for F35 even if it is 'too late' because well this just doesn't sit well.
This doesn't make sense to me—what is “this proposal”, and how it was “pushed again”?
Thanks, Florian
On Wed, 7 Jul 2021 at 11:45, Florian Weimer fweimer@redhat.com wrote:
- Stephen John Smoogen:
C) This proposal was reviewed and pushed again for F35 even if it is 'too late' because well this just doesn't sit well.
This doesn't make sense to me—what is “this proposal”, and how it was “pushed again”?
Sorry.. my brain seems to have rebooted while typing that.
1. I thought I was responding to the discussion on https://pagure.io/fesco/issue/2558 2. It should have read " This proposal ( https://pagure.io/fesco/issue/2558 ) needs to be reviewed and pushed again for F35 even if it is 'too late' for proposals. The original decision just doesn't sit well with me in telling people to do things."
I hope that clarifies things.
Thanks, Florian
* Stephen John Smoogen:
On Wed, 7 Jul 2021 at 11:45, Florian Weimer fweimer@redhat.com wrote:
- Stephen John Smoogen:
C) This proposal was reviewed and pushed again for F35 even if it is 'too late' because well this just doesn't sit well.
This doesn't make sense to me—what is “this proposal”, and how it was “pushed again”?
Sorry.. my brain seems to have rebooted while typing that.
- I thought I was responding to the discussion on
https://pagure.io/fesco/issue/2558 2. It should have read " This proposal ( https://pagure.io/fesco/issue/2558 ) needs to be reviewed and pushed again for F35 even if it is 'too late' for proposals. The original decision just doesn't sit well with me in telling people to do things."
I hope that clarifies things.
Indeed. I originally read it as opposition to re-submission of the change (and I could see that submitting a proposal over and over again until it passes could be a problem).
Thanks, Florian
On Wed, Jul 07, 2021 at 01:38:18PM +0200, Hans de Goede wrote:
Hi,
On 7/7/21 1:08 PM, Florian Weimer wrote:
- Neal Gompa:
Wait, why don't we have guile 3.0?
We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult.
So I've gone and checked the Fesco issue where dropping guile support from make + gdb was discussed:
I'm especially shocked about how Fesco is in essence mandating a group of maintainers to spend time maintaining a feature where they clearly have indicated they don't want to maintain that feature.
[snip]
I urge Fesco to reconsider this and I suggest that we (Fedora) take another serious look at implementing: https://fedoraproject.org/wiki/Changes/RemoveGuileFromToolchain for Fedora 35.
What's notable to me is that, generally speaking, maintainers use their own discretion as to which optional features they enable or disable with a package built in Fedora. I'd expect that in most cases similar to this a maintainer will just disable the feature, do a koji build, and never tell anyone, nor ask for permission. Package maintainers do this all the time, even dropping builds for entire architectures without telling anyone beforehand even though there are users / dependant packages.
In this case the maintainers are effectively being penalized for trying to proactively alert users to a change, that probably doesn't impact many/any users in the first place.
This serves to discourage other maintainers from even making a feature change page in future, lest they be rejected. The safer course of action is to just silently disable the feature, and then ask for forgiveness later in the unlikely event anyone complains.
Regards, Daniel
* Daniel P. Berrangé:
What's notable to me is that, generally speaking, maintainers use their own discretion as to which optional features they enable or disable with a package built in Fedora. I'd expect that in most cases similar to this a maintainer will just disable the feature, do a koji build, and never tell anyone, nor ask for permission. Package maintainers do this all the time, even dropping builds for entire architectures without telling anyone beforehand even though there are users / dependant packages.
In this case the maintainers are effectively being penalized for trying to proactively alert users to a change, that probably doesn't impact many/any users in the first place.
This serves to discourage other maintainers from even making a feature change page in future, lest they be rejected. The safer course of action is to just silently disable the feature, and then ask for forgiveness later in the unlikely event anyone complains.
Yes, this thought has crossed my mind as well.
There are definitely much more impactful changes we make upstream, and at most, Fesco gets to rubber-stamp them. So the balance seems rather off here.
Thanks, Florian
On 07. 07. 21 13:38, Hans de Goede wrote:
Hi,
On 7/7/21 1:08 PM, Florian Weimer wrote:
- Neal Gompa:
Wait, why don't we have guile 3.0?
We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult.
So I've gone and checked the Fesco issue where dropping guile support from make + gdb was discussed:
https://pagure.io/fesco/issue/2558
And I must say that I find the argumentation for rejecting the change very very weak. I would really expect Fesco to make better motivated decisions then this one.
I'm especially shocked about how Fesco is in essence mandating a group of maintainers to spend time maintaining a feature where they clearly have indicated they don't want to maintain that feature.
My being shocked here is not so much about the guile issue, but about a IMHO much bigger issue underlying this decision:
Since when does Fesco get to mandate on which features our volunteer maintainers get to spend there time ?
I understand there need to be rules and I can understand Fesco denying approval for enabling / adding certain features for a wide set of reasons, thus in essence blocking volunteers from spending time on something because that something is deemed undesirable for Fedora.
But this is different here Fesco is telling a group of maintainers that they must maintain a feature even though they have indicated that they find the benefits of that feature not worth the amount of time it costs to maintain support for that feature. So in essence Fesco is telling the maintainers that they MUST spend time maintaining this even though they don't want this.
IMHO this is just outrageous and goes way way beyond the purview of Fesco.
Now if dropping this feature would cause major breakage this would a different story, But in the whole discussion about this, at least as documented in the Fesco issue, no actual users of this feature have been indentified and nothing will break by disabling this as far is is known. So since there is no known breakage caused by this, I end up circling back to this basically telling Fesco that the make/gdb timers MUST spend them on maintaining this even though they don't want to (and have good reasons for not wanting to).
Which again, is IHMO pretty outrageous really.
Sorry Fesco, I know that you all do a lot of (hard) work as Fesco members and do your best when making decisions like this; and I don't doubt that your intentions where well, but you made a big booboo here (IMHO).
I urge Fesco to reconsider this and I suggest that we (Fedora) take another serious look at implementing: https://fedoraproject.org/wiki/Changes/RemoveGuileFromToolchain for Fedora 35.
Thanks for the honest feedback for FESCo. As a FESCo member, I need to say several things.
I agree that this should be reconsidered. IIRC the problem I personally had with the proposal is that I find one of the benefits listed in the proposal confusing ("This proposal will help shrink the buildroot").
I agree with you that FESCo has no business in telling packagers "you MUST continue supporting this". That's why I said in the meeting about this:
""" 15:21:07 <mhroncok> I don't feel this benefits Fedora much, but I won't block the maintainers to make a decision that doe snot affect other packages """
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-02-03/fesco.2021-02-...
When this change proposal was rejected, it didn't necessarily mean FESCo "demanded Guile support in Make stays". Instead it meant that FESCo is not confident to approve the change proposal as presented to FESCo. I don't consider that outrageous. Proposals have been adapted in the past.
Also note that the vote was very close (the change proposal got +4 votes and needed +5). The current members of FESCo are different (at least a bit) and hence today, the vote might have been different. I think it is OK if FESCo decisions are re-evaluated in time: sometimes circumstances change, sometimes FESCo members change.
* Hans de Goede:
Hi,
On 7/7/21 1:08 PM, Florian Weimer wrote:
- Neal Gompa:
Wait, why don't we have guile 3.0?
We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult.
So I've gone and checked the Fesco issue where dropping guile support from make + gdb was discussed:
https://pagure.io/fesco/issue/2558
And I must say that I find the argumentation for rejecting the change very very weak. I would really expect Fesco to make better motivated decisions then this one.
I'm especially shocked about how Fesco is in essence mandating a group of maintainers to spend time maintaining a feature where they clearly have indicated they don't want to maintain that feature.
I guess this is partly on us (on the toolchain side). We missed the meeting, and no one pointed out that the make change in particular meant that instead of writing $(guile …), the user arguing for this feature would have to write $(shell guile …). The make/Guile integration is simply not very deep. It's not that you can rewrite recipes, have access to the dependency engine, or anything like that.
(There is deeper integration for GDB, but no one seemed to be concerned about that for some reason.)
My being shocked here is not so much about the guile issue, but about a IMHO much bigger issue underlying this decision:
Since when does Fesco get to mandate on which features our volunteer maintainers get to spend there time ?
Most of us Fedora toolchain maintainers aren't volunteers in the actual sense of the word, so we shouldn't play the volunteer card (and Fesco probably knew this too). I know that several members of the Red Hat Platform Tools team (who maintain the toolchain downstream) have Fedora work as goals or key responsibilities.
We removed Guile from the downstream toolchain, and we wanted to upstream this change, and that didn't work out. As far as I know, this did not have any consequence how Fedora work on the affected components is treated by the relevant maintainers' managers. (They didn't turn volunteers over night.)
I think that in general, if community requirements diverge this way, we just consider it the cost of doing business. Clearly there is no tangible return on investment for this kind of work, it's just something that has to be done, given how the productization work for Red Hat Enterprise Linux is structured. In this particular instance, the cost isn't particularly high, so we moved on.
Obviously I disagree with Fesco's decision, but I don't think it matters that much in the grand scheme of things.
Now if dropping this feature would cause major breakage this would a different story, But in the whole discussion about this, at least as documented in the Fesco issue, no actual users of this feature have been indentified and nothing will break by disabling this as far is is known.
One user showed up in the Fesco meeting, and because we weren't there, that was enough to block the change. I don't have a link to the IRC minutes right now, but I remember reviewing them after the fact.
Thanks, Florian
On Wed, Jul 7, 2021 at 8:14 AM Florian Weimer fweimer@redhat.com wrote:
- Hans de Goede:
Hi,
On 7/7/21 1:08 PM, Florian Weimer wrote:
- Neal Gompa:
Wait, why don't we have guile 3.0?
We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult.
So I've gone and checked the Fesco issue where dropping guile support from make + gdb was discussed:
https://pagure.io/fesco/issue/2558
And I must say that I find the argumentation for rejecting the change very very weak. I would really expect Fesco to make better motivated decisions then this one.
I'm especially shocked about how Fesco is in essence mandating a group of maintainers to spend time maintaining a feature where they clearly have indicated they don't want to maintain that feature.
I guess this is partly on us (on the toolchain side). We missed the meeting, and no one pointed out that the make change in particular meant that instead of writing $(guile …), the user arguing for this feature would have to write $(shell guile …). The make/Guile integration is simply not very deep. It's not that you can rewrite recipes, have access to the dependency engine, or anything like that.
If I had known that, I would have voted differently. If using Guile in Make is trivial even without the native support, then documenting how to do it would have been fine. I assumed it was like how GDB's integration works, where you can instrument the tool itself.
(There is deeper integration for GDB, but no one seemed to be concerned about that for some reason.)
I have not seen any Guile usage for instrumenting GDB. Everyone uses Python. So, this didn't really bother me. For Make, there was no other option, and I didn't know the Guile integration wasn't much of one that could be replaced with a shell exec.
If you were dropping *both* Guile and Python, we would have words. :)
-- 真実はいつも一つ！/ Always, there's only one truth!
Hi,
On 7/7/21 2:14 PM, Florian Weimer wrote:
- Hans de Goede:
Hi,
On 7/7/21 1:08 PM, Florian Weimer wrote:
- Neal Gompa:
Wait, why don't we have guile 3.0?
We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult.
So I've gone and checked the Fesco issue where dropping guile support from make + gdb was discussed:
https://pagure.io/fesco/issue/2558
And I must say that I find the argumentation for rejecting the change very very weak. I would really expect Fesco to make better motivated decisions then this one.
I'm especially shocked about how Fesco is in essence mandating a group of maintainers to spend time maintaining a feature where they clearly have indicated they don't want to maintain that feature.
I guess this is partly on us (on the toolchain side). We missed the meeting
Yes that was less then ideal OTOH since there was no majority to either reject or accept it would have been better IMHO for Fesco to simply postpone the decision and explicitly invite you for the next meeting.
<snip>
My being shocked here is not so much about the guile issue, but about a IMHO much bigger issue underlying this decision:
Since when does Fesco get to mandate on which features our volunteer maintainers get to spend there time ?
Most of us Fedora toolchain maintainers aren't volunteers in the actual sense of the word, so we shouldn't play the volunteer card (and Fesco probably knew this too). I know that several members of the Red Hat Platform Tools team (who maintain the toolchain downstream) have Fedora work as goals or key responsibilities.
Right, I knew that already, but IMHO that only makes this Fesco decision worse, if you were true volunteers you could choose to simply walk away (which even for volunteers is not an easy decission, but it is a real option) where as now you are stuck between a rock and a hard place, which I see as worse then the pure volunteer situation.
I think it is great how you are simply taking this in stride, if I were in your shoes I would certainly be very unhappy about this.
Anyways Neal and Miro have indicated that they would be happy to revisit this for Fedora 35, so I think the best way forward here is to resubmit the change for Fedora 35, you can still do this until 2021-07-20 .
Regards,
Hans
On Wed, Jul 07, 2021 at 03:09:47PM +0200, Hans de Goede wrote:
Hi,
On 7/7/21 2:14 PM, Florian Weimer wrote:
- Hans de Goede:
Hi,
On 7/7/21 1:08 PM, Florian Weimer wrote:
- Neal Gompa:
Wait, why don't we have guile 3.0?
We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult.
So I've gone and checked the Fesco issue where dropping guile support from make + gdb was discussed:
https://pagure.io/fesco/issue/2558
And I must say that I find the argumentation for rejecting the change very very weak. I would really expect Fesco to make better motivated decisions then this one.
I'm especially shocked about how Fesco is in essence mandating a group of maintainers to spend time maintaining a feature where they clearly have indicated they don't want to maintain that feature.
I guess this is partly on us (on the toolchain side). We missed the meeting
Yes that was less then ideal OTOH since there was no majority to either reject or accept it would have been better IMHO for Fesco to simply postpone the decision and explicitly invite you for the next meeting.
I wonder if the process we're following (as it is defined today) is actually beneficial for self-contained changes ? Did having a vote which rejected the change actually improve Fedora, or was it just busy work that is better eliminated in the common/simple case ?
The announcement of the change on this list resulted in minimal discussion and no show stopper objections. The points raised in the FESCo meeting could have just been discussion in the change announcement email thread. Did we actually need an interactive meeting for it at a specific time where only a tiny set of people are actually present to participate ?
Any time there is a voting process, people are divided into winners/loosers. Even if the vote rejects something through a technicality, that can easily leave a negative impression. In most communities I work in, the need to apply something as formal as voting would be considered a failure. Agreement should be achieved through discussion, so we don't formally divide people. Voting a last resort only when discussion fails to come to acceptable consensus.
None the less I can see value in formal FESCo approval for system-wide changes that have a broad impact across the distro. In that area FESCo is not so much acting as a gate keeper, but rather as the designated leadership for the project's overall technical vision/direction.
I'm far less convinced FESCo formally voting is beneficial for (uncontroversial) self-contained changes, where the goal of the maintainer is largely just to make sure people have awareness of what's coming down the pipe.
Is there scope for having self-contained changes implicitly approved 2 weeks after being posted to Fedora devel list in absence of controversy ? In that 2 week period, if someone raises an objection that does not get a satisfactorily resolved through discussion, they could raise an explicit request for a FESCo vote on the change as a last resort.
Regards, Daniel
On Wed, Jul 7, 2021 at 9:38 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Wed, Jul 07, 2021 at 03:09:47PM +0200, Hans de Goede wrote:
Hi,
On 7/7/21 2:14 PM, Florian Weimer wrote:
- Hans de Goede:
Hi,
On 7/7/21 1:08 PM, Florian Weimer wrote:
- Neal Gompa:
Wait, why don't we have guile 3.0?
We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult.
So I've gone and checked the Fesco issue where dropping guile support from make + gdb was discussed:
https://pagure.io/fesco/issue/2558
And I must say that I find the argumentation for rejecting the change very very weak. I would really expect Fesco to make better motivated decisions then this one.
I'm especially shocked about how Fesco is in essence mandating a group of maintainers to spend time maintaining a feature where they clearly have indicated they don't want to maintain that feature.
I guess this is partly on us (on the toolchain side). We missed the meeting
Yes that was less then ideal OTOH since there was no majority to either reject or accept it would have been better IMHO for Fesco to simply postpone the decision and explicitly invite you for the next meeting.
I wonder if the process we're following (as it is defined today) is actually beneficial for self-contained changes ? Did having a vote which rejected the change actually improve Fedora, or was it just busy work that is better eliminated in the common/simple case ?
There are three major purposes for Changes:
1. Marketing 2. Transparency 3. Coordination
Every time a Change gets proposed, we get the benefit of all three. For sure, there are plenty of things that happen in Fedora releases that don't go through this process, but increasingly people are leveraging the benefits of this process to support their work. A huge part of why Fedora is considered an innovative, well-run open source project is because of this.
The announcement of the change on this list resulted in minimal discussion and no show stopper objections. The points raised in the FESCo meeting could have just been discussion in the change announcement email thread. Did we actually need an interactive meeting for it at a specific time where only a tiny set of people are actually present to participate ?
Any time there is a voting process, people are divided into winners/loosers. Even if the vote rejects something through a technicality, that can easily leave a negative impression. In most communities I work in, the need to apply something as formal as voting would be considered a failure. Agreement should be achieved through discussion, so we don't formally divide people. Voting a last resort only when discussion fails to come to acceptable consensus.
None the less I can see value in formal FESCo approval for system-wide changes that have a broad impact across the distro. In that area FESCo is not so much acting as a gate keeper, but rather as the designated leadership for the project's overall technical vision/direction.
This is often a matter of perspective. I won't go into how much hell I went through last year with my changes in Fedora Linux 33. It worked out in the end because I was patient and actively communicating with everyone, but I can definitely say that was not a fun experience. But it was *important* because the end result is that we have a solid platform.
I'm far less convinced FESCo formally voting is beneficial for (uncontroversial) self-contained changes, where the goal of the maintainer is largely just to make sure people have awareness of what's coming down the pipe.
It can seem like that at first glance and then turn out to not be so. That was the case with the debuginfod Change[1]. I was not the one that slowed that Change down, in fact I was *very* enthusiastic about it. However, Zbigniew had concerns[1] that led to further development upstream that made a better feature overall for when it was finally approved.
[0]: https://fedoraproject.org/wiki/Changes/DebuginfodByDefault [1]: https://pagure.io/fesco/issue/2597#comment-728404
Is there scope for having self-contained changes implicitly approved 2 weeks after being posted to Fedora devel list in absence of controversy ? In that 2 week period, if someone raises an objection that does not get a satisfactorily resolved through discussion, they could raise an explicit request for a FESCo vote on the change as a last resort.
We lazy approve after three weeks of no objections from the time it was posted to the list. This is true for both system-wide and self-contained changes.
That is not what happened with this change. I objected in the original thread[2], and my concerns were not satisfactorily resolved on-list, so I objected again in the issue[3].
I stated in the meeting discussion[4] that I was okay with being overruled, but I still felt strongly enough about it to object. Nobody brought up any information that would have changed my mind then or convinced everyone else strongly to overrule my objection.
Now I learn that folks using Guile integration actually *can* still use their Makefiles in Make-without-Guile with minimal tweaks, so now I don't care, and we would probably approve it if it were proposed again.
[2]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [3]: https://pagure.io/fesco/issue/2558 [4]: https://meetbot.fedoraproject.org/teams/fesco/fesco.2021-02-03-15.00.log.htm...
On Wed, Jul 07, 2021 at 09:56:43AM -0400, Neal Gompa wrote:
On Wed, Jul 7, 2021 at 9:38 AM Daniel P. Berrangé berrange@redhat.com wrote:
I'm far less convinced FESCo formally voting is beneficial for (uncontroversial) self-contained changes, where the goal of the maintainer is largely just to make sure people have awareness of what's coming down the pipe.
It can seem like that at first glance and then turn out to not be so. That was the case with the debuginfod Change[1]. I was not the one that slowed that Change down, in fact I was *very* enthusiastic about it. However, Zbigniew had concerns[1] that led to further development upstream that made a better feature overall for when it was finally approved.
The concerns Zbigniew mentions there deserved answers. Did those answers need to be obtained in a formal interactive FESCo meeting, as opposed to being handled on fedora-devel. The information and discussion about the change ended up split across fedora-devel, the meeting IRC logs, and the pagure ticket. Just feels like an uncessary complication to me looking in, and makes it harder to follow the discussion after the fact due to the split of forums.
Is there scope for having self-contained changes implicitly approved 2 weeks after being posted to Fedora devel list in absence of controversy ? In that 2 week period, if someone raises an objection that does not get a satisfactorily resolved through discussion, they could raise an explicit request for a FESCo vote on the change as a last resort.
We lazy approve after three weeks of no objections from the time it was posted to the list. This is true for both system-wide and self-contained changes.
Maybe I'm mis-understanding what you mean by lazy approved ? My understanding was that everything ends up with a formal FESCo ticket created from the moment the change is published and thus gets voted on ?
Regards, Daniel
On Wed, Jul 7, 2021 at 10:46 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Wed, Jul 07, 2021 at 09:56:43AM -0400, Neal Gompa wrote:
On Wed, Jul 7, 2021 at 9:38 AM Daniel P. Berrangé berrange@redhat.com wrote:
I'm far less convinced FESCo formally voting is beneficial for (uncontroversial) self-contained changes, where the goal of the maintainer is largely just to make sure people have awareness of what's coming down the pipe.
It can seem like that at first glance and then turn out to not be so. That was the case with the debuginfod Change[1]. I was not the one that slowed that Change down, in fact I was *very* enthusiastic about it. However, Zbigniew had concerns[1] that led to further development upstream that made a better feature overall for when it was finally approved.
The concerns Zbigniew mentions there deserved answers. Did those answers need to be obtained in a formal interactive FESCo meeting, as opposed to being handled on fedora-devel. The information and discussion about the change ended up split across fedora-devel, the meeting IRC logs, and the pagure ticket. Just feels like an uncessary complication to me looking in, and makes it harder to follow the discussion after the fact due to the split of forums.
Is there scope for having self-contained changes implicitly approved 2 weeks after being posted to Fedora devel list in absence of controversy ? In that 2 week period, if someone raises an objection that does not get a satisfactorily resolved through discussion, they could raise an explicit request for a FESCo vote on the change as a last resort.
We lazy approve after three weeks of no objections from the time it was posted to the list. This is true for both system-wide and self-contained changes.
Maybe I'm mis-understanding what you mean by lazy approved ? My understanding was that everything ends up with a formal FESCo ticket created from the moment the change is published and thus gets voted on ?
If there are no "-1" votes, it gets accepted.
On 07. 07. 21 17:01, Neal Gompa wrote:
Is there scope for having self-contained changes implicitly approved 2 weeks after being posted to Fedora devel list in absence of controversy ? In that 2 week period, if someone raises an objection that does not get a satisfactorily resolved through discussion, they could raise an explicit request for a FESCo vote on the change as a last resort.
We lazy approve after three weeks of no objections from the time it was posted to the list. This is true for both system-wide and self-contained changes.
Maybe I'm mis-understanding what you mean by lazy approved ? My understanding was that everything ends up with a formal FESCo ticket created from the moment the change is published and thus gets voted on ?
If there are no "-1" votes, it gets accepted.
Technically, it still requires at least one +1.
On Wed, Jul 7, 2021 at 9:38 AM Daniel P. Berrangé berrange@redhat.com wrote:
I wonder if the process we're following (as it is defined today) is actually beneficial for self-contained changes ? Did having a vote which rejected the change actually improve Fedora, or was it just busy work that is better eliminated in the common/simple case ?
I've given a lot of thought to an "announcement-only Change" path in the last three years. There are definitely cases where increased visibility would help (particularly in the release notes and release announcement that Matthew writes). There are a few reasons I haven't done anything with that yet:
* I don't think it would reduce the overhead much. The FESCo vote is generally no burden on the Change owner. The rest of the process would still be in place, so I doubt we'd see any meaningful increase in use of the process. * Escalating to "needs a vote" becomes messy. Is there a magic phrase that needs to be said? That's a burden on the community who now have to remember to say the right words. It also leaves us open to me missing the use of the magic phrase. If we don't have a magic phrase, then someone may think they've objected sufficiently to a proposal and then being surprised when it gets auto-approved. * It adds another path to the Changes process. Ideally, changes to the process should simplify, not add more complexity.
I'm definitely open to changes to the Changes process. I'm just not sure this specific approach is necessary. The issue we're discussing is rare—I don't recall another case like it in the three years I've been in this role—and I'm generally reluctant to change processes to address edge cases.
The announcement of the change on this list resulted in minimal discussion and no show stopper objections. The points raised in the FESCo meeting could have just been discussion in the change announcement email thread. Did we actually need an interactive meeting for it at a specific time where only a tiny set of people are actually present to participate ?
It wouldn't have even come up in a meeting except there were a couple of FESCo members opposed to it. If we're going to change processes, perhaps the better change is to explicitly invite people to the meeting when their Change proposal is on the agenda.
-- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis
* Ben Cotton:
It wouldn't have even come up in a meeting except there were a couple of FESCo members opposed to it. If we're going to change processes, perhaps the better change is to explicitly invite people to the meeting when their Change proposal is on the agenda.
It probably would have helped in our case. I knew that someone from the toolchain side should attend the discussion, but I got distracted and forgot to check the meeting agenda during the critical week.
Does Pagure send notification email on label changes? Could that be a way to notice an upcoming meeting?
Thanks, Florian
On Wed, Jul 7, 2021 at 10:20 AM Florian Weimer fweimer@redhat.com wrote:
- Ben Cotton:
It wouldn't have even come up in a meeting except there were a couple of FESCo members opposed to it. If we're going to change processes, perhaps the better change is to explicitly invite people to the meeting when their Change proposal is on the agenda.
It probably would have helped in our case. I knew that someone from the toolchain side should attend the discussion, but I got distracted and forgot to check the meeting agenda during the critical week.
Does Pagure send notification email on label changes? Could that be a way to notice an upcoming meeting?
It can be configured to do so on a per-project basis. We probably should have it do that for the fesco project.
On Wed, Jul 7, 2021 at 10:23 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Jul 7, 2021 at 10:20 AM Florian Weimer fweimer@redhat.com wrote:
Does Pagure send notification email on label changes? Could that be a way to notice an upcoming meeting?
It can be configured to do so on a per-project basis. We probably should have it do that for the fesco project.
I'm glad you answered before I did, because I'd have said "no it doesn't" :-)
I agree that enabling it for the fesco project would be good. It's probably insufficient, though. When the meeting chair sends the agenda, adding the owners on cc or bcc so that they get reminded of time/location/etc is important.
On Wed, Jul 7, 2021 at 10:25 AM Ben Cotton bcotton@redhat.com wrote:
On Wed, Jul 7, 2021 at 10:23 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Jul 7, 2021 at 10:20 AM Florian Weimer fweimer@redhat.com wrote:
Does Pagure send notification email on label changes? Could that be a way to notice an upcoming meeting?
It can be configured to do so on a per-project basis. We probably should have it do that for the fesco project.
I'm glad you answered before I did, because I'd have said "no it doesn't" :-)
I agree that enabling it for the fesco project would be good. It's probably insufficient, though. When the meeting chair sends the agenda, adding the owners on cc or bcc so that they get reminded of time/location/etc is important.
That gets into "we need to script the meeting announcement notice" territory. :)
Ben Cotton bcotton@redhat.com writes:
[...] I agree that enabling it for the fesco project would be good. It's probably insufficient, though. When the meeting chair sends the agenda, adding the owners on cc or bcc so that they get reminded of time/location/etc is important.
Since this gets overlooked with some regularity, a mechanical way of getting notified / invited to relevant fesco meetings should be a priority.
- FChE
On Wed, Jul 07, 2021 at 03:31:21PM -0400, Frank Ch. Eigler wrote:
Ben Cotton bcotton@redhat.com writes:
[...] I agree that enabling it for the fesco project would be good. It's probably insufficient, though. When the meeting chair sends the agenda, adding the owners on cc or bcc so that they get reminded of time/location/etc is important.
Since this gets overlooked with some regularity, a mechanical way of getting notified / invited to relevant fesco meetings should be a priority.
well, we have:
https://fedoraproject.org/wiki/FESCo_meeting_process
"Make sure to check with and invite stakeholders who may not be CC'd in the issue. Consider deferring issue if stakeholders have not had adequate notice and are not available for discussion."
Perhaps it should be more explicit in how to "check with and invite"?
kevin
Kevin Fenzi kevin@scrye.com writes:
https://fedoraproject.org/wiki/FESCo_meeting_process
"Make sure to check with and invite stakeholders who may not be CC'd in the issue. Consider deferring issue if stakeholders have not had adequate notice and are not available for discussion."
Perhaps it should be more explicit in how to "check with and invite"?
Not sure about that cc:-on-the-issue condition. There appears to be no systematic notification *in the issue* that the topic is on the next agenda, so people on the cc: list are not automatically invited. There's also no notification in the wiki Change page, so those watching that don't know either. Can this get fixed? Those two bits of extra process might be enough to ensure that change proponents feel invited.
- FChE
On Wed, Jul 07, 2021 at 09:58:56PM -0400, Frank Ch. Eigler wrote:
Kevin Fenzi kevin@scrye.com writes:
https://fedoraproject.org/wiki/FESCo_meeting_process
"Make sure to check with and invite stakeholders who may not be CC'd in the issue. Consider deferring issue if stakeholders have not had adequate notice and are not available for discussion."
Perhaps it should be more explicit in how to "check with and invite"?
Not sure about that cc:-on-the-issue condition. There appears to be no systematic notification *in the issue* that the topic is on the next agenda, so people on the cc: list are not automatically invited. There's also no notification in the wiki Change page, so those watching that don't know either. Can this get fixed? Those two bits of extra process might be enough to ensure that change proponents feel invited.
I meant to bring this up at todays meeting, but forgot. ;(
I think it is a good idea to change the meeting process to add a comment that the issue will be discussed at the next meeting as part of putting together the agenda. I suppose we could make a null commit to the wiki page about it, but I am less convinced thats useful. Wiki watches are pretty useless because they only tell you about the very next commit and then go away. :(
I'm out next week, but I filed https://pagure.io/fesco/issue/2646 to amend the process.
kevin
On Wed, Jul 7, 2021 at 10:22 AM Ben Cotton bcotton@redhat.com wrote:
On Wed, Jul 7, 2021 at 9:38 AM Daniel P. Berrangé berrange@redhat.com wrote:
I wonder if the process we're following (as it is defined today) is actually beneficial for self-contained changes ? Did having a vote which rejected the change actually improve Fedora, or was it just busy work that is better eliminated in the common/simple case ?
I've given a lot of thought to an "announcement-only Change" path in the last three years. There are definitely cases where increased visibility would help (particularly in the release notes and release announcement that Matthew writes). There are a few reasons I haven't done anything with that yet:
- I don't think it would reduce the overhead much. The FESCo vote is
generally no burden on the Change owner. The rest of the process would still be in place, so I doubt we'd see any meaningful increase in use of the process.
- Escalating to "needs a vote" becomes messy. Is there a magic phrase
that needs to be said? That's a burden on the community who now have to remember to say the right words. It also leaves us open to me missing the use of the magic phrase. If we don't have a magic phrase, then someone may think they've objected sufficiently to a proposal and then being surprised when it gets auto-approved.
- It adds another path to the Changes process. Ideally, changes to the
process should simplify, not add more complexity.
I'm definitely open to changes to the Changes process. I'm just not sure this specific approach is necessary. The issue we're discussing is rare—I don't recall another case like it in the three years I've been in this role—and I'm generally reluctant to change processes to address edge cases.
The announcement of the change on this list resulted in minimal discussion and no show stopper objections. The points raised in the FESCo meeting could have just been discussion in the change announcement email thread. Did we actually need an interactive meeting for it at a specific time where only a tiny set of people are actually present to participate ?
It wouldn't have even come up in a meeting except there were a couple of FESCo members opposed to it. If we're going to change processes, perhaps the better change is to explicitly invite people to the meeting when their Change proposal is on the agenda.
I assumed we already did this. That's why I made sure to remind the co-owners of my Changes about it. If we don't, that's definitely a failure that we should fix.
On Wed, Jul 7, 2021 at 1:38 PM Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 7/7/21 1:08 PM, Florian Weimer wrote:
- Neal Gompa:
Wait, why don't we have guile 3.0?
We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult.
So I've gone and checked the Fesco issue where dropping guile support from make + gdb was discussed:
https://pagure.io/fesco/issue/2558
And I must say that I find the argumentation for rejecting the change very very weak. I would really expect Fesco to make better motivated decisions then this one.
I'm especially shocked about how Fesco is in essence mandating a group of maintainers to spend time maintaining a feature where they clearly have indicated they don't want to maintain that feature.
My being shocked here is not so much about the guile issue, but about a IMHO much bigger issue underlying this decision:
Since when does Fesco get to mandate on which features our volunteer maintainers get to spend there time ?
I understand there need to be rules and I can understand Fesco denying approval for enabling / adding certain features for a wide set of reasons, thus in essence blocking volunteers from spending time on something because that something is deemed undesirable for Fedora.
But this is different here Fesco is telling a group of maintainers that they must maintain a feature even though they have indicated that they find the benefits of that feature not worth the amount of time it costs to maintain support for that feature. So in essence Fesco is telling the maintainers that they MUST spend time maintaining this even though they don't want this.
IMHO this is just outrageous and goes way way beyond the purview of Fesco.
Now if dropping this feature would cause major breakage this would a different story, But in the whole discussion about this, at least as documented in the Fesco issue, no actual users of this feature have been indentified and nothing will break by disabling this as far is is known. So since there is no known breakage caused by this, I end up circling back to this basically telling Fesco that the make/gdb timers MUST spend them on maintaining this even though they don't want to (and have good reasons for not wanting to).
Which again, is IHMO pretty outrageous really.
Sorry Fesco, I know that you all do a lot of (hard) work as Fesco members and do your best when making decisions like this; and I don't doubt that your intentions where well, but you made a big booboo here (IMHO).
I urge Fesco to reconsider this and I suggest that we (Fedora) take another serious look at implementing: https://fedoraproject.org/wiki/Changes/RemoveGuileFromToolchain for Fedora 35.
I feel like I need to chime in here as a FESco member who was part of this decision.
As others have already mentioned in this thread, this change was Rejected by the smallest possible margin, with four +1 votes, two abstentions, and two -1 votes, while it needed five +1 votes to pass.
As I was one of the two "±0" votes: My reason for not voting +1 was that impact analysis was only based on anecdata, if at all - either "popcon data from debian shows that almost nobody has make-guile installed", or "I can't believe anybody actually uses this", but no actual analysis was done - which, for a central package like make, would be important, IMO. The stated reason of "we don't want to maintain this" was also weak, since the developers still maintain the guile support upstream, and if this was really in preparation for dropping guile support from ELN / RHEL 9 via a Change in Fedora 34, that was not really a good reason to "just do it in Fedora first" either.
However, you are right - FESCo cannot "force" anybody to maintain anything, but the change proposal was sufficiently "weak" that it was - barely - not accepted. But I think almost any package maintainer in Fedora would actually *look if any optional feature is actually used* before just silently dropping it from their package, or at least notify maintainers of dependent packages that feature X was considered for removal. I don't see this case any different, just that make is a more prominent package than most.
So: I'd like to see actual investigation into whether the guile support is actually used in any Fedora package, and if it's going to be removed, it should be removed upstream first. If it turns out that really actually nobody uses this, why not drop it upstream, and have the guile support removal come with the next GNU toolchain Change for Fedora?
Fabio
* Fabio Valentini:
If it turns out that really actually nobody uses this, why not drop it upstream, and have the guile support removal come with the next GNU toolchain Change for Fedora?
Guile support in GNU packages is a goal of the GNU project, I think. Where Guile is used as a scripting language for a larger program, its use is generally optional. And it is unlikely that this optional support will be removed upstream.
Given that, “do what upstream does” doesn't really help to solve settle the matter in Fedora.
Thanks, Florian
On Wed, Jul 07, 2021 at 02:27:39PM +0200, Florian Weimer wrote:
- Fabio Valentini:
If it turns out that really actually nobody uses this, why not drop it upstream, and have the guile support removal come with the next GNU toolchain Change for Fedora?
Guile support in GNU packages is a goal of the GNU project, I think. Where Guile is used as a scripting language for a larger program, its use is generally optional. And it is unlikely that this optional support will be removed upstream.
Given that, “do what upstream does” doesn't really help to solve settle the matter in Fedora.
Yeah, I agree with that. Upstreams have different goals than Fedora, different stability policies, and different sets of people involved. I think it's entirely reasonable to deprecate and remove features (or bring in new dependencies and introduce features) in Fedora at a different schedule than upstream. Sometimes it'll be faster, sometimes it'll be slower. Even if our packagers are also upstream developers it does not mean that upstream==Fedora.
Zbyszek
On 7/7/21 2:21 PM, Fabio Valentini wrote:
On Wed, Jul 7, 2021 at 1:38 PM Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 7/7/21 1:08 PM, Florian Weimer wrote:
- Neal Gompa:
Wait, why don't we have guile 3.0?
We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult.
So I've gone and checked the Fesco issue where dropping guile support from make + gdb was discussed:
https://pagure.io/fesco/issue/2558
And I must say that I find the argumentation for rejecting the change very very weak. I would really expect Fesco to make better motivated decisions then this one.
I'm especially shocked about how Fesco is in essence mandating a group of maintainers to spend time maintaining a feature where they clearly have indicated they don't want to maintain that feature.
My being shocked here is not so much about the guile issue, but about a IMHO much bigger issue underlying this decision:
Since when does Fesco get to mandate on which features our volunteer maintainers get to spend there time ?
I understand there need to be rules and I can understand Fesco denying approval for enabling / adding certain features for a wide set of reasons, thus in essence blocking volunteers from spending time on something because that something is deemed undesirable for Fedora.
But this is different here Fesco is telling a group of maintainers that they must maintain a feature even though they have indicated that they find the benefits of that feature not worth the amount of time it costs to maintain support for that feature. So in essence Fesco is telling the maintainers that they MUST spend time maintaining this even though they don't want this.
IMHO this is just outrageous and goes way way beyond the purview of Fesco.
Now if dropping this feature would cause major breakage this would a different story, But in the whole discussion about this, at least as documented in the Fesco issue, no actual users of this feature have been indentified and nothing will break by disabling this as far is is known. So since there is no known breakage caused by this, I end up circling back to this basically telling Fesco that the make/gdb timers MUST spend them on maintaining this even though they don't want to (and have good reasons for not wanting to).
Which again, is IHMO pretty outrageous really.
Sorry Fesco, I know that you all do a lot of (hard) work as Fesco members and do your best when making decisions like this; and I don't doubt that your intentions where well, but you made a big booboo here (IMHO).
I urge Fesco to reconsider this and I suggest that we (Fedora) take another serious look at implementing: https://fedoraproject.org/wiki/Changes/RemoveGuileFromToolchain for Fedora 35.
I feel like I need to chime in here as a FESco member who was part of this decision.
As others have already mentioned in this thread, this change was Rejected by the smallest possible margin, with four +1 votes, two abstentions, and two -1 votes, while it needed five +1 votes to pass.
As I was one of the two "±0" votes: My reason for not voting +1 was that impact analysis was only based on anecdata, if at all - either "popcon data from debian shows that almost nobody has make-guile installed", or "I can't believe anybody actually uses this", but no actual analysis was done - which, for a central package like make, would be important, IMO. The stated reason of "we don't want to maintain this" was also weak, since the developers still maintain the guile support upstream, and if this was really in preparation for dropping guile support from ELN / RHEL 9 via a Change in Fedora 34, that was not really a good reason to "just do it in Fedora first" either.
However, you are right - FESCo cannot "force" anybody to maintain anything, but the change proposal was sufficiently "weak" that it was
- barely - not accepted.
But I think almost any package maintainer in Fedora would actually *look if any optional feature is actually used* before just silently dropping it from their package, or at least notify maintainers of dependent packages that feature X was considered for removal. I don't see this case any different, just that make is a more prominent package than most.
This is interesting request. I spent some thinking about it for my optional package features bind-sdb. Do we have any way to guess what feature is used at least sometime? Especially hard for make package, where you cannot expect checking every dependent package by hand.
What would be considered sufficient research about usage of guile? If package provides it as optional feature among many other features, how should package owner test one feature is still demanded? Do we have any best practice? Is asking on users@ and devel@ list enough?
So: I'd like to see actual investigation into whether the guile support is actually used in any Fedora package, and if it's going to be removed, it should be removed upstream first. If it turns out that really actually nobody uses this, why not drop it upstream, and have the guile support removal come with the next GNU toolchain Change for Fedora?
Fabio
Cheers,
Petr
On Wed, Jul 07, 2021 at 06:21:08PM +0200, Petr Menšík wrote:
What would be considered sufficient research about usage of guile? If package provides it as optional feature among many other features, how should package owner test one feature is still demanded? Do we have any best practice? Is asking on users@ and devel@ list enough?
I strongly suspect that those users would have made themselves known by now. Neal mentioned that he uses guile in some projects, and that's pretty much it so far.
Zbyszek
On 7/7/21 2:14 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Jul 07, 2021 at 06:21:08PM +0200, Petr Menšík wrote:
What would be considered sufficient research about usage of guile? If package provides it as optional feature among many other features, how should package owner test one feature is still demanded? Do we have any best practice? Is asking on users@ and devel@ list enough?
I strongly suspect that those users would have made themselves known by now. Neal mentioned that he uses guile in some projects, and that's pretty much it so far.
Well, I'm using guile scripting support in gdb as it seems to be noticeably faster than python for my scenarios with parsing huge heap areas. But I do that on CentOS 7/8s with my own backports of the gdb package and won't be losing a lot if Fedora spec hides guile under %bcond.
Maybe there are others who are abstaining from this discussion simply because they don't expect to be affected by the change.
(I'd have a stronger opinion on that if we had better ECMAScript support in guile though)
On Wed, 7 Jul 2021 at 17:15, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Jul 07, 2021 at 06:21:08PM +0200, Petr Menšík wrote:
What would be considered sufficient research about usage of guile? If package provides it as optional feature among many other features, how should package owner test one feature is still demanded? Do we have any best practice? Is asking on users@ and devel@ list enough?
I strongly suspect that those users would have made themselves known by now. Neal mentioned that he uses guile in some projects, and that's pretty much it so far.
Has anyone tried to contact Tomáš Korbař to see what they want to do? The fact that neither guile-3 and the other packages have been 'moribund' says that maybe there are other issues which need help on. [I mean 2020 has been a crap year for a LOT of people.. people have a lot of other things to worry about than a scheme derivative.]
On July 7, 2021 9:14:34 PM UTC, "Zbigniew Jędrzejewski-Szmek" zbyszek@in.waw.pl wrote:
On Wed, Jul 07, 2021 at 06:21:08PM +0200, Petr Menšík wrote:
What would be considered sufficient research about usage of guile? If package provides it as optional feature among many other features,
how
should package owner test one feature is still demanded? Do we have
any
best practice? Is asking on users@ and devel@ list enough?
I strongly suspect that those users would have made themselves known by now. Neal mentioned that he uses guile in some projects, and that's pretty much it so far.
I wouldn't be so sure about that. I don't expect most Fedora users to read devel, especially these rather long "orphaned packages threads". So my guess is that most devs, who are not Fedora contributors, but use make in their personal projects are not even aware of this discussion taking place.
Cheers,
Dan
I hope a reasonable summary is:
* The core toolchain maintainers don't want guile to be a requirement.
* The guile maintainers don't want guile to be a dependency of the core toolchain either.
* With a small adjustment, Makefiles which use guile can be changed even if make itelf doesn't support it.
How about dropping the gnutls -> guile22 BR?
Rich.
On Wed, Jul 7, 2021 at 9:06 AM Richard W.M. Jones rjones@redhat.com wrote:
I hope a reasonable summary is:
The core toolchain maintainers don't want guile to be a requirement.
The guile maintainers don't want guile to be a dependency of the core toolchain either.
With a small adjustment, Makefiles which use guile can be changed even if make itelf doesn't support it.
Yep.
How about dropping the gnutls -> guile22 BR?
Ask the GnuTLS maintainer. :)
Neal Gompa ngompa13@gmail.com writes:
On Wed, Jul 7, 2021 at 9:06 AM Richard W.M. Jones rjones@redhat.com wrote:
I hope a reasonable summary is:
The core toolchain maintainers don't want guile to be a requirement.
The guile maintainers don't want guile to be a dependency of the core toolchain either.
With a small adjustment, Makefiles which use guile can be changed even if make itelf doesn't support it.
Yep.
How about dropping the gnutls -> guile22 BR?
Ask the GnuTLS maintainer. :)
I am for dropping the BR, and perhaps it might also make sense to split out the gnutls guile binding from the upstream distribution.
That said, the current gnutls build would bring in guile22 BR anyway, indirectly through the autogen/libopts BR (if we bootstrap). We want to replace the tool with something minimal, but haven't had time to move it forward.
For the meantime, thanks Tomáš Korbař for stepping up and taking those packages; much appreciated.
Regards,
On Wed, Jul 07, 2021 at 02:06:16PM +0100, Richard W.M. Jones wrote:
- The guile maintainers don't want guile to be a dependency of the core toolchain either.
It was pointed out to me off list that this statement isn't accurate - I confused a toolchain maintainer with a guile maintainer.
Rich.
On Wed, 7 Jul 2021 06:59:18 -0400 Chuck Anderson cra@alum.wpi.edu wrote:
On Wed, Jul 07, 2021 at 11:18:04AM +0200, Miro Hrončok wrote:
cra: guile22
I'm not listed as a (co)maintainer, so I'm not sure how I ended up on this list.
because a package you maintain depends (even indirectly) on guile22, see the full report for details
Dan
On Wednesday, 7 July 2021 11.59.18 WEST Chuck Anderson wrote:
I'm not listed as a (co)maintainer, so I'm not sure how I ended up on this list.
By a transitive dependency relation... :-)
Basically one of your packages depends on another package that depends on guile22.
-
Aleksei Bavshin -
Ben Cotton -
Chuck Anderson -
Daiki Ueno -
Dan Horák -
Dan Čermák -
Daniel P. Berrangé -
Fabio Valentini -
Florian Weimer -
Frank Ch. Eigler -
Hans de Goede -
José Abílio Matos -
Kevin Fenzi -
Miro Hrončok -
Neal Gompa -
Petr Menšík -
Richard W.M. Jones -
Stephen John Smoogen -
Zbigniew Jędrzejewski-Szmek