On Tue, Jun 30, 2020 at 4:02 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Tue, Jun 30, 2020 at 4:30 PM Justin Forbes <jmforbes@xxxxxxxxxxx> wrote: > > > > On Tue, Jun 30, 2020 at 1:39 PM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> wrote: > > > > > > On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote: > > > > On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro <mcatanzaro@xxxxxxxxx> > > > > wrote: > > > > > > > > > > > > > > > On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher > > > > > <sgallagh@xxxxxxxxxx> wrote: > > > > > > > > > > > For the record, as this directly affects the Workstation deliverable, > > > > > > I will be voting -1 until and unless the Workstation WG votes in > > > > > > favor. > > > > > > > > > > > > > > > > > > > > > > > > Yes, it's a large set of Change owners, but since only two of them are > > > > > > Workstation WG members, they are not representative of that group. > > > > > > > > > > > > > > > > > > > > Workstation WG hat on: > > > > > > > > > > > > > > > > > > > > I don't think there's any need to vote -1 for that reason alone. The > > > > > Workstation WG has discussed the change proposal at several meetings > > > > > recently (really, we've spent a long time on this), and frankly we were > > > > > not making a ton of progress towards reaching a decision either way, so > > > > > going forward with the change proposal and moving the discussion to > > > > > devel@ to get feedback from a wider audience and from FESCo seemed like > > > > > a good idea. Most likely, we'll wind up doing whatever FESCo chooses > > > > > here, but unless FESCo were to explicitly indicate intent to override > > > > > the Workstation WG, we would not consider a FESCo decision to limit > > > > > what the Workstation WG can do with the Workstation product. At least, > > > > > my understanding of the power structure FESCo has established is that > > > > > the WG can make product-specific decisions that differ from FESCo's > > > > > decisions whenever we want, unless FESCo says otherwise (because FESCo > > > > > always has final say). That is, if FESCo were to approve btrfs by > > > > > default, but Workstation WG were to vote to stick with ext4, then we > > > > > would stick with ext4 unless FESCo were to say "no really, you need to > > > > > switch to btfs" (which I highly doubt would happen). So I don't see any > > > > > reason to vote -1 here out of concern for overriding the WG. > > > > > > > > > > > > > > > > > > > > > > The problem is that the request as discussed reads as "FESCo says use > > > > it for workstation" vs "FESCo has no problem with Workstation saying > > > > they want btrfs" or "FESCo says use btrfs as default". Yes it says > > > > "desktop variants" but only 1 variant really counts and that is > > > > Workstation. So yes, either Workstation agrees to it or it isn't > > > > getting voted on. If Workstation can't come to an agreement on it, > > > > then the proposal is dead. Anything else is an end-run and a useless > > > > trolling of people to see how many rants LWN counts in its weekly > > > > messages. > > > > > > Well, it's not only Workstation that this proposal is trying to throw btrfs > > > on, but the other desktops as well, such as KDE Spin. > > > > How is that even a thing? Shouldn't a spin maintainer be responsible > > for choosing the defaults of their spin? This proposal seems fairly > > absurd in the regard of dictating what other people should do. > > For what it's worth, I asked spin owners from each one before adding > them. That's why the change covers them all, they all assented to it. > I am doing all the work for it, but I asked for their approval to be > covered under this. > > Please don't assume such absurd things like that, especially given the > list of change owners and listed responsible entities. > I honestly hadn't considered it until it came up that the Workstation WG has not come to agreement on this change yet. Either way, it is my belief that the spins should be able to decide what they want to use, when they want to use it. If they have bought in, that's great. >From a kernel standpoint, the only change being asked here is to make btrfs inline instead of a module. If it is to become the default fs for any spin, I don't have a problem with that. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
