4:18 a.m.
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
--
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
4:43 a.m.
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
5:07 a.m.
New subject: guile22 -> gnutls -> lots of virt packages (was: Re: Orphaned
packages looking for new maintainers)
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
5:58 a.m.
New subject: guile22 -> gnutls -> lots of virt packages (was: Re: Orphaned
packages looking for new maintainers)
On Wed, Jul 7, 2021 at 6:08 AM Richard W.M. Jones <rjones(a)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?
--
真実はいつも一つ！/ Always, there's only one truth!
6:13 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
On Wed, Jul 7, 2021 at 7:08 AM Florian Weimer <fweimer(a)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
--
真実はいつも一つ！/ Always, there's only one truth!
6:18 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
* Neal Gompa:
On Wed, Jul 7, 2021 at 7:08 AM Florian Weimer
<fweimer(a)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
6:33 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
On Wed, Jul 7, 2021 at 7:18 AM Florian Weimer <fweimer(a)redhat.com> wrote:
* Neal Gompa:
> On Wed, Jul 7, 2021 at 7:08 AM Florian Weimer <fweimer(a)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!
6:43 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
Hi,
On 7/7/21 1:33 PM, Neal Gompa wrote:
On Wed, Jul 7, 2021 at 7:18 AM Florian Weimer
<fweimer(a)redhat.com> wrote:
>
> * Neal Gompa:
>
>> On Wed, Jul 7, 2021 at 7:08 AM Florian Weimer <fweimer(a)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
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
6:38 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
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
6:53 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
On Wed, Jul 7, 2021 at 7:38 AM Hans de Goede <hdegoede(a)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....
--
真実はいつも一つ！/ Always, there's only one truth!
7:53 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
Hi,
On 7/7/21 1:53 PM, Neal Gompa wrote:
On Wed, Jul 7, 2021 at 7:38 AM Hans de Goede
<hdegoede(a)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:
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....
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
10:38 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
On Wed, 7 Jul 2021 at 08:54, Hans de Goede <hdegoede(a)redhat.com> wrote:
Hi,
> [1]:
https://meetbot.fedoraproject.org/teams/fesco/fesco.2021-02-03-15.00.log....
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 J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on BBS...
time to reboot.
10:45 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
* 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
10:57 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
On Wed, 7 Jul 2021 at 11:45, Florian Weimer <fweimer(a)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 J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on BBS...
time to reboot.
11:04 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
* Stephen John Smoogen:
On Wed, 7 Jul 2021 at 11:45, Florian Weimer
<fweimer(a)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.
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
6:59 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
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:
https://pagure.io/fesco/issue/2558
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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
7:29 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
* 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
6:59 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
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-...
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
7:14 a.m.
New subject: Guile & Fesco requiring package maintenance work (was: Re: guile22
-> gnutls -> lots of virt packages)
* 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
7:38 a.m.
New subject: Guile & Fesco requiring package maintenance work (was: Re:
guile22 -> gnutls -> lots of virt packages)
On Wed, Jul 7, 2021 at 8:14 AM Florian Weimer <fweimer(a)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!
8:09 a.m.
New subject: Guile & Fesco requiring package maintenance work (was: Re:
guile22 -> gnutls -> lots of virt packages)
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
8:37 a.m.
New subject: Guile & Fesco requiring package maintenance work (was: Re:
guile22 -> gnutls -> lots of virt packages)
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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
8:56 a.m.
New subject: Guile & Fesco requiring package maintenance work (was: Re:
guile22 -> gnutls -> lots of virt packages)
On Wed, Jul 7, 2021 at 9:38 AM Daniel P. Berrangé <berrange(a)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.o...
[3]: https://pagure.io/fesco/issue/2558
[4]: https://meetbot.fedoraproject.org/teams/fesco/fesco.2021-02-03-15.00.log....
--
真実はいつも一つ！/ Always, there's only one truth!
9:46 a.m.
New subject: Guile & Fesco requiring package maintenance work (was: Re:
guile22 -> gnutls -> lots of virt packages)
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(a)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.
[0]: https://fedoraproject.org/wiki/Changes/DebuginfodByDefault
[1]: https://pagure.io/fesco/issue/2597#comment-728404
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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
10:01 a.m.
New subject: Guile & Fesco requiring package maintenance work (was: Re:
guile22 -> gnutls -> lots of virt packages)
On Wed, Jul 7, 2021 at 10:46 AM Daniel P. Berrangé <berrange(a)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(a)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.
>
> [0]: https://fedoraproject.org/wiki/Changes/DebuginfodByDefault
> [1]: https://pagure.io/fesco/issue/2597#comment-728404
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.
--
真実はいつも一つ！/ Always, there's only one truth!
2:07 p.m.
New subject: Guile & Fesco requiring package maintenance work (was: Re:
guile22 -> gnutls -> lots of virt packages)
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
9:14 a.m.
New subject: Guile & Fesco requiring package maintenance work (was: Re:
guile22 -> gnutls -> lots of virt packages)
On Wed, Jul 7, 2021 at 9:38 AM Daniel P. Berrangé <berrange(a)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
9:20 a.m.
New subject: Guile & Fesco requiring package maintenance work
* 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
9:22 a.m.
New subject: Guile & Fesco requiring package maintenance work
On Wed, Jul 7, 2021 at 10:20 AM Florian Weimer <fweimer(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
9:25 a.m.
New subject: Guile & Fesco requiring package maintenance work
On Wed, Jul 7, 2021 at 10:23 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Wed, Jul 7, 2021 at 10:20 AM Florian Weimer <fweimer(a)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.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
9:27 a.m.
New subject: Guile & Fesco requiring package maintenance work
On Wed, Jul 7, 2021 at 10:25 AM Ben Cotton <bcotton(a)redhat.com> wrote:
On Wed, Jul 7, 2021 at 10:23 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Wed, Jul 7, 2021 at 10:20 AM Florian Weimer <fweimer(a)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.
:)
--
真実はいつも一つ！/ Always, there's only one truth!
2:31 p.m.
New subject: Guile & Fesco requiring package maintenance work
Ben Cotton <bcotton(a)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
2:42 p.m.
New subject: Guile & Fesco requiring package maintenance work
On Wed, Jul 07, 2021 at 03:31:21PM -0400, Frank Ch. Eigler wrote:
Ben Cotton <bcotton(a)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
8:58 p.m.
New subject: Guile & Fesco requiring package maintenance work
Kevin Fenzi <kevin(a)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
6:56 p.m.
New subject: Guile & Fesco requiring package maintenance work
On Wed, Jul 07, 2021 at 09:58:56PM -0400, Frank Ch. Eigler wrote:
Kevin Fenzi <kevin(a)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
9:26 a.m.
New subject: Guile & Fesco requiring package maintenance work (was: Re:
guile22 -> gnutls -> lots of virt packages)
On Wed, Jul 7, 2021 at 10:22 AM Ben Cotton <bcotton(a)redhat.com> wrote:
On Wed, Jul 7, 2021 at 9:38 AM Daniel P. Berrangé <berrange(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
7:21 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
On Wed, Jul 7, 2021 at 1:38 PM Hans de Goede <hdegoede(a)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
7:27 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
* 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
4:12 p.m.
New subject: guile22 -> gnutls -> lots of virt packages
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
11:21 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
On 7/7/21 2:21 PM, Fabio Valentini wrote:
On Wed, Jul 7, 2021 at 1:38 PM Hans de Goede
<hdegoede(a)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
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
4:14 p.m.
New subject: guile22 -> gnutls -> lots of virt packages
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
4:55 p.m.
New subject: guile22 -> gnutls -> lots of virt packages
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)
--
Best regards,
Aleksei Bavshin
5:08 p.m.
New subject: guile22 -> gnutls -> lots of virt packages
On Wed, 7 Jul 2021 at 17:15, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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.]
--
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on BBS...
time to reboot.
11:13 p.m.
New subject: guile22 -> gnutls -> lots of virt packages
On July 7, 2021 9:14:34 PM UTC, "Zbigniew Jędrzejewski-Szmek"
<zbyszek(a)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
8:06 a.m.
New subject: guile22 -> gnutls -> lots of virt packages (was: Re: Orphaned
packages looking for new maintainers)
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
8:09 a.m.
New subject: guile22 -> gnutls -> lots of virt packages (was: Re: Orphaned
packages looking for new maintainers)
On Wed, Jul 7, 2021 at 9:06 AM Richard W.M. Jones <rjones(a)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. :)
--
真実はいつも一つ！/ Always, there's only one truth!
2:19 a.m.
New subject: guile22 -> gnutls -> lots of virt packages
Neal Gompa <ngompa13(a)gmail.com> writes:
On Wed, Jul 7, 2021 at 9:06 AM Richard W.M. Jones
<rjones(a)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,
--
Daiki Ueno
8:55 a.m.
New subject: guile22 -> gnutls -> lots of virt packages (was: Re: Orphaned
packages looking for new maintainers)
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
6:15 a.m.
On Wed, 7 Jul 2021 06:59:18 -0400
Chuck Anderson <cra(a)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
6:19 a.m.
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.
--
José Abílio
1002
days inactive
1017
days old
51 comments
19 participants
participants (19)
-
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