Dne 02. 04. 20 v 21:38 Kalev Lember napsal(a):
On Thu, Apr 2, 2020 at 9:10 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
And having to manually perform a sync between those packages for every
update is somehow less work
There are two things:
1) Of course I don't expect I'll do it manually, but if I have to, then it is still better then having branches.
Ups, this should have been:
Of course I don't expect I'll do it manually, but if I have to, then it is still better than having conditionals.
Vít
2) I see this as a `git rebase` where this works automatically.
You can call me naive ... but I can tell you that his works. However of course it depends on your strategy. If the work of common package looks like, e.g.:
My package is FTBFS due to several issues, so fixing this, I'll also do rebase. Later when finished, everything is one commit, then this might be problematic. But if there are several commits, e.g. a) fix first reason for FTBFS b) update the spec file to conform to the latest and greatest packaging standard c) rebase the package, the story is different.
And actually this is what we do. E.g. there is some security issue, I think twice how it should be fixed in Fedora so I can easily reuse the same patch in RHEL/RHSCL. And believe me, the simple patches such as security fix applies just fine from plain Fedora spec into SCL conventionalized spec.
I do this while preparing new Ruby release for a Rawhide in a branch, structuring commits so I can reuse them in Rawhide immediately.
Frankly, I expect that without branch, which will give you safe place, the ELN will be constantly broken and completely unusable.
than *checks notes* adding some
conditionals once and then letting it get pulled from the master
branch thereafter? I don't understand your logic here, I'm sorry.
For what it's worth, I agree with Stephen that conditionals are easier to maintain when we need to keep them working across rebases. I'd much prefer keeping a RHEL conditional in git master than having to manually go through each and every RHEL package after branching and adding back downstream changes.
This is continuous process. There is no branch point. That is the difference. You would need to keep the ELN branch up2date. IOW there won't be one time heroic to add some conditionals. That would be small continuous effort, keeping and eye when something is broken. But in this case, it is either fixing broken conditional, rebuilding Fedora packages, shipping them to users and then finally building also ELN package, while the branch would allow to not touch the Fedora package at all and fix just the broken conditional for ELN.
In my opinion, this doesn't scale at all -- it may work for people who maintain a small amount of packages and can keep track of what changes need to be made in RHEL, but not if someone is maintaining a large number of packages. (I am a package monkey for the GNOME stack with hundreds of packages, both in upstream Fedora and downstream RHEL) .
So how you envision this will work for Gnome? I am genuinely interested? You are doing the release not so often. It is typically big bang and update of everything. So you won't ship anything into Rawhide unless the ELN conditionals are correct (how you would ensure that)? Or you ship everything in Rawhide, then you start fixing the conditionals and ship again essentially the same content to Rawhide users after that? Both of the scenarios are big fail for Rawhide.
Or maybe you have different idea.
Speaking of updates of Ruby, my vision for Rawhide is to do everything as we did, e.g. keep maintaining development version of Ruby spec file in a branch, later merge into Rawhide and do mass rebuild in a side tag, merge it back (without any ELN conditionals). Then ELN will try to rebase everything (or if there are git symbolic-ref, there would not be needed anything), letting me know that I screwed something. I (or some ELN folks) will take a look, update the packages where the rebase failed, possibly adjusting the packages in a Rawhide.
Also writing this, I have realized, that there is one problem with the side tag and that is the commits into master branch. So although Rawhide keeps running just fine, ELN might be broken during this time. Depends what will actually drive the ELN rebuilds.
Vít
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
