On 1/10/23 18:13, Kevin Kofler via devel wrote:
> Michael Catanzaro wrote:
>> You've previously indicated that developers should just 'dnf
>> distro-sync' to an alternative Fedora that has frame pointers, as if
>> building two alternate versions of Fedora, one for developers and one
>> for users, i
Siddhesh Poyarekar wrote:
> That came up in yesterday's FESCO meeting, so hopefully at least that
> workflow hole will be plugged:
Still does not help the current case though, unfortunately.
Kevin Kofler
___
devel mailing list -- devel@lists.fed
On Wed, Jan 11, 2023 at 6:25 AM Vít Ondruch wrote:
>
>
> 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
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 initia
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.
~~~
And maybe it should not happen in the ticket, but on the meeting?
Vít
Dne 11. 01. 23 v 3:1
On Tue, Jan 10, 2023 at 7:17 PM Fabio Valentini wrote:
> Speaking for myself, the only way in which the _FORTIFY_SOURCE change
> impacted my opinion on -fno-omit-frame-pointers is that it made me
> think about it again, and that the level of scrutiny myself - and
> other members of FESCo - had giv
On Tue, Jan 10, 2023 at 09:15:41PM -0500, Siddhesh Poyarekar wrote:
...snip...
>
> 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.
Just to set the reco
On Tue, Jan 10, 2023 at 4:31 PM Zbigniew Jędrzejewski-Szmek
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 clea
On Wed, Jan 11, 2023 at 12:15 AM Kevin Kofler via devel
wrote:
>
> Michael Catanzaro wrote:
> > (In particular, I doubt the _FORTIFY_SOURCE=3 change was really a major
> > consideration here.)
>
> What was, then? That was literally the only thing that has changed between
> the two diametrically di
Zbigniew Jędrzejewski-Szmek 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 fo
Michael Catanzaro wrote:
> (In particular, I doubt the _FORTIFY_SOURCE=3 change was really a major
> consideration here.)
What was, then? That was literally the only thing that has changed between
the two diametrically different votes.
Kevin Kofler
___
Michael Catanzaro wrote:
> You've previously indicated that developers should just 'dnf
> distro-sync' to an alternative Fedora that has frame pointers, as if
> building two alternate versions of Fedora, one for developers and one
> for users, is a reasonable thing to do. The cost of this is just t
On Tue, Jan 10, 2023 at 08:30:25AM -0500, Siddhesh Poyarekar wrote:
> On Tue, Jan 10, 2023 at 3:05 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> > Exactly, you're just confirming what I wrote above.
> >
> > A "vote being rigged" means that either the people who should be allowed to
> > vote
> > could
On Tue, Jan 10 2023 at 01:12:35 AM +0100, Kevin Kofler via devel
wrote:
For speed:
https://valgrind.org/info/tools.html#cachegrind
or
https://valgrind.org/info/tools.html#callgrind
with (in both cases)
https://apps.kde.org/kcachegrind/
For memory (RAM) usage:
https://valgrind.org/info/tools.h
On Mon, Jan 9 2023 at 06:54:09 PM +0100, Florian Weimer
wrote:
No one spoke out when the tools team was called untrustworthy on the
FESCo ticket.
That was one of my comments. [1] I should have worded that more
carefully, but didn't because I was very frustrated. I apologize. What
I meant
On 10. 01. 23 0:44, Kevin Kofler via devel wrote:
Miro Hrončok wrote:
Considering the mass rebuild is happening really soon, I feel like
repeating the vote later is not helpful, but if people want to, we can
surely run the vote again. However, I am confident the result will be the
same.
With a
On Mon, Jan 09, 2023 at 10:08:11PM +0100, Mark Wielaard wrote:
> > ... and I won't quote all of that, but looking at
> > https://docs.fedoraproject.org/en-US/fesco/#_ticket_policy...
> > I don't see any violations, either in the letter or the spirit of what is
> > written.
[...]
> It does feel to m
Am Dienstag, 10. Jänner 2023 08:25:27 CET schrieb Zbigniew
Jędrzejewski-Szmek:
On Mon, Jan 09, 2023 at 11:53:17PM +0100, Kevin Kofler via devel wrote:
No, the result is NOT why I got the impression that the vote
was rigged. The way that result was obtained is.
Exactly, you're just confirming w
On Tue, Jan 10, 2023 at 3:05 AM Zbigniew Jędrzejewski-Szmek
wrote:
> Exactly, you're just confirming what I wrote above.
>
> A "vote being rigged" means that either the people who should be allowed to
> vote
> couldn't, or that people who are not allowed to vote did, or that voters were
> tricked
On Mon, Jan 09, 2023 at 11:53:17PM +0100, Kevin Kofler via devel wrote:
> Am Montag, 9. Jänner 2023 23:06:17 CET schrieb Zbigniew Jędrzejewski-Szmek:
> > On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
> > > Kevin Kofler via devel wrote:
> > > PS: The impression I get is tha
On Mon, Jan 9, 2023 at 5:53 PM Kevin Kofler via devel
wrote:
> * It made wrong assumptions about the performance impact of
> _FORTIFY_SOURCE=3, which, compared to the already existing (!)
> _FORTIFY_SOURCE=2, appears to actually have NO performance impact at all
> (!), only compared to no _FORTIFY
Demi Marie Obenour wrote:
> On 1/6/23 20:35, Frank Ch. Eigler wrote:
>> (There are exist other profiling tools and techniques that do not
>> require frame pointer recompilation, but whatever.)
>
> Which ones? I would love for them to exist, and I believe there is
> work being done in that direct
Miro Hrončok wrote:
> Considering the mass rebuild is happening really soon, I feel like
> repeating the vote later is not helpful, but if people want to, we can
> surely run the vote again. However, I am confident the result will be the
> same.
With all this talk about the mass rebuild being immi
Am Montag, 9. Jänner 2023 23:06:17 CET schrieb Zbigniew Jędrzejewski-Szmek:
On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
Kevin Kofler via devel wrote:
PS: The impression I get is that everything was deliberately
rigged so that
the vote would end up the way it did:
led in the middle of the holiday season. Many people in
> Europe are on vacation until today.
> 6. There was NO thread about the reopening of the discussion on the mailing
> list. The first message that mentioned the issue on the mailing list was
> "Schedule for Tuesday's FESC
Hi Matthew,
On Mon, Jan 09, 2023 at 11:47:54AM -0500, Matthew Miller wrote:
> On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
> > Therefore, I hereby request that the vote be annulled as having happened
> > in violation of the Change policy.
>
> So, from a purely "what are
On 1/9/23 12:27, Kevin Kofler via devel wrote:
Am Montag, 9. Jänner 2023 21:02:48 CET schrieb Tom Stellard:
I think a good solution would be to move the proposal submission deadlines
a month earlier in the schedule. There's only 3 weeks between the
"Changes Requiring Mass Rebuild" deadline and
On 1/9/23 08:47, Matthew Miller wrote:
It might be useful to improve both the documented policies. The Changes
policy has nothing about reconsidering Changes in the current cycle that I
can see. (Or, actually, for that matter, for resubmitting in future cycles
either, unless i'm missing somethin
Am Montag, 9. Jänner 2023 21:02:48 CET schrieb Tom Stellard:
I think a good solution would be to move the proposal submission deadlines
a month earlier in the schedule. There's only 3 weeks between the
"Changes Requiring Mass Rebuild" deadline and the mass rebuild.
I don't think 3 weeks is rea
On 1/9/23 11:18, Neal Gompa wrote:
On Mon, Jan 9, 2023 at 2:11 PM Daniel P. Berrangé wrote:
On Mon, Jan 09, 2023 at 11:47:54AM -0500, Matthew Miller wrote:
On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
PS: The impression I get is that everything was deliberately rig
wrong here so we can remove mno-omit-leaf-frame-pointer for
aarch64.
Cheers,
Daan De Meyer
From: Daan De Meyer
Sent: 09 January 2023 19:21
To: Matthew Miller; Development discussions related to Fedora
Subject: Re: FESCo revote on "Add -fno-omit-fr
On Mon, Jan 9, 2023 at 2:11 PM Daniel P. Berrangé wrote:
>
> On Mon, Jan 09, 2023 at 11:47:54AM -0500, Matthew Miller wrote:
> > On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
> > > PS: The impression I get is that everything was deliberately rigged so
> > > that
> > > th
Am Montag, 9. Jänner 2023 20:10:53 CET schrieb Daniel P. Berrangé:
Holding a FESCo meeting and vote on the very first working day after
the long xmas / new year holiday is not exactly good timing if you
want contributors to be broadly aware it is happening[1]. I might
humbly suggest that next yea
On Mon, Jan 09, 2023 at 11:47:54AM -0500, Matthew Miller wrote:
> On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
> > PS: The impression I get is that everything was deliberately rigged so that
> > the vote would end up the way it did:
> >
> > 1. A new ticket was filed, in
On 1/6/23 20:35, Frank Ch. Eigler wrote:
>
> Hi -
>
>> The thing is that perf + flamegraphs makes your whole system much more
>> visible and so it's much easier to find these kind of gains in
>> specific scenarios.
>
> (There are exist other profiling tools and techniques that do not
> require f
* Matthew Miller:
> BUT, I do not think it was done with malice, as "deliberately rigged"
> implies. I don't see that at all -- I see excitement and interest in moving
> forward on something that already has taken a long time, and looming
> practical deadlines.
No one spoke out when the tools tea
On 09. 01. 23 17:47, Matthew Miller wrote:
On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
PS: The impression I get is that everything was deliberately rigged so that
the vote would end up the way it did:
1. A new ticket was filed, in order to exclude the participants of
Am Montag, 9. Jänner 2023 17:47:54 CET schrieb Matthew Miller:
And, from a practical point of view, since this passed with six +1 votes,
I'm not sure what benefit canceling and re-voting would really add.
Canceling the vote and requiring that the Change Policy be followed would
mean that the c
Matthew Miller writes:
> So, from a purely "what are the rules?" view, the Change process says:
> FESCo will vote to approve or deny a change proposal in accordance with
> the FESCo ticket policy.
>
> ... and I won't quote all of that, but looking at
> https://docs.fedoraproject.org/en-US/fes
On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
> PS: The impression I get is that everything was deliberately rigged so that
> the vote would end up the way it did:
>
> 1. A new ticket was filed, in order to exclude the participants of the
> previous discussion.
> 2. The
On 9/01/2023 10:09, Mamoru TASAKA wrote:
Honestly saying, I cannot understand this context, why native English
speaker or not is relevant here, especially because I am also
non-native.
I don't think Fedora committers change their attitude against
between native or non-native English speakers.
M
Hi Neal,
On Wed, 2023-01-04 at 08:44 -0500, Neal Gompa wrote:
> On Wed, Jan 4, 2023 at 8:30 AM Vitaly Zaitsev via devel
> wrote:
> >
> > Already rejected proposal was submitted because big corporations
> > weren't
> > happy with the results. This is a VERY BAD precedent for Fedora.
> >
>
> Act
Neal Gompa wrote on 2023/01/09 11:58:
I'm extremely tired of how you communicate on this mailing list. I've
been quiet about it for years and years. But people leave Fedora
because of you. Once again, I'm having discussions with people trying
to convince them Fedora isn't a bad place because of
On 09/01/2023 03:58, Neal Gompa wrote:
I'm extremely tired of how you communicate on this mailing list. I've
been quiet about it for years and years. But people leave Fedora
because of you. Once again, I'm having discussions with people trying
to convince them Fedora isn't a bad place because of
he discussion on the
> > mailing list. The first message that mentioned the issue on the mailing
> > list was "Schedule for Tuesday's FESCo Meeting (2023-01-03)" from
> > 2023-01-03 09:39 UTC, only 7 hours 21 minutes before the meeting. This is
> > in contrast to
was filed in the middle of the holiday season. Many people
> in Europe are on vacation until today.
> 6. There was NO thread about the reopening of the discussion on the
> mailing list. The first message that mentioned the issue on the mailing
> list was "Schedule for Tuesday's
On Sun, Jan 8, 2023 at 9:08 PM Kevin Kofler via devel
wrote:
>
> Also, the pull request implementing the change was merged 6 days BEFORE the
> change was approved by FESCo! It is unacceptable to sneak unapproved changes
> into Rawhide this way in order to "create facts".
>
Actually, no it wasn't.
Also, the pull request implementing the change was merged 6 days BEFORE the
change was approved by FESCo! It is unacceptable to sneak unapproved changes
into Rawhide this way in order to "create facts".
Kevin Kofler
___
devel mailing list -- de
Vitaly Zaitsev via devel wrote:
> The original proposal received a lot of negative feedback. Only a few
> big corporations will get benefit and end users will get a 3-10%
> performance penalty which is absolutely unacceptable.
Not to mention the size impact. My request in the original discussion t
Kevin Kofler via devel wrote:
> 7. Only 4 days had elapsed between the (unannounced) opening of the ticket
> and the vote. This is clearly insufficient. The one week in the Change
Sorry, there were actually 6 days. Still, less than a week, and there was no
mailing list announcement. The community
NO thread about the reopening of the discussion on the mailing
list. The first message that mentioned the issue on the mailing list was
"Schedule for Tuesday's FESCo Meeting (2023-01-03)" from 2023-01-03 09:39
UTC, only 7 hours 21 minutes before the meeting. This is in contrast to t
Kevin Kofler via devel wrote:
> Also, for MSVC, /Oy- is documented to be supported on everything except
/Oy actually. /Oy- is the default (= -fno-omit-frame-pointer), /Oy is the
equivalent of -fomit-frame-pointer. But both are documented as unsupported
only for "x64 compilers".
Kevin Ko
On Sat, Jan 7, 2023 at 1:31 AM Kevin Kofler via devel
wrote:
>
> Neal Gompa wrote:
> > GCC is not the official compiler on Windows or macOS. Both platforms
> > require frame pointers on all supported architectures with their
> > official compilers (MSVC for Windows, Clang for macOS).
>
> Frame poi
Neal Gompa wrote:
> GCC is not the official compiler on Windows or macOS. Both platforms
> require frame pointers on all supported architectures with their
> official compilers (MSVC for Windows, Clang for macOS).
Frame pointers are not required by the operating system if you can compile
working
Richard W.M. Jones wrote:
> The problem is you're confusing general gains and gains in
> specific scenarios.
But the thing is that a gain in some specific scenario is a lot less useful
than a general gain. And the latter is usually not had through profiling,
but through improvements in toolchain
On Sat, Jan 7, 2023 at 12:24 AM Kevin Kofler via devel
wrote:
>
> Neal Gompa wrote:
> > For what it's worth, frame pointers are required on other operating
> > systems for precisely this reason
>
> What operating systems REQUIRE frame pointers? GCC supports
> -fomit-frame-pointer basically everywh
Miro Hrončok wrote:
> On 04. 01. 23 17:29, Jonathan Wakely wrote:
>> On Tue, 3 Jan 2023 at 09:39, Miro Hrončok wrote:
>>>
>>> = New business =
>>>
>>> #2923 Re-vote for Change proposal: Add -fno-omit-frame-pointer to
>>> #default
>>> compilation flags
>>> https://pagure.io/fesco/issue/2923
>>
>>
PS:
Kevin Kofler via devel wrote:
> The way this was done is so wrong:
> * There was a vote. You were not happy with the outcome.
> * So you first tried to complain in the original ticket about this. It was
> clear that the consensus in that ticket was to not reconsider at this
> time.
> * So inst
Andrii Nakryiko wrote:
>
>> This is why I think the change is implicitly just for x86_64.
>
> Definitely not intentionally, might be just a bias of what we had most
> hands-on experience with.
Well, that is why it is so bad that you forced through this change behind
the toolchain team's back. Th
Michael Catanzaro wrote:
> Benchmarks probably won't improve.
And that alone is enough to make Fedora look bad and lose users to other
distributions that cater to the Phoronix crowd.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproj
Neal Gompa wrote:
> For what it's worth, frame pointers are required on other operating
> systems for precisely this reason
What operating systems REQUIRE frame pointers? GCC supports
-fomit-frame-pointer basically everywhere.
Kevin Kofler
___
Neal Gompa wrote:
> On Wed, Jan 4, 2023 at 8:30 AM Vitaly Zaitsev via devel
> wrote:
>>
>> On 03/01/2023 18:42, Miro Hrončok wrote:
>> >* AGREED: APPROVED (+6,1,-1) This Change is implemented for Fedora
>> > Linux 38 and we evaluate whether to retain it by Fedora Linux 40.
>> > This
Hi -
> The thing is that perf + flamegraphs makes your whole system much more
> visible and so it's much easier to find these kind of gains in
> specific scenarios.
(There are exist other profiling tools and techniques that do not
require frame pointer recompilation, but whatever.)
> Frame poi
On 2023-01-06 02:24, Jonathan Wakely wrote:
Aside: could the change proposal please be updated to show *how* to
opt out, not just state it can be done trivially?
I shouldn't have to find
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/231#request_diff
to know whether the right
On Fri, Jan 06, 2023 at 10:24:39AM +, Jonathan Wakely wrote:
> But they should be measurable, right? If profiling can't actually
> measure performance and track improvements in performance, the change
> isn't useful. So it should be possible to show the benefits over the
> next release or two.
On Thu, 5 Jan 2023 at 17:47, Demi Marie Obenour wrote:
>
> On 1/5/23 11:08, Frank Ch. Eigler wrote:
> >
> >> Of course, but the benefit is to fix performance bugs in applications
> >> or maybe the desktop itself. [...]
> >
> >>> Let's be firm in testing this empirically rather than aspirationally.
On 1/5/23 11:08, Frank Ch. Eigler wrote:
>
>> Of course, but the benefit is to fix performance bugs in applications
>> or maybe the desktop itself. [...]
>
>>> Let's be firm in testing this empirically rather than aspirationally.
>> I really don't know how. Suggestions welcome.
>
> I'd put the o
On 04. 01. 23 17:29, Jonathan Wakely wrote:
On Tue, 3 Jan 2023 at 09:39, Miro Hrončok wrote:
= New business =
#2923 Re-vote for Change proposal: Add -fno-omit-frame-pointer to default
compilation flags
https://pagure.io/fesco/issue/2923
Given the controversial nature of this one, why was it
> Of course, but the benefit is to fix performance bugs in applications
> or maybe the desktop itself. [...]
>> Let's be firm in testing this empirically rather than aspirationally.
> I really don't know how. Suggestions welcome.
I'd put the onus on the proponents of the Change, who made predict
On Wed, Jan 04, 2023 at 02:30:07PM +0100, Vitaly Zaitsev via devel wrote:
> On 03/01/2023 18:42, Miro Hrončok wrote:
> > * AGREED: APPROVED (+6,1,-1) This Change is implemented for Fedora
> > Linux 38 and we evaluate whether to retain it by Fedora Linux 40.
> > This Change must be impleme
On Wed, Jan 4 2023 at 11:10:54 PM -0500, Frank Ch. Eigler
wrote:
If I understood it correctly, the claim was that enabling this
distro-user-penalizing option would make it back in terms of
performance
optimizations.
Of course, but the benefit is to fix performance bugs in applications
or ma
Michael Catanzaro writes:
>> Then perhaps the Change could have had a dead-man-switch built in:
>> unless performance improvements due to this profiling change do not in
>> fact appear by F39 or F40, the Change should be automatically
>> reverted.
>
> Question is how to measure that? Is it suffic
On Wed, Jan 4 2023 at 03:42:43 PM -0500, Frank Ch. Eigler
wrote:
Then perhaps the Change could have had a dead-man-switch built in:
unless performance improvements due to this profiling change do not in
fact appear by F39 or F40, the Change should be automatically
reverted.
Question is how to
Michael Catanzaro writes:
> [...]
> Please, stop saying this. It's just not true. All Fedora users will
> benefit from the performance improvements that we're able to make
> using sysprof. [...]
Then perhaps the Change could have had a dead-man-switch built in:
unless performance improvements du
> The change as voted simply does not work at a technical level because
> -mno-omit-leaf-frame-pointer is an architecture-specific GCC option that
> is not available on all Fedora architectures. I don't think
> -fno-omit-frame-pointer is well-exercised on s390x, so I wouldn't want
> to use it ther
On 2023-01-04 09:28, Florian Weimer wrote:
The change as voted simply does not work at a technical level because
-mno-omit-leaf-frame-pointer is an architecture-specific GCC option
that
is not available on all Fedora architectures. I don't think
-fno-omit-frame-pointer is well-exercised on s39
On 1/4/23 10:05, Vitaly Zaitsev via devel wrote:
> On 04/01/2023 15:25, Michael Catanzaro wrote:
>> All Fedora users will benefit from the performance improvements that
>> we're able to make using sysprof.
>
> Maybe. Or maybe not. And the performance penalty is here and now.
The optimizations en
* Miro Hrončok:
> * #2923 Re-vote for Change proposal: Add -fno-omit-frame-pointer to
> default (mhroncok, 17:06:26)
> * LINK:
> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/230
> is the implementation (davide, 17:13:47)
> * AGREED: APPROVED (+6,1,-1) This Cha
On Tue, 3 Jan 2023 at 09:39, Miro Hrončok wrote:
>
> = New business =
>
> #2923 Re-vote for Change proposal: Add -fno-omit-frame-pointer to default
> compilation flags
> https://pagure.io/fesco/issue/2923
Given the controversial nature of this one, why was it re-litigated at
short notice when a l
On 04/01/2023 15:25, Michael Catanzaro wrote:
All Fedora users will benefit from the performance improvements that
we're able to make using sysprof.
Maybe. Or maybe not. And the performance penalty is here and now.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On Wed, Jan 4 2023 at 02:49:30 PM +0100, Vitaly Zaitsev via devel
wrote:
. Only a few
big corporations will get benefit
Please, stop saying this. It's just not true. All Fedora users will
benefit from the performance improvements that we're able to make using
sysprof. Right now desktop devel
On Wed, Jan 4, 2023 at 8:50 AM Vitaly Zaitsev via devel
wrote:
>
> On 04/01/2023 14:44, Neal Gompa wrote:
> > Actually, the Change owners were prepared to give up. I was the one
> > that pushed for it to be reconsidered because of how much benefit it
> > gives to desktop Linux developers.
>
> The
On 04/01/2023 14:44, Neal Gompa wrote:
Actually, the Change owners were prepared to give up. I was the one
that pushed for it to be reconsidered because of how much benefit it
gives to desktop Linux developers.
The original proposal received a lot of negative feedback. Only a few
big corporati
On Wed, Jan 4, 2023 at 8:30 AM Vitaly Zaitsev via devel
wrote:
>
> On 03/01/2023 18:42, Miro Hrončok wrote:
> >* AGREED: APPROVED (+6,1,-1) This Change is implemented for Fedora
> > Linux 38 and we evaluate whether to retain it by Fedora Linux 40.
> > This Change must be implemented
On 03/01/2023 18:42, Miro Hrončok wrote:
* AGREED: APPROVED (+6,1,-1) This Change is implemented for Fedora
Linux 38 and we evaluate whether to retain it by Fedora Linux 40.
This Change must be implemented in a manner which packages are able
to trivially opt-out of retaining fra
===
#fedora-meeting: FESCO (2023-01-03)
===
Meeting started by mhroncok at 17:01:53 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2023-01-03/fesco.2023-01-03-17.01.log.html
.
Meeting summary
On Tue, Jan 03, 2023 at 10:39:13AM +0100, Miro Hrončok wrote:
> = Discussed and Voted in the Ticket =
…
> Change: Use mdadm for BIOS RAID Support in Anaconda
> https://pagure.io/fesco/issue/2922
Something went wrong here. The tally is +4,0,0 on this one.
The ticket wasn't closed.
Zbyszek
On 03. 01. 23 10:39, Miro Hrončok wrote:
Change: Use mdadm for BIOS RAID Support in Anaconda
https://pagure.io/fesco/issue/2922
A decision has not yet been made officially for this one, I copy pasted it to
the email and forgot to remove it before I sent it. Sorry about that.
--
Miro Hrončok
On 03. 01. 23 10:39, Miro Hrončok wrote:
Title of issue
https://pagure.io/fesco/issue/###
DECISION (+X, Y, -Z)
There was no actual issue supposed to be listed here instead of the
placeholder, it was merely redundant.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_
Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on
irc.libera.chat.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2023-01-03 17:00 UTC'
Links to all issues to be d
90 matches
Mail list logo
