subject:"guile22 \-> gnutls \-> lots of virt packages"

* Stephen John Smoogen:

> On Wed, 7 Jul 2021 at 11:45, Florian Weimer  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: guile22 -> gnutls -> lots of virt packages

2021-07-07 Thread Stephen John Smoogen

On Wed, 7 Jul 2021 at 11:45, Florian Weimer  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: guile22 -> gnutls -> lots of virt packages

2021-07-07 Thread Stephen John Smoogen

On Wed, 7 Jul 2021 at 08:54, Hans de Goede  wrote:
>
> Hi,

> > [1]: 
> > https://meetbot.fedoraproject.org/teams/fesco/fesco.2021-02-03-15.00.log.html
>
> 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: 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é  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é  
> > 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Guile & Fesco requiring package maintenance work (was: Re: guile22 -> gnutls -> lots of virt packages)

2021-07-07 Thread Daniel P . Berrangé

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é  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 :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: 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  wrote:
>
> On Wed, Jul 7, 2021 at 9:38 AM Daniel P. Berrangé  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Guile & Fesco requiring package maintenance work (was: Re: guile22 -> gnutls -> lots of virt packages)

2021-07-07 Thread Ben Cotton

On Wed, Jul 7, 2021 at 9:38 AM Daniel P. Berrangé  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: 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é  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 satisfacto

Re: guile22 -> gnutls -> lots of virt packages (was: Re: Orphaned packages looking for new maintainers)

2021-07-07 Thread Richard W.M. Jones

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Guile & Fesco requiring package maintenance work (was: Re: guile22 -> gnutls -> lots of virt packages)

2021-07-07 Thread Daniel P . Berrangé

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 :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: 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.

>> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: 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  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: guile22 -> gnutls -> lots of virt packages (was: Re: Orphaned packages looking for new maintainers)

2021-07-07 Thread Richard W.M. Jones


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/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: 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  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!

Re: 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  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: guile22 -> gnutls -> lots of virt packages

2021-07-07 Thread Fabio Valentini

On Wed, Jul 7, 2021 at 1:38 PM 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.

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_lis

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: guile22 -> gnutls -> lots of virt packages

2021-07-07 Thread Miro Hrončok

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 I don't feel this benefits Fedora much, but I won't block
the maintainers to make a decision that doe snot affect other packages

"""

https://meetbot.fedoraproject.org/fedora-meeting-2/2021-02-03/fesco.2021-02-03-15.00.log.html

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure

Re: guile22 -> gnutls -> lots of virt packages

2021-07-07 Thread Daniel P . Berrangé

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 :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: guile22 -> gnutls -> lots of virt packages

On Wed, Jul 7, 2021 at 7:38 AM 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.
>

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.html


--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: 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  wrote:
>>
>> * Neal Gompa:
>>
>>> On Wed, Jul 7, 2021 at 7:08 AM 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.
>>>
>>> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: guile22 -> gnutls -> lots of virt packages

On Wed, Jul 7, 2021 at 7:18 AM Florian Weimer  wrote:
>
> * Neal Gompa:
>
> > On Wed, Jul 7, 2021 at 7:08 AM 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.
> >
> > 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: guile22 -> gnutls -> lots of virt packages

* Neal Gompa:

> On Wed, Jul 7, 2021 at 7:08 AM 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.
>
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: guile22 -> gnutls -> lots of virt packages

On Wed, Jul 7, 2021 at 7:08 AM 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.
>

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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: guile22 -> gnutls -> lots of virt packages

* 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.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: guile22 -> gnutls -> lots of virt packages (was: Re: Orphaned packages looking for new maintainers)