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. > 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? > 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. 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. 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. josh _______________________________________________ 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
