On Tue, Nov 5, 2019 at 4:35 PM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > > On Tue, Nov 5, 2019 at 8:15 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, Nov 05, 2019 at 01:08:23PM -0500, Neal Gompa wrote: > > > I think I mentioned that it would be possible, as OpenPKG actually > > > worked this way. > > > > > > The key for this would be improving the user-experience with > > > interacting with source RPMs and spec files with DNF. We've optimized > > > *heavily* for remote builds, but a good chunk of how Gentoo's > > > mechanism works is built around supporting local permutations. We just > > > don't have that fleshed out yet. > > > > Well, exactly. This is what I meant with my short "who is going to do that > > work?" comment. Gentoo's solution is not a drop-in thing for Fedora and > > would require changes to RPM, DNF, and the *significant* work of figuring > > out what all this would mean in a binary-focused distribution. We'd > > certainly need a whole *new* MBS equivalent, and there's surely a ton of > > "unknown unknowns" lurking as well. > > > > And then all of that would get us to... sort of where we are now? Basically > > the same thing as with Modularity's "virtual repositories" approach with > > different tradeoffs? > > > > If someone thinks that my skepticism is wrong and that the Modularity team > > is on the complete wrong path, I have no objection to anyone who wants to > > work on something new solution, either as a prototype or a more detailed > > proposal. Awesome! If it gets to the point where it's a viable alternative, > > we can weigh those options. But the team in Fedora actually working on > > Modularity today includes some pretty smart, very invested Fedora people and > > I don't feel bad at all about standing up for their wanting to continue to > > refine the path they've chosen and are working on. > > > > To me this is just like the Flatpak and Snap thing — both have some > > strengths and weaknesses. I'm absolutely supportive of the effort of the > > Workstation team (and Red Hat's Desktop team!) to drive that work in Fedora. > > I happen to personally (and professionally) think that's good for Fedora. > > But I'm _also_ happy to make room for you and whoever else to work on doing > > something similar with Snap. > > > > If someone were to come by and say "I don't understand why you're doing all > > this, when it's been solved by AppImage since 2004", I'd say the same thing > > I'm telling Randy: you're welcome to work on that, but it's rude to tell the > > people who are invested in building something different that _they're_ the > > problem. > > > > If that's demoralizing... well, I don't know what to to tell you. I want to > > support people doing things and exploring and contributing. > > That's all well and good, but you seem to be forgetting that people > are actually getting *paid* to work on modularity for fedora. > Any proposal for an alternative, which apparently needs to arrive at > least at MVP / proof-of-concept quality before it is even *considered* > as an alternative without getting called "trolling", can likely only > be worked on in somebody's spare time. I don't think that's a fair > requirement, and "exploring and contributing" will stay limited to RH > employees if that's the case. What you call unfair, I call open source winning in the industry. Does it create an imbalance between funded vs. unfunded work? Yes. That is the reality of the software landscape today though, and I think it's a net good thing even if it is somewhat departed from what people consider open source "roots". I would suggest people wanting to deliver competing solutions be vocal about their intentions and provide frequent updates and comparisons. It's not trolling if they're actively working on it, despite the development speed. They might not be able to produce as much code as funded development, but often it's the ideas that matter. Alternatively, pitch in those ideas and critiques to the project that's being worked on and shape the direction that way. josh _______________________________________________ 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
