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 <sgallagh(a)redhat.com
> <mailto:sgallagh@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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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