#2429 F33 System-Wide Change: Make btrfs the default file system for desktop variants
Closed: Accepted 4 months ago by zbyszek. Opened 4 months ago by bcotton.

For laptop and workstation installs of Fedora, we want to provide file system features to users in a transparent fashion. We want to add new features, while reducing the amount of expertise needed to deal with situations like running out of disk space. Btrfs is well adapted to this role by design philosophy, let's make it the default.


+1 for LXQt.
LXQt simply includes fedora-live-base.ks so as soon as the change lands in fedora-live-base.ks it takes effect in LXQt live media.

+1 for LXQt.
LXQt simply includes fedora-live-base.ks so as soon as the change lands in fedora-live-base.ks it takes effect in LXQt live media.

The changes for the spins is already pending in a PR to fedora-kickstarts.

Note that the voting here is for FESCo members, as this allows us to vote in the ticket.

I'd like to hear from the Workstation teams regarding this change as well as the filesystem team. This change is proposed for the desktop variants....is this desired by GNOME, KDE, any other desktop environments that produce install media?

Does the filesystem team have any comments? My understanding is we have no one working on btrfs nor committed to addressing btrfs issues that may come up.

Withholding my vote until I hear from the above.

I'd like to hear from the Workstation teams regarding this change as well as the filesystem team. This change is proposed for the desktop variants....is this desired by GNOME, KDE, any other desktop environments that produce install media?

Yes. All desktop spins were asked and they assented. Most of the change owners are in fact spin/edition owners that have agreed to the change.

Does the filesystem team have any comments? My understanding is we have no one working on btrfs nor committed to addressing btrfs issues that may come up.

Nobody at Red Hat, but @josef from Facebook is being formally committed to work on Fedora Btrfs issues. He is also a change owner, along with @dcavalca and @salimma who are working on the userspace integration side of things.

Withholding my vote until I hear from the above.

Hopefully this satisfies your query.

I'm likely a weak +1 here, but I would like to defer my vote until after the upcoming test day (wed). Can we perhaps wait until after that to vote (in ticket)?

I'd like to complement the change owners for a detailed change with lots of data and engagement. Thanks.

I'm likely a weak +1 here, but I would like to defer my vote until after the upcoming test day (wed). Can we perhaps wait until after that to vote (in ticket)?

Just curious, what is the reason for that? I mean during one day the FS must be so bad or people writing random garbage on their disks to break it to get it broken within one test day.

I'm likely a weak +1 here, but I would like to defer my vote until after the upcoming test day (wed). Can we perhaps wait until after that to vote (in ticket)?

Maybe. I'm not sure it makes a difference one way or another. We could hold off on merging the PRs associated with this Change until after the test day if it's approved. Indeed, I'd probably ask on doing that anyway, because I want to make sure I got it all right. :wink:

Approval of the change doesn't imply everything changes immediately in Rawhide, but it certainly makes it easy to proceed with next steps (especially with ARM...).

I'd like to complement the change owners for a detailed change with lots of data and engagement. Thanks.

Your thanks is appreciated. :grinning:

Seriously, I'm glad that it helped you understand the change. :smile:

I'm likely a weak +1 here, but I would like to defer my vote until after the upcoming test day (wed). Can we perhaps wait until after that to vote (in ticket)?

Just curious, what is the reason for that? I mean during one day the FS must be so bad or people writing random garbage on their disks to break it to get it broken within one test day.

Well, there may well be install workflows or popular hardware that has issues. Much of the current data we have is: users who have been using it for ages in fedora in desktops and servers at facebook.

