Re: [x264/f30: 7/7] Merge branch 'f29' into f30
On Fri, Oct 4, 2019 at 8:00 PM Kevin Kofler wrote: > FeRD wrote: > > If you were developing a bugfix or a new feature to submit to an upstream > > project, would you develop against the code from three releases ago, > > submit it as a patch or PR against that code, and tell them to merge it > > forward to their current development tree? Of course not, and no project > > would accept such a patch. > > This is not true. Qt and parts of KDE actually work that way: Bug fixes > that > should go into the release branches should be targeted at the oldest > supported release branch and will be merged to the newer releases by > upstream. Features should typically go only into dev (Qt) or master (KDE) > and so should be targeted against that branch. > True enough, and I stand corrected. Qt's branching and maintenance strategy[1] is apparently far more complex than I've encountered in the past. The primary difference seems to be that Qt maintains a LTS release (currently Qt 5.6), so they have to worry about fixing bugs in feature-frozen 3-year-old code. That's not an issue for Fedora's package maintenance strategy. [1]: https://wiki.qt.io/Branch_Guidelines ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [unifi] Change requirement from policycoreutils-python to policycoreutils-python-utils so Python 3 is used
On Fri, Oct 4, 2019 at 11:49 PM Kevin Kofler wrote: > I think mongodb should be packageable in RPM Fusion nonfree. Not taking sides, but Björn 'besser82' Esser said that it (probably cannot be packaged in RPMFusion for the unifi controller in a previous discussion. https://lists.rpmfusion.org/archives/list/rpmfusion-developers@lists.rpmfusion.org/message/BPKDVFJENHUFC4RQMRNZVN6U4AFEXXAU/ ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [x264/f30: 7/7] Merge branch 'f29' into f30
I am NOT arguing that merging from older to newer branches makes sense in a dist-git context (in fact, I'd argue that it does not, because changes should be built for Rawhide first and dist-git requires them to be pushed to master to be built for Rawhide), but: FeRD wrote: > If you were developing a bugfix or a new feature to submit to an upstream > project, would you develop against the code from three releases ago, > submit it as a patch or PR against that code, and tell them to merge it > forward to their current development tree? Of course not, and no project > would accept such a patch. This is not true. Qt and parts of KDE actually work that way: Bug fixes that should go into the release branches should be targeted at the oldest supported release branch and will be merged to the newer releases by upstream. Features should typically go only into dev (Qt) or master (KDE) and so should be targeted against that branch. Kevin Kofle ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [unifi] Change requirement from policycoreutils-python to policycoreutils-python-utils so Python 3 is used
Gary Buhrmaster wrote: > IRT mongod, see the discussion in > https://bugzilla.rpmfusion.org/show_bug.cgi?id=5252 > which would appear to leave Richard between a rock > and a hard place as mongoDB is no longer packageable > by Fedora/EL due to the license changes. > > Not including a Requires: that forces one to install > the mongoDB upstream package will result in a > RPMFusion package that is no longer complete > (and usable) either causing different confusion > (bugzilla's about "it does not start!" seem likely). > > I would guess if a Requires is not allowed it would > be better to not include unifi at all to minimize the > confusion? I think mongodb should be packageable in RPM Fusion nonfree. It is under a non-Free license (which is why Fedora does not accept it and also why it does not belong in the free section), but it is redistributable. A Requires on an external package is not acceptable. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [x264/f30: 7/7] Merge branch 'f29' into f30
I work from master and merge downwards, so get used to it! ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Build notifications are disabled from koji
Hi there, Because the build notification feature seems broken already with current koji, I've fully disabled it. This will prevent lot of failing notification tasks from the koji-hub (and hopefully reducing the admin stress on this topic). There are still some random issue with build failing from alternate arch builders. The issue has been reduced to the VPN link, but root cause is still investigated. -- - Nicolas (kwizart) ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [x264/f30: 7/7] Merge branch 'f29' into f30
On Fri, Oct 4, 2019 at 4:47 AM Nicolas Chauvet wrote: > > NO, please re-evaluate, I'm not going to read further nor to discuss > it yet again. > I will! On Fri, Oct 4, 2019 at 4:34 AM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > > Cherry-picking only makes sense when the branches are too diverged. I > did cherry-pick from f29 to el7 for that reason. The others are more or > less the same. All the fixes that went into all branches should have > been applied to the oldest applicable branch first and then merged > upwards. This wasn't done, hence the current merge commits look uglier > than they could be. They will be much cleaner in the future if this > workflow is followed. > > Christopher over at fedora devel list has some valid points in favour of > this way[1]: > They're *not*, though. Points in favor of this bass-ackwards "oldest branch first" merge idea, I mean. They *are* good points, and merges are generally better than cherry-picking, I agree. But people who argue for this "start at the oldest branch" merge plan are misunderstanding... not *git* itself, exactly... but the realities of release-management in git. And they are guaranteeing themselves merge conflicts by doing it that way. > Git has excellent branch merging features. Merging branches, rather than > cherry-picking across them, results in commits representing the same > changeset being present in multiple branches, making it easier to search > git history and identify which branches contain a specific change. > Agreed on all points, *there*. And if you go in the correct direction, merges are very clean, typically fast-forwards that require no commits at all. Going in the *wrong* direction, you can't help but end up in merge conflict hell. If you were developing a bugfix or a new feature to submit to an upstream project, would you develop against the code from three releases ago, submit it as a patch or PR against that code, and tell them to merge it forward to their current development tree? Of course not, and no project would accept such a patch. Even where bugfixes are going to be made in older releases, they're developed in the newest code first, and then _backported_ as far as they deem necessary for that particular change. (And that's the first important point: Different changes in the master codebase will have a different level of "penetration" into the past branches, so every past branch will *necessarily* have an incomplete picture of any branch forward of it. But generally speaking, *all* of those changes will be on the master branch in one form or another. The entire concept of backporting is predicated on that truth. Release branches in package repos work the same way. Newer branches will receive changes that *aren't* necessarily pushed all the way back into their past each time. 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. 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. 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. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to r
Re: [x264/f30: 7/7] Merge branch 'f29' into f30
Le ven. 4 oct. 2019 à 10:34, Dominik 'Rathann' Mierzejewski a écrit : > > On Friday, 04 October 2019 at 10:23, Nicolas Chauvet wrote: > > Please consider to use cherry-pick next time. > > I don't see the point to compute a merge resolution for the changelog > > because of a single fix. > > This is craziness. > > Cherry-picking only makes sense when the branches are too diverged. I NO, please re-evaluate, I'm not going to read further nor to discuss it yet again. -- - Nicolas (kwizart) ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [x264/f30: 7/7] Merge branch 'f29' into f30
On Friday, 04 October 2019 at 10:23, Nicolas Chauvet wrote: > Please consider to use cherry-pick next time. > I don't see the point to compute a merge resolution for the changelog > because of a single fix. > This is craziness. Cherry-picking only makes sense when the branches are too diverged. I did cherry-pick from f29 to el7 for that reason. The others are more or less the same. All the fixes that went into all branches should have been applied to the oldest applicable branch first and then merged upwards. This wasn't done, hence the current merge commits look uglier than they could be. They will be much cleaner in the future if this workflow is followed. Christopher over at fedora devel list has some valid points in favour of this way[1]: Git has excellent branch merging features. Merging branches, rather than cherry-picking across them, results in commits representing the same changeset being present in multiple branches, making it easier to search git history and identify which branches contain a specific change. Regards, Dominik [1] https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/RQBIXNOQXRYMWNXSA3EBJJWVZNDCEQCG/ -- 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
