Btrfs SIG Established For Advancing Btrfs Interests On Fedora

[intelfx]

"Some of us working on Btrfs in Fedora have decided to start a SIG to foster both better coordination, and also provide an easier way for others in the community to get in touch."

This is not a goal, this is "I wanna do stuff, wanna do stuff with me?"

"We definitely have more Btrfs enablement to pursue in the future - bootable snapshots being one, transparent encryption another (pending it making it into the upstream kernel) [...]"

this doesn't seem to be in the original post, but do these two things warrant creating a sig for it? I assume there are other things, but it would be nice to know what they are.

"Our goal is to deliver the highest quality experience leveraging the capabilities Btrfs has to offer [...]"

A mission statement, I don't consider vague statements like these to be "actual goals" it's not that useful in determining the worth of a dedicated sig

You asked a question, you were given a likely answer based on public sources.

If you actually wish to argue about whether this SIG is worth its existence, I suggest you contact the members of said SIG (and/or those with decision-making authority who oversee SIG creation) and argue with them.

[woddy]

but why? What are the actual goals this intends to accomplish?

I guess they want to make the best use of some Btrfs features, hence the choice to have a dedicated workgroup. The last time I tried Fedora, it still lacked many features, which are present for example in openSUSE, including perhaps graphical tools for better management of snapshots.

[pokeballs]

I thought BTRFS was already the default on Fedora? They were one of the first distro to switch to it.

[johnny]

I imagine they could use snapshotting as a part of or replacement of certain functionality in their atomic distros' functionality. You could make a subvolume w/ all your system stuff snapshottable and then your system is protected from all of issues like power outages. So lots of the benefits of atomic distros supported at the filesystem level instead.

This is like what opensuse's Aeon does right? If they wanted to do that, it seems like they would have already. Maybe they didn't think it was ready yet?

[Quackdoc]

I guess they want to make the best use of some Btrfs features, hence the choice to have a dedicated workgroup. The last time I tried Fedora, it still lacked many features, which are present for example in openSUSE, including perhaps graphical tools for better management of snapshots.

really? I don't even understand how it *can* lack features, it's a kernel thing right? As for graphical tools, I do get that, but is that within scope of a SIG to develop? I don't really understand the scope of the issues it has, but then again, I don't use fedora lately, and being arch, maybe I take for granted how easy arch is to setup things... But if setting up btrfs to be consistent requires fedora to have a dedicated sig for it then good I guess. I just don't understand how many problems it would need to have for a dedicated sig

[Vermilion]

This is not a goal, this is "I wanna do stuff, wanna do stuff with me?"

I don't know why you don't consider creating a space for like-minded people with its own mailing list and stuff to collaborate and plan future efforts as a valid goal on its own. That's what the majority of current SIGs are about, with similarly worded goals/missions.

this doesn't seem to be in the original post,

These points were all taken from the original SIG announcement, linked in today's post which is just a confirmation that it is now operational.

[Espionage724]

I keep using EXT4 on Fedora until there's a compelling reason to change.

I used XFS since RHEL did

[ahrs]

I think it would be cool to explore the use of snapshots more, not just for rollbacks but for use in $HOME too. One of the things I do on my system is make a ~/.config its own subvolume and have Snapper configured to take snapshots of it. This is really nice because I can easily diff old snapshots to see what's changed in the ~/.config or rollback older state. Some programs store way more than they need to in ~/.config though, Chromium has all sorts in there, cache, cookies, databases, etc .

[pWe00Iri3e7Z9lHOX2Qx]

Automatic and bootable snapshots on package changes should already be a thing by now just like OpenSUSE has done for many years. I'll be excited if they add that. Going immutable shouldn't be the only way to get easy rollbacks.

[Old Grouch]

Automatic and bootable snapshots on package changes should already be a thing by now just like OpenSUSE has done for many years. I'll be excited if they add that. Going immutable shouldn't be the only way to get easy rollbacks.

I just wish for file versioning, and quasi-continuous snapshots, like NILFS2 (all synchronous writes checkpointed, asynchronous writes at regular short (configurable) intervals; any checkpoint can be converted to a snapshot).