I suspect (but don't know) that most of the existing fedora btrfs users are folks who would have SSDs/nvram/new hardware and at least some of the people at a test day might have older hardware/spinning disks/etc that they use to test with.

I guess it would take something widespread and not easily fixable to change my vote, but on the other hand... whats the hurry? Why not seek more datapoints?

I'm likely a weak +1 here, but I would like to defer my vote until after the upcoming test day (wed). Can we perhaps wait until after that to vote (in ticket)?

Just curious, what is the reason for that? I mean during one day the FS must be so bad or people writing random garbage on their disks to break it to get it broken within one test day.

Well, there may well be install workflows or popular hardware that has issues. Much of the current data we have is: users who have been using it for ages in fedora in desktops and servers at facebook.
I suspect (but don't know) that most of the existing fedora btrfs users are folks who would have SSDs/nvram/new hardware and at least some of the people at a test day might have older hardware/spinning disks/etc that they use to test with.

Personally, I just got my first NVMe based computer a couple of weeks ago. I have one laptop with PCIe SSD as well, and the rest of my machines are hard drive-only. Count me old, but I tend to ride hardware out as long as I can.

I guess it would take something widespread and not easily fixable to change my vote, but on the other hand... whats the hurry? Why not seek more datapoints?

At least from my perspective, I don't know what else we'd do with the data other than go and fix bugs if any cropped up. We're fortunate that in Rawhide we can integrate fixes as they land in the mainline kernel because we roll with upstream and with Rawhide we even roll snapshots and prereleases, and I'm reasonably confident that everything will be fine by the time we roll out 5.9 final with Fedora 33 in the fall.

So I guess this is more of a "bias for action" kind of thing to me.

@kevin
The hard drive case is also used quite a bit at Facebook. I'm a sample of 1 but use it on hard drives and SD Card in a Raspberry Pi Zero of all things (with compression enabled) - as well as SSD and NVMe. The hard drive case magnifies latency a ton no matter the file system, the mitigations for this on Btrfs: inline extents (located with the inode in fs metadata) for small files, and delayed allocation accumulates random writes into sequential writes so long. Fsync can break that, and there's a significant bias in programs these days that favor file systems that overwrite+journal. Compression is also a considerable mitigator in that it'll reduce the read and write time, and increase throughput.

If the change is approved, there will be more and longer (probably enduring) test days. A not so subtle advantage of sooner approval is the default can be flipped in Rawhide, so that we can start produce install media with this change applied. Right now we can't do that. Fedora infrastructure lacks out of band test day media creation - so for Wednesday's test day this week, we can't in fact make it the default and test it as the default, so we'll need to use Custom partitioning with the Btrfs preset instead.

@dcantrell
It might seem unusual that Workstation WG has not yet voted on the proposal, but (a) this is a highly technical change, and most WG members are not file system experts, and some were hoping FESCo would weight in on the technical side; (b) there are changes that come up that have no advance approval, e.g. swap-on-zram change, the WG will vote on after FESCo and Test Day (which completed today), this too was rather technical.

It might seem unusual that Workstation WG has not yet voted on the proposal

I was hoping we would vote on this at our Workstation WG meeting today, but in the end we had several other items on the agenda and ran out of discussion time. I think it's fair to say the WG is very likely to approve a change to btrfs. But there are two remaining questions that we are still discussing: timeframe and testing plan. Regarding timeframe, some of us want to approve the change for F33, some are skeptical about that timeframe and want to instead approve it for F34. That's actually the main discussion point right now, when rather than whether. (We also have one WG member who prefers to stick with ext4, but I think everybody else is willing to switch.) There is also a proposal from @otaylor to have a community test and feedback period, potentially facilitated by UI changes in anaconda to promote btrfs testing, and in gnome-initial-setup for users to sign up to be contacted to provide feedback after a few months of btrfs usage. This proposal only reached the WG earlier this morning, so we don't have consensus on that yet either. We simply need more time to discuss. So I hope that explains why have not yet voted: we do mostly have consensus on switching to btrfs, but we do not yet have consensus on these important details. We're going to continue discussing and we'll figure it out.

So, for what it's worth, here's my official Fedora Project Leader opinion on this.

  1. I'm predisposed to "sure, let's try it!" for most things in Fedora. Features and First, after all. That goes for this too. The folks working on the proposal have done their proverbial homework, and I appreciate the active participation of the Facebook people and btrfs devs. It's a good proposal with real benefits and committed owners.
  2. For the record, with my "Red Hat liaison" responsibilities hat on: I'm not super-worried. I know RH's storage team has reservations, but they also have different use-cases. The RH Workstation team is already carrying an ext4/xfs delta between our Fedora upstream and the product, so this isn't a huge amount of new work. It'd be nice if RH Workstation were aligned, but, basically, so it goes sometimes. I've discussed with RHEL management and product, and while there's skepticism, it's not a problem.
  3. On timing: I prefer Owen's "btrfs with confidence" (Google doc) proposal, which is to do a two-part rollout over F33 and F34. In my judgment, there's a reasonable risk to users and to Fedora's reputation if we introduce the change to new installs first. We've done a lot of work to take the edge off of the "Fedora is too bleeding edge to take seriously" canard, and I don't want to lose that out of impatience. However, as the engineering steering committee if y'all think I'm being too cautious and want to okay this for F33, I'll do everything I can to back up that decision.

I'd like to make a counter-proposal for FESCo's consideration:

Let's make the switch now in Rawhide. Let's keep it in through the Beta release. If between Beta and GA we see a significant problem emerge (or lots of negative press, etc.) we revert it at Final Freeze. (We continue as we have been with having OpenQA test both flavors.) If things appear to be going smoothly, we continue with btrfs for GA.

If, after GA, we discover that it's negatively impacting a significant portion of our userbase, we can go ahead and say "Sorry folks, sometimes trying new things means failing" and revert the change for Fedora 34.

I'll note that this Change is only going to affect clean installs; anyone upgrading from F32 is not going to end up with a new filesystem (nor should they).

Sorry, I forgot to mention my main objection to Matthew/Owen's plan: we know from past experience (such as with systemd, dnssec, etc.) that attempting to encourage folks to try a new technology on their own before we make it the default never works. The set of people who try it out are generally the same set of people who would have done so without a bunch of announcements (and maybe one or two damned fools like me).

The only way to know for sure how this is going to turn out is to try it and have a backup plan in case it fails.

Let's make the switch now in Rawhide. Let's keep it in through the Beta release. If between Beta and GA we see a significant problem emerge (or lots of negative press, etc.) we revert it at Final Freeze. (We continue as we have been with having OpenQA test both flavors.) If things appear to be going smoothly, we continue with btrfs for GA.

This sounds like "accept the proposal and invoke the contingency plan if it's not ready to deliver, which is how we normally do things. Is the intent here to explicitly say "we're going to watch closely to make sure the contingency plan is invoked if necessary" or is there something more to this that I'm missing?

Is the intent here to explicitly say "we're going to watch closely to make sure the contingency plan is invoked if necessary" or is there something more to this that I'm missing?

I don't think so. I think you've got the idea here.

I like @sgallagh's approach. In this vein I want to reprovision my backup laptop with UEFI and btrfs sometime this week.

Let's make the switch now in Rawhide. Let's keep it in through the Beta release. If between Beta and GA we see a significant problem emerge (or lots of negative press, etc.) we revert it at Final Freeze. (We continue as we have been with having OpenQA test both flavors.) If things appear to be going smoothly, we continue with btrfs for GA.

This sounds like "accept the proposal and invoke the contingency plan if it's not ready to deliver, which is how we normally do things. Is the intent here to explicitly say "we're going to watch closely to make sure the contingency plan is invoked if necessary" or is there something more to this that I'm missing?

Yeah, that's pretty much what I'm saying. I was just trying to be highly explicit.

Now, I'll attempt to summarize the main technical concerns from the devel@ discussion:

  1. The main concern is that corrupted btrfs filesystems are more difficult to recover than ext4 in cases where the disk is failing or unreliable and has written corrupt data. Users who are unable to boot their systems due to filesystem corruption will need to follow different and more complex recovery procedures. But if a user's disk is failing in this way, the result with ext4 would be bitrot, the condition where random files are randomly corrupted with random data. If you take regular backups as you should, the bitrotted files will be backed up over your good copies; eventually your old good backups will be deleted, and then recovery is not possible. btrfs detects corrupted files and returns EIO to prevent applications from reading them at all, guaranteeing the bad data does not reach your backups. User data is sacrosanct, and btrfs protects it. So it's true that technical users may have more difficulty and less success in following recovery procedures with btrfs than with ext4, but bitrot is worse. Nobody can repair data lost to bitrot once it gets into backups. (Based on Facebook's statistics, we expect failure to mount to occur roughly as often in practice with btrfs as with ext4, although Eric on devel@ also found that btrfs fails significantly earlier with larger numbers of synthetic errors.)
  2. Some users also report noticeable performance issues in certain edge cases. Such reports are uncommon, but there was one particular report of this during the devel@ discussion that drew my attention. Chris has a theory as to what went wrong in that particular case, but such cases will need to be analyzed in bug reports to be properly fixed. In general, certain virtual machine and possibly database workloads where the virtual machine manager or database application does not mark its data as nodatacow may be problematic. Our judgment is that such issues are not common or severe enough to derail the change proposal, given all the benefits provided by btrfs.
  3. Finally, we have spurious ENOSPC issues when the disk is not yet completely full, under certain workloads. The problem is that btrfs has run out of metadata space. This is mostly a solved problem, but Josef is working on a few remaining edge cases. Again, our judgment is that these cases are not common or severe enough to derail the change proposal.

This comment is meant to summarize my understanding of the user feedback we've received on devel@. Asides from data checksumming, it doesn't address the other benefits of btrfs (which the change proposal discusses).

Edit: Note that in this post, I'm not speaking on behalf of the WG, which has not yet voted.

My previous comments were effectively an approval of this Change, but so it's clearly written:

+1

@chrismurphy> The hard drive case is also used quite a bit at Facebook.

That was just a random generic example... I meant that lots of people in a test day are likely to have more varied hardware and cases than the change owners or facebook. :)

@sgallagh > Your proposal basically makes it so we only invoke the contingency plan at final? I'm not a fan... that results in a mad scramble at the last minute to revert things and hopefully not forget something and make release candidates. I'd prefer we revert at beta like anything else...

@sgallagh > Your proposal basically makes it so we only invoke the contingency plan at final? I'm not a fan... that results in a mad scramble at the last minute to revert things and hopefully not forget something and make release candidates. I'd prefer we revert at beta like anything else...

Reverting at Beta would not be meaningfully different than punting to F34. This Change only applies to new installs... Beta is the only opportunity prior to GA for releasing install media.

Let me rephrase a bit: if there's some serious technical problem prior to Beta (such as we discover it's impossible for GRUB2 to boot to btrfs or something), we should revert then. But if we are capable of shipping with this at Beta, I think we need to or we will never get the real-world data we need.

I'd like to make a counter-proposal for FESCo's consideration:
Let's make the switch now in Rawhide. Let's keep it in through the Beta release. If between Beta and GA we see a significant problem emerge (or lots of negative press, etc.) we revert it at Final Freeze. (We continue as we have been with having OpenQA test both flavors.) If things appear to be going smoothly, we continue with btrfs for GA.

@kparal actually proposed exactly the same idea in a QA team chat today. I think we all agreed it would be a good idea. The change is easy to make and easy to revert and only affects people who install a pre-Beta OS. I can't see any drawbacks to just going ahead and merging it as soon as possible, if there's at least a realistic possibility of the Change being approved.

We also think the 'different and more complex recovery procedures' are one of the more significant issues with this Change. We think if it's accepted that we definitely need to have a good recovery guide that is very easy to follow written up, reviewed and ready to go at release time. We will definitely take part in testing such a guide.

@adamwill fwiw the recovery flow is something we're actively working on, both in terms of resiliency improvements to address the feedback from devel@ and of documentation. On the latter note, we do plan to have Fedora-specific docs to highlight the recovery options and guide users through the workflow as needed.

Thanks @dcavalca -- that's really helpful.

Alright, if QA is ok with reverting at final then I guess I can be too, but if we do I'm sure I will grumble about it. :)

I would like to go on record to urge FESCo to reject the proposal to make BTRFS the file system default for Fedora. I've responded to the pertinent section of the proposal below, with my comments in Bold Italic. I have also noted the conditions which I believe need to occur before this proposal should be allowed to move forward. It's basically a situation about accountability and ownership.

🔗 Red Hat doesn't support Btrfs? Can Fedora do this?

Red Hat supports Fedora well, in many ways. But Fedora already works closely with, and depends on, upstreams. And this will be one of them. That's an important consideration for this proposal. The community has a stake in ensuring it is supported. Red Hat will never support Btrfs if Fedora rejects it. Fedora necessarily needs to be first, and make the persuasive case that it solves more problems than alternatives. Feature owners believe it does, hands down.

Missing in this entire statement is that Fedora serves as a strategic upstream for Red Hat. In 2017 Red Hat took the action to deprecate BTRFS. Why? They must have had a reason. If you're interested in making a case to persuade Red Hat to reconsider, you first need to understand why Red Hat deprecated BTRFS in the first place. Was it a technical issue? Did they just get tired of waiting for it to reach an official stable status? How can you believe it resolves Red Hat's issues "hands down" without first identifying those issues? I noticed how this question was added to the proposal, and then removed with the comment of "Change owners cannot answer questions about RHEL..." Seriously? It's your proposal. Are you hoping that throwing your hands up and saying "Oops, we can't do it, I don't work for Red Hat or not my problem" will make the issue go away?

The Btrfs community has users that have been using it for most of the past decade at scale. It's been the default on openSUSE (and SUSE Linux Enterprise) since 2014, and Facebook has been using it for all their OS and data volumes, in their data centers, for almost as long. Btrfs is a mature, well-understood, and battle-tested file system, used on both desktop/container and server/cloud use-cases. We do have developers of the Btrfs filesystem maintaining and supporting the code in Fedora, one is a Change owner, so issues that are pinned to Btrfs can be addressed quickly.

That may be true, but the fact that something has been used over the past decade is irrelevant to the elephant in the room - which is the stability of BTRFS. The proposal mentions "mature, well-understood and battle-tested file system" but avoids using the term stability. Which begs the question, is BTRFS stable? Let's examine their own documentation: https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F

"Is BTRFS stable? Short answer: Maybe."

Really? Even the "Pragmatic answer" doesn't exude confidence... "As always, keep backups, test them, and be prepared to use them." ¯\(ツ)

These aren't my words... I didn't write them. They are written by the BTRFS project in a section that they created to specifically discuss the stability of their filesystem. It isn't the parsing of words and/or phrases from various mailing lists posts or articles to weave a particular narrative.

I'm all for testing out new technologies and pushing the envelope in providing the most recent code updates in packages - but we're not talking about a browser or DE here. We're talking about a filesystem where the reality is many people aren't going to have adequate backups. Yes, we can shake our fingers and tell them shame - but we certainly should not needlessly put them in more vulnerable situations. Additionally, this proposal isn't about letting someone opt-in to use BTRFS - it's about automatically making the decision for them - and thereby affecting the most naive users.

Before Fedora should even consider BTRFS as a default, the BTRFS project needs to own their product and clearly state which, if any, of the functionality is STABLE. In fact, that should be a very simple ask. After all, it's mature, well-understood and battle-tested, right? They can update their online documentation and make an announcement. Done! Investigate and address what were the Red Hat concerns and explain how they affect or do not affect Fedora. Why is all this being glossed over and what is the hurry?

This proposal, as written should be rejected.

Before Fedora should even consider BTRFS as a default, the BTRFS project needs to own their product and clearly state which, if any, of the functionality is STABLE. In fact, that should be a very simple ask. After all, it's mature, well-understood and battle-tested, right? They can update their online documentation and make an announcement. Done! Investigate and address what were the Red Hat concerns and explain how they affect or do not affect Fedora. Why is all this being glossed over and what is the hurry?

They have a nice table for the purpose actually https://btrfs.wiki.kernel.org/index.php/Status, you should read the wiki sometime, it's pretty cool ;)

Before Fedora should even consider BTRFS as a default, the BTRFS project needs to own their product and clearly state which, if any, of the functionality is STABLE. In fact, that should be a very simple ask. After all, it's mature, well-understood and battle-tested, right? They can update their online documentation and make an announcement. Done! Investigate and address what were the Red Hat concerns and explain how they affect or do not affect Fedora. Why is all this being glossed over and what is the hurry?

They have a nice table for the purpose actually https://btrfs.wiki.kernel.org/index.php/Status, you should read the wiki sometime, it's pretty cool ;)

I have read it... have you? What is their definition of "OK"?
OK: should be safe to use, no known major defficiencies

The spelling error is theirs... I did a cut and paste.

Guys, it's not hard. As I mentioned I didn't write this stuff - and I'm not parsing and cherry picking words and phrases like apparently those who are supporting this proposal.

Again:
Before Fedora should even consider BTRFS as a default, the BTRFS project needs to own their product and clearly state which, if any, of the functionality is STABLE. In fact, that should be a very simple ask. After all, it's mature, well-understood and battle-tested, right? They can update their online documentation and make an announcement. Done! Investigate and address what were the Red Hat concerns and explain how they affect or do not affect Fedora. Why is all this being glossed over and what is the hurry?

@hellcp Let's keep the sarcasm down please. I know there's a smiley but it gets out of hand.

@gbcox If you have concerns about Fedora as RHEL upstream that aren't addressed by my comment above, I'll be happy to discuss them with you offline. (Well, online, I mean, but a different line.)

As for "stable"... that's a tricky word and always has been for Fedora. It means a dozen different things. So while it would be more confidence-inspiring for the wiki to use less equivocal wording, it's all open source and comes with no warranty and I understand not wanting to make guarantees. The wording should be taken in context.

Anyway... long discussion really shouldn't go in this ticket -- it should go back in the devel-list thread which is linked at the top of the ticket.

@hellcp Let's keep the sarcasm down please. I know there's a smiley but it gets out of hand.
@gbcox If you have concerns about Fedora as RHEL upstream that aren't addressed by my comment above, I'll be happy to discuss them with you offline. (Well, online, I mean, but a different line.)
As for "stable"... that's a tricky word and always has been for Fedora. It means a dozen different things. So while it would be more confidence-inspiring for the wiki to use less equivocal wording, it's all open source and comes with no warranty and I understand not wanting to make guarantees. The wording should be taken in context.
Anyway... long discussion really shouldn't go in this ticket -- it should go back in the devel-list thread which is linked at the top of the ticket.

I am concerned about Fedora's reputation and us making something default with such wishy-washy wording - bestowing default status, especially when it's a filesystem should be a very high bar - and we should be asking very tough questions and demanding answers. It's nothing personal, it's just good project management. Regarding the word stable, no one is asking for guarantees in software, but the BTRFS project has been quite unique in trying to straddle the fence for over a decade now. They imply stability, but when something goes wrong it's well, we said maybe, should, etc.

Fedora's reputation has gone from being a tech toy to a reliable, stable system. I'd hate to have that screwed up.

My purpose of posting wasn't for discussion. I want my views to be seen and hopefully considered by FESCo when they make their decision. The reason I responded was that it was implied that I haven't read the BTRFS information regarding functionality and stability. I have, and I believe what they currently have posted isn't sufficient to be considered as a default for Fedora. Again, nothing personal - but it is what it is.

@kevin the practical implementation of the change is not complicated and I'm pretty confident it can be reverted very quickly and simply if necessary. if the change was more complex it'd worry me more.

Well, I was thinking of that but also https://pagure.io/fedora-kickstarts/pull-request/656 and documentation changes, websites, etc.

Anyhow, I guess I'm a +1.

Shameless +1

APPROVED (+7, 0, -0)

Metadata Update from @ngompa:
- Issue tagged with: pending announcement

4 months ago

Guys, what is going on? This ticket just got posted yesterday, and the meeting isn't until tomorrow To say that the fix was in is an understatement. Why have rules and participation guidelines if you just make your mind up ahead of time and railroad things through without consideration for any discussion. This is just disappointing on so many levels. Not to mention having people voting for their own proposals. What a joke.

@gbcox Most proposals are approved in-ticket, unless there's a -1 from a FESCo member, so this wouldn't have come up in tomorrow's meeting anyway. You're welcome to disagree with the decision, but the voting followed the ticket policy.

By my count, there were nearly 350 BTRFS-related messages on devel since the proposal was announced. With the holiday weekend, this got a longer community comment period than normal. It's reasonable to think that in the course of that discussion, FESCo members made up their mind, especially since this proposal had support from all of the desktop variants.

You may think the decision is wrong, but there's no cause to insinuate an ulterior motive.

@kevin I was kinda figuring we wouldn't necessarily lock in all the documentation changes and so on right away, but rather do the actual code changes ASAP and see how that goes.

@bcotton I read the policy... so you're telling me that in less than 24 hours a ticket is posted and approved. That gives new meaning to the term "fast track". Doesn't hurt if you're also voting on your own proposals. Personally, doesn't matter to me what the default is... but I believe what has occurred here today has done a major disservice to the project. So you can try with the I'm shocked, shocked, to find that gambling is going on in here." approach, but no objective person is believing it. The fix was in.

@gbcox the ticket is an implementation detail for voting and tracking practical things. There's no requirement in any process for it to be open for a long time, or any reason why there should be. It's not a discussion forum. The main forum for discussion and debate is on the devel list. Where this has been under extremely active discussion and debate for like two weeks, which you should know as you were involved in it.

@bcotton I read the policy... so you're telling me that in less than 24 hours a ticket is posted and approved. That gives new meaning to the term "fast track"

No, that's literally the point of "fast track". It's been used on numerous occasions for less than 3 hours since a ticket was posted. If any FESCo member wanted to slow it down, they had that opportunity.

Doesn't hurt if you're also voting on your own proposals.

Which is perfectly legitimate. We had the debate about this on fedora-devel in May or June. The general consensus was that it is not a conflict of interest for FESCo members to support their own proposals.

Personally, doesn't matter to me what the default is... but I believe what has occurred here today has done a major disservice to the project. So you can try with the I'm shocked, shocked, to find that gambling is going on in here." approach, but no objective person is believing it. The fix was in.

All the actually objective people recognize that the discussion was held in public with basically all of FESCo involved at one point or another on the mailing list thread. There is no reason whatsoever to rehash all the same arguments on a procedural ticket. The debate was held and FESCo members made their decisions.

Also, if you want to be pedantic: I (a Red Hatter) initially argued against this and changed my opinion as the conversation went on and my concerns were addressed. I received new information, incorporated it into my decision-making process and when I was done, I decided that this proposal was worth moving ahead with.

Now, whether or not you agree with the decision, the decision has been made. You are welcome to reserve the right to say "I told you so" if it doesn't pan out, but please stop harassing people for disagreeing with you.

@sgallagh I'm not harrassing anyone. You're projecting. I completely understand how this project is run now.

@gbcox I suggest you continue discussion on devel@. To be more persuasive, I would consider addressing technical concerns rather than expectations regarding how the upstream project communicates stability status on its wiki. E.g. I tried to summarize known issues in https://pagure.io/fesco/issue/2429#comment-663921. If you feel that's not a very good summary, let's continue discussion on devel@.

Test day went well.
https://testdays.fedorainfracloud.org/events/88

Many KVM based tests are to be expected this early in the cycle. But we may want to think of ways to activate Fedora pride to get more testers, early adopters, and build user to user support.

I'd like to hear from the Workstation teams regarding this change as well as the filesystem team. This change is proposed for the desktop variants....is this desired by GNOME, KDE, any other desktop environments that produce install media?

Yes. All desktop spins were asked and they assented. Most of the change owners are in fact spin/edition owners that have agreed to the change.

Does the filesystem team have any comments? My understanding is we have no one working on btrfs nor committed to addressing btrfs issues that may come up.

Nobody at Red Hat, but @josef from Facebook is being formally committed to work on Fedora Btrfs issues. He is also a change owner, along with @dcavalca and @salimma who are working on the userspace integration side of things.

Withholding my vote until I hear from the above.

Hopefully this satisfies your query.

I am still not convinced this is a good default for Fedora Workstation. My vote is a -1 on this proposal. I under the impression that we would discuss this in a meeting and vote there. My vote has been incorrectly recorded as approval in this case, which troubles me.

My vote has been incorrectly recorded as approval in this case, which troubles me.

Your vote was not recorded as an approval. You were essentially listed as +0, since you withheld your vote and we reached the threshold without you.

Should we repeat the vote on a meeting to avoid confusion?

I've been concerned about the need for disk maintenance on btrfs. The following posts are relivant:

https://discussion.fedoraproject.org/t/btrfs-on-fedora/21611

https://pagure.io/fedora-magazine-proposals/issue/98

While no longer a member, by policy, it should not have been approved when it was:

Once a ticket has a formal proposal offered, FESCo members have one week to either vote for or against it or else propose the ticket for the next weekly meeting agenda. At the end of that one week, if the proposal has gained at least three "for" votes and no "against" votes, it is approved. Any "against" votes mean that it goes onto the next meeting agenda, unless there are at least 7 negative votes and no positive ones, see below. If the week passes and the required number of votes have not been met, the proposal is extended by one further week and the minimum requirement becomes a single positive "for" vote. This is intended to ensure that proposals do not languish.

This ticket was submitted 1 week ago today, and listed as "approved" after only 2 days. Acceptable if every member has voted to approve, not so much if a member hasn't voted. If that policy has change, the documentation is out of date.

While no longer a member, by policy, it should not have been approved when it was:

Technically, it met the requirements for the fast track policy, which triggers acceptance or rejection when there are seven votes in one direction with none in the other. However, I agree that in this case, technical compliance with the policy is at odds with the intent. I have an idea that I'm going to submit to FESCo shortly to improve the policy for cases like that.

Edited to add a link to the FESCo ticket with the policy proposal.

Should we repeat the vote on a meeting to avoid confusion?

I would prefer that. I imagine the ship has sailed, but I did feel excluded from this change request and subsequent vote.

Metadata Update from @ngompa:
- Issue tagged with: meeting

4 months ago

@dcantrell Sure, I've tagged it for the meeting on Wednesday.

Metadata Update from @dcantrell:
- Issue untagged with: meeting

4 months ago

Uhh, not sure how that happened.

Metadata Update from @dcantrell:
- Issue tagged with: meeting

4 months ago

Metadata Update from @zbyszek:
- Issue untagged with: pending announcement

4 months ago

Approved (+8,0,-1) in today's meeting.

Metadata Update from @bcotton:
- Issue untagged with: meeting
- Issue tagged with: pending announcement

4 months ago

-1, but who cares.

I was sitting on btrfs 2013 - 2015 years, because at that time it was touted in many blogs as the file system of the future and a replacement for ext4. But btrfs does did not give me any benefit for home using. All real-life task (web surfing, gaming, programming) with this fs is noticeably slower than ext4 and xfs. My HDD was constantly rustled after turning on my computer.
What benefits give me BTRFS? I haven't used any exclusive btrfs features in three years. Do you really think that someone wants on a workstation to make FS snapshots? I make backup all important files manually and place the archive.
For home using would be a more interesting caching layer for HDD. I really await when bcashefs would be mainlined in the kernel.

Maybe we can stick with ext4/xfs for HDD for now and only suggest BTRFS by default for SSD?

I think this particular FESCo ticket is not the right place for such type of discussions. Please start new thread on devel@ and share your concerns there.

Metadata Update from @zbyszek:
- Issue untagged with: pending announcement
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

4 months ago

Login to comment on this ticket.

Metadata