Dne 03. 04. 20 v 10:46 Vít Ondruch napsal(a): > > > Dne 02. 04. 20 v 21:38 Kalev Lember napsal(a): >> On Thu, Apr 2, 2020 at 9:10 PM Stephen Gallagher <sgall...@redhat.com >> <mailto:sgall...@redhat.com>> 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
