On Sat, Feb 2, 2019 at 10:37 AM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > > On Thu, Jan 31, 2019 at 8:19 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > On Thu, Jan 31, 2019 at 6:58 PM Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > > > > > > On Thu, 31 Jan 2019 at 07:28, Igor Gnatenko <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote: > > >> > > >> Problem №1: Build-only packages > > >> > > >> Rawhide gating makes this much more complicated because builds appear in buildroot slower, updating group of packages would need side tags and it’s just painful to work with. > > >> > > >> https://pagure.io/fesco/issue/2068 > > >> > > >> And, after all, those packages shouldn’t be shipped to users. > > > > > > > > > My main problem with this is the above. Yes Joe Desktop User isn't going to see/need that package.. but we have a LOT of packagers who take our stuff and rebuild it for themselves for various reasons. I find it hard to put together the proposal which is supposed to make developing/packaging easier with making developing/packaging harder. Whether you want it to or not, this comes across as "If you want to use Go or Rust, you will need our special set of tools which we keep hidden." > > > > > > > This is actually something I really don't like either. But the Fedora > > leadership has pushed very hard on the concept of having packages that > > aren't available to "normies", and require special tooling to be able > > to leverage (that for various reasons, I can't even use as a third > > party packager!). That's a big part of the core to how Modularity is > > being used. The CRB in RHEL 8 is another example of this. But fixing > > I'd like to understand why you see RHEL 8 Code Ready Linux Builder as > an example of what you're talking about, but I think that's for a > different email. > The problem is that it's a symptom of a greater issue, which is that RHEL is no longer self-consistent as a distribution. Wiring up RHEL 8 into my build process is functionally impossible without rebootstrapping and building all the module components as "normal" packages. But there are a class of packages that simply don't exist in any form: packages that are used exclusively build-time. We started seeing this problem come about with RHEL 7 over time as CentOS 7 rebuilt new point releases. RHEL 8 takes that to a whole new level. And the CRB wasn't even published as part of the RHEL 8 beta public repos, which made it impossible to build anything using it. Fedora is starting to do the same thing. One of the major points of contention I've had with Igor in the Rust SIG was the choice to stop publishing Rust crate packages that were used to build applications themselves when we switched to modules. It's essentially vendoring all in but name. But as we've talked about it, I realized that we basically have no choice, because the people in control of the tooling have not been receptive to caring about our problems and working with us to improve it. But it means that downstream people cannot easily take our stuff, modify it, rebuild it, etc. That's a huge loss from my point of view. > > this is very hard when few others see it as a problem. There was even > > talk of not publishing SRPMs of packages that make up modules a while > > ago. That idea died very quickly thankfully, but I don't know how > > people think of these things anymore. > > > > I'm tired of fighting... Our tools haven't improved enough to handle > > our new challenges in the Fedora way, because it's hard for people in > > the community to experiment and explore in this manner. My hope is > > that with something like MBI, we can finally put the power to > > experiment and develop tooling that actually makes sense for Fedora > > (rather than clearly being designed for RHEL and shoehorned into > > Fedora) without all the pain and agony of people imposing RHELish > > requirements. There's no way we can evolve and meet the needs of our > > communities without some way for people to "play". > > I don't understand what is preventing anyone from building such tools > or communities. Why can't you do what you want? > Right now, it doesn't matter what I want to do. I don't have the resources to host infrastructure and I don't have the buy-in from people to consider new ideas that *I want to implement*. > > COPR was supposed to be that outlet, but no one gives a damn about it. > > Everyone complains that the service is "bad" and that the design is > > "bad" but no one wants to actually constructively improve it. The > > quality of service on COPR has fallen due to lack of care and > > unwillingness to invest, so what are we supposed to do? The horrible > > thing is that COPR is successful *despite* that. COPR is an > > interesting and cool service, and I would have loved to see an > > eventual merger of the Koji and COPR systems (because there are > > awesome attributes to both and we should have a large and strong team > > actually supporting the literal core of the distribution), but it > > won't happen because everyone thinks the COPR system is terrible even > > though it's not really. > > > > I've been arguing for literally years about our shortcomings. I've > > built tools for working around pitfalls in the Fedora workflow for my > > personal use. I've personally explored how other people and other > > distributions do things. I got my hands dirty to learn about other > > ways of doing things. I've used that knowledge and expertise to avoid > > those mistakes when deploying package and image construction > > infrastructure for $DAYJOB. But it deeply saddens me that I have not > > been able to make any meaningful progress in convincing anyone that it > > was something that we should invest in. > > You've used the word "invest" twice in your email, so perhaps the > answer to my above question is "because I/we don't have enough funds > and/or time to make it happen"? If that's the case, and I'm thinking > it likely is, then I have no good answer for you. People choose to > invest their money and time in the things they are interested in or > see long-term value out of. Corporations (which are not people) > choose to invest resources (machine, monetary, human) in things they > see as providing value to their long-term business interests. > While money is helpful, the real problem is that people don't see it as a priority to work with the community to resolve these issues. I'm happy to help with doing the work, but I can't do it alone. This is one of those things I *literally* cannot do alone because I don't have the power, resources, or time to do alone. But as an example of something for COPR that I'd been working on is an autorebuilder service that is dependency-aware[1]. Basically, when the repositories configured for your COPR project update, it would trigger rebuilds of your packages in the correct order. This is very similar to the build scheduler present in the Open Build Service. It wouldn't require anything more than you to configure the rebuilder service on which projects and packages to watch, and an API key for COPR. Ideally, such a thing would be integrated into COPR itself and done with a bit more finesse, but I wanted to build this out to support my own use-case: rebuilding kmod packages automatically when new kernels became available. But the idea would be trivial to extend to anything. I hadn't gotten the initial code working yet, so there's only a skeleton pushed, but it's something I have been hacking on periodically. [1]: https://pagure.io/copr-autorebuilder > It can be frustrating to not get that critical mass needed to move an > idea forward. I'm in a similar boat with many (minor) things in > Fedora right now. I can empathize with you on that front. > > > I still believe that Modularity, as designed, is a mistake. But if I > > don't have a way to prove a better way to do things, there's no way > > anything will improve. The folks running the show like what they have > > now, so it'll take a lot to trigger change. > > Here is my issue with many of the ideas/proposals I've seen lately in > Fedora. Someone describes a problem (good!), they come up with a plan > (ok!), that plan immediately requires a significant investment in > resources and time of *other people*. There is no evolution from > existing tools, there is no small prototype they've done on the side > to prove things out or tackle some of the issues. There's no evidence > the idea is even going to pay off at all. It's an immediate "here's > my idea!" with a hand out to get started. > That has *never* been the way I roll with things. It doesn't take much to see that I'm fairly involved in a wide variety of projects. However, an important litmus for me is that the people in control of the project have to be receptive and willing to work with me. I do not have the mental bandwidth or time to sometimes carry out an idea to its full conclusion. I can build small-scale things to prove out the concept, and maybe help with scaling the idea up. But this is not my job, this is my passion I work on in nights and weekends. If I do it alone, it'll take a long time to get there. I *know* I need help, and I'm happy to accept it. Perversely, it also means if there's a fundamental disagreement that can't be worked past, I probably am more likely to quit rather than fork the project and keep going with it. I just simply don't have the ability to drive something alone. > Fedora is a project, not a venture capital firm. Things get done > because people do them, prove they work, get buy-in, and evolve over > time. If that means ideas or projects start small and outside > existing Fedora infrastructure, that's OK! > > For the record, I think Modularity started much the same way. > "Everything will be a module!" without proving any of it out in a > small scale hurt the adoption and messaging around why it's useful. > When it was reset and rescoped, it started making more progress and > continues to gain steam. I am not blind to the fact that Modularity > did not suffer from lack of investment, but it should serve to > illustrate that even if you have a corporate backer your plan or idea > still might not succeed at first and will need to evolve over time. > The problem with Modularity today is that it's still working from several biases that will hurt the overall Fedora ecosystem. It assumes people don't want to do local builds of packages reliably. It assumes that everyone has a Koji with an MBS scheduler. It assumes that Mock is used build-side and DNF is used for runtime. It assumes you never use PackageKit. It does not even account for ecosystem assumptions about repository metadata, which is extremely painful for me personally. Many of the improvements in MBS should not be module-exclusive. They should be part of Koji and usable by regular packages too. But there's no opportunity because the Koji team is incredibly unresponsive. To the point that even basic, trivial patches go without response for months. And doing PR reviews for them doesn't seem to help either. I'm incredibly frustrated and dismayed because it's Fedora's (and maybe even Red Hat's) own fault that our tooling is in such poor shape. To me, it seems like we don't actually want to be better. I haven't given up yet because I care very deeply about Fedora as a whole. The Project, the distribution, and the people. I want us to be the best we can be. I just don't know what to do anymore... -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
