Dne 11. 01. 23 v 12:16 Vít Ondruch napsal(a):
So shouldn't there be some policy for revoting? E.g.:


~~~

If revote is initiated (by somebody?), the revote is going to be announced on devel(-announce) and can happen as soon as in one week.

~~~



Also, I am not quite sure who and how initiated the revote. Maybe the policy should be about initiating the revote instead. E.g. if I disagree with some FESCo decision and I think it should be revoted, I would announce my intention to initiate the revote on devel(-announce).


Vít


And maybe it should not happen in the ticket, but on the meeting?


Vít


Dne 11. 01. 23 v 3:15 Siddhesh Poyarekar napsal(a):
On Tue, Jan 10, 2023 at 4:31 PM Zbigniew Jędrzejewski-Szmek
<zbys...@in.waw.pl> wrote:
That description assumes that FESCo members are preschoolers who are
easy to trick and also need to be reminded who said what every day.
That's certainly not the case. The objections against the proposal
were made very clearly and they certainly weren't forgotten over a few
days. Those objections also didn't *change* over those few days, so
repeating them wouldn't actually change anything.
They don't need to be preschoolers; it's not that hard to manufacture
an opinion among well informed adults, even unintentionally by just
having a lot of conviction about it.

The seeds for the revote were placed in the _FORTIFY_SOURCE=3 change
discussion and throughout the discussion, repeated explanations of why
the proposals are not comparable were ignored, instead of which the
focus seemed to be on driving consensus towards getting a revote on
the frame pointer proposal and trying to paint the tools team's
position as being duplicitous.

In the _FORTIFY_SOURCE=3 ticket one of the FESCo voters (who also
drove the revote FWIW) took a hard negative stand only because they
perceived a double standard on performance, which had, by then,
already been debunked a couple of times in the devel thread. While he
did change his vote to +1 later, he appeared to do so only after other
members voiced their support.  If that's not influencing narrative
then I don't know what is.

Multiple other FESCo voters, when voting for the _FORTIFY_SOURCE
proposal, talked about the frame pointer proposal, again clearly
indicating that there is a cross-influence.

Finally, another voting member commented, this time on the re-vote
ticket[1], again indicating that the reason for the revote is the
misdirection in the _FORTIFY_SOURCE proposal discussion.

Christian did make an impassioned plea on the re-vote ticket for the
case of frame pointers and it's perfectly understandable if that was a
turning point for those who changed their vote (and please say it if
that was what it was; I'd disagree but that's a different matter then)
but the thing is, that plea needs counterarguments and further
discussion and there was no opportunity for that to happen. Even
then, the only reason why the revote happened at all was because of
the persistent misdirection in the _FORTIFY_SOURCE proposal.

Speaking for myself, I heard the objections from various sides, and I
think I understand them. In particular I think that the objections from
the compiler team are based on correct evaluation of the effect of the
change. But that evaluation is hyperfocused on benchmark performance and
doesn't look at the needs of the whole ecosystem. I think that the
advantages of the proposal and the gains I hope will be realized outweigh
the drawbacks.
Ack, I respect that even if I don't agree with the conclusion.

Thanks,
Sid

[1] https://pagure.io/fesco/issue/2923#comment-833708
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to