> Am 28.05.2021 um 23:08 schrieb Chris Murphy <lists@xxxxxxxxxxxxxxxxx>: > >> …… > > All I mean by this is to push back on the idea that the proposal for > Cloud translates into delaying the decision for Server by 5 or 10 > years. Not that Server folks should escalate their discussion. What I originally meant was the idea to discuss / explore opportunities to coordinate or join the efforts of Server WG and Cloud WG and to better aline both. But that idea seems to me got silently out of attention over time. We discussed that an the beginning of March, Server WG picked it up again at the end of March, and there was a brief mention in Cloud WG in early April. Since then there has been silence. > My working assumption is substantive public > discussion, to reveal the pros and cons of the proposal, in order to > come to a decision. The proposal is not the decision. We fully agree on that. >> And when we address discussion and evidence: What I miss is a prior detailed discussion of this change in cloud WG and coordination with other possible affected areas, e.g. server or CoreOS. Cloud Working Group did not happened for years, then there were a few short, sparsely-attended and content-dry meetings. A range of existing problems, starting with lack of documentation. A hesitancy to make any change currently to the cloud artifacts (expressed by Dusty Mabe at that March meeting, 3). And then out of nowhere the file system conversion, a very central element. To me, it seems like a playground for missionaries to gain ground, certainly not like a considerate and methodical long-term design. > > I don't agree it happened out of nowhere. It's been floated by various > folks over the years, even before Workstation edition switched to > Btrfs by default. Fedora has quite a lot of sprawl, it's a diverse > community, not all conversations happen on devel@ so it can be easy to > draw a conclusion that it's sudden. But that is the whole point of the > change proposal process, is to make a broad and grand announcement on > the primary development list, expressly because we don't want folks > missing big changes. Now is exactly the time to dig into the > drawbacks, liabilities, risks of proposals, and weigh them against the > proponents' typically strong take in favor of the change or else they > probably wouldn't have submitted the proposal in the first place. > > Take it from me, I really like the adversarial process. I don't mean > this in the negative connotation, but rather the legal denotation. We > should have a debate. That time is right now, in this thread. And I > welcome it. The mail came from Ben as the FPM and not as part of an invitation to cloud irc meeting nor as part of a broader programmatic discussion in Cloud WG about the continued long-term evolution of cloud images. That is what irritated me and what I missed. I see the invigorating effect of an adversarial process. However, I worry that the long-term programmatic aspects will be neglected. And it emphasizes very much the differentiating and the separating. That’s fine in a legal process, but not in a community process. And part of such a programmatic discussion would also be the exploration of common features of server and cloud, of possible adaptations and synergy effects, which was discussed at the beginning of the year and planned after Dusty's return. All that is gone now as a result of that action, virtually in an "overnight coup d'état". And this was (and is) my argument, not various single technical properties, advantages or disadvantages of BTRFS. And that is what I regret. _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
