* Neal Gompa: > Sure, fork traps and such do still happen, but they're a lot rarer > because that is much more painful with our current packaging model.
It's relatively painless once you write some scripts. Some teams serialize some Git history to a long list of patches, some teams work with non-pristine tarballs. There's no endorsed default solution, so everyone builds their own thing. > It's a lot more obvious that package is in bad shape when it has ~100+ > patches and is hard to rebase than it is when you have Git trees and > can just do merges all the time. Once you've done merges, it becomes > impossible to sort out. It depends on the documentation you have, and you can cover *a lot* with tooling. With Git history, there's a chance that the tooling can eventually become generic and the de facto default. See git range-diff for a first tep in this area (although I have yet to use it). >> > Fundamentally, I don't want having patches to be too easy, because >> > then people _will_ do that. Fedora should strive to remain close to >> > upstream projects and interact with them to make things better[1]. >> >> To be honest, that's an awful attitude. >> >> Do you want me to spend time on packaging work instead of glibc >> maintenance? Do you really think that's a good use of my time? >> > > I think that if you're maintaining large patch sets that you might > want to consider talking to upstream about doing more releases. I don't think we want to update the platform ABI within a Fedora release, or introduce substantial header file changes, adding new warnings or just new declarations. > If glibc has so many problems that this becomes an issue even with the > short life cycle in Fedora, then maybe upstream needs to reconsider > its release model a bit and do more frequent releases per version > series. Actually, does it even do that now? I'm not actually sure... We have actually discussed it. There's hardly any point because anyone can create fairly reproducible tarballs off the release branches. And that's exactly what we are doing, so that we don't have manage all those patches individual. Most fixes relevant to Fedora (even bugs reported here first) come into Fedora through those tarball updates. Of course it makes things complicated when you actually want to browse the difference in terms of patches between two different Fedora builds, but you cannot have everything. >> Do you really think an unavoidable conflict each time you merge parallel >> development into a source RPM provides value? (You didn't answer this question.) > As a consequence, the C.UTF-8 locale is probably what I would consider > one of our biggest failures. It's present in Fedora, openSUSE, Debian, > and now Mageia. Carification: *Some* C.UTF-8 locale. I very much doubt it's the same everywhere. >> That's just a matter of tooling. A lot of information can be recovered >> from Git history, and it's going to be easier to do this in a single >> repository than with copied patches, without tooling that enforces that >> the patches actually contain what they say. > > It's a lot clearer that patch files applied to a tarball are > distinctly packager things vs a cacophony of changes from upstream and > downstream mixed together. But that's exactly what we have with patch files today. Thanks, Florian _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
