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 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". 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. 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. -- 真実はいつも一つ！/ 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
