Hi! On Friday, 04 October 2019 at 12:37, FeRD wrote: > On Fri, Oct 4, 2019 at 4:47 AM Nicolas Chauvet <kwiz...@gmail.com> wrote: > > > NO, please re-evaluate, I'm not going to read further nor to discuss > > it yet again. > > I will!
Thanks. > On Fri, Oct 4, 2019 at 4:34 AM Dominik 'Rathann' Mierzejewski < > domi...@greysector.net> wrote: [...] > Release branches in package repos work the same way. I disagree. > Newer branches will receive changes that *aren't* necessarily pushed > all the way back into their past each time. True. > But when a change comes along that *does* need to be pushed back > farther, those newer changes should be brought along *at that time*, > in order to keep their shared history coherent. I disagree. I don't think it makes sense to backport all commits from master to older branches whenever I want to backport just one particular commit. Cherry-picking will do that at the expense of different commit hash corresponding to the same change in different branches. I test my changes on all branches and I think merging upwards makes perfect sense because I don't want all changes from master landing in f29 package (for example, dropping python2 subpackage). > Here's a concrete (though hypothetical) example: > > 1. Say there's a package xyz that exists in F29, F30, F31, and > rawhide. > > 2. It's currently packaged with the NVR xyz-1.2.3-1 for all of > those releases. > > 3. xyz has a dependency on libfoo, which gets upgraded in rawhide > and F31, but no earlier because it's an API-breaking change > > 4. xyz has to be rebuilt for the new libfoo, so new builds > xyz-1.2.3-2 are done on the master and f31 branches (again, *only*) > > 5. Now you have a bugfix you need to apply to xyz on all branches > back to f29 > > 1. If you develop that bugfix on the master branch, as xyz-1.2.3-3, > then you can merge master back to f31, f30, and f29 cleanly, as > a fast-forward merge. I do it all the time. No cherry-picking, > no merge commits. Just fast-forwards. They will all end up at > xyz-1.2.3-3. F29 and F30 will have skipped over xyz-1.2.3-2, > which is perfectly fine. But their histories will now also > receive the commits for the libfoo rebuild that, *until that > point*, they didn't need to have. It's not fine. Older branches will get a completely confusing changelog entry saying they were rebuilt for a change in a dependency that never happened there. If there were other changes on master (like the dropping of python2 subpackage, for example), it would get merged to the older branches, too, which would be completely wrong. > 2. OTOH, if you try to develop your bugfix on f29 first and merge it > forward, there is *NO WAY* to avoid merge commits — if not > outright merge conflicts — when merging that forward into the > newer branches. At *BEST* you'll have been careful enough to > manually jump over release number 2 and go straight to 3, which > may let you avoid any actual *conflicts*, but you'll still have > to perform a merge commit to reconcile your changes into the f31 > and master branches. Whereas all of that could have been > avoided, and you wouldn't have to worry about being careful and > checking all of the branches' release numbers, if the bugfix had > started from the other end of the branch chain. I don't understand why you're so afraid of merge commits. I have no problem dealing with them or merge conflicts, if that's what it takes to be able to choose which fixes get applied to which branches and still see them as the same commit hash everywhere. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan _______________________________________________ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
