Is there a policy for branches being merged or not

[Julian Sikorski]

Hello,

is there a general recommendation regarding keeping git release branches 
separate vs merged? I have been keeping mine separate. Originally to 
avoid release and changelog conflicts when cherry-picking, but I got 
used to it and kept doing it after converting to %autorelase and 
%autochangelog.
Recently one of my packages got it branches merged by a provenpackager 
doing a deps rebuild. If there is no policy to merge, this is 
disappointing as force-pushes as not allowed and branches once merged 
cannot be unmerged. I know this is just a cosmetic issue, but choices 
made by the primary maintainers should be respected IMO.

Best regards,
Julian

[Peter Robinson]

On Sun, 28 Apr 2024, 09:28 Julian Sikorski, <belegdol(a)gmail.com&gt; wrote:

>  Hello,
>
>  is there a general recommendation regarding keeping git release branches
>  separate vs merged? I have been keeping mine separate. Originally to
>  avoid release and changelog conflicts when cherry-picking, but I got
>  used to it and kept doing it after converting to %autorelase and
>  %autochangelog.
>  Recently one of my packages got it branches merged by a provenpackager
>  doing a deps rebuild. If there is no policy to merge, this is
>  disappointing as force-pushes as not allowed and branches once merged
>  cannot be unmerged. I know this is just a cosmetic issue, but choices
>  made by the primary maintainers should be respected IMO.
>  
It's up to the maintainers, but it's also hard to determine what the
maintainer's intentions are for those sorts of things, especially if you're
scripting a rebuild across 100s of packages for a bump.

As both a maintainer and a proven packagers I tend to just assume the
person has the best intentions of the project in mind.

Best regards,
>  Julian
>  --
>  _______________________________________________
>  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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Julian Sikorski]

Am 28.04.24 um 10:36 schrieb Peter Robinson:
>  
>  
>  On Sun, 28 Apr 2024, 09:28 Julian Sikorski, <belegdol(a)gmail.com 
>  <mailto:[e-mail]>> wrote:
>  
>      Hello,
>  
>      is there a general recommendation regarding keeping git release
>      branches
>      separate vs merged? I have been keeping mine separate. Originally to
>      avoid release and changelog conflicts when cherry-picking, but I got
>      used to it and kept doing it after converting to %autorelase and
>      %autochangelog.
>      Recently one of my packages got it branches merged by a provenpackager
>      doing a deps rebuild. If there is no policy to merge, this is
>      disappointing as force-pushes as not allowed and branches once merged
>      cannot be unmerged. I know this is just a cosmetic issue, but choices
>      made by the primary maintainers should be respected IMO.
>  
>  
>  It's up to the maintainers, but it's also hard to determine what the 
>  maintainer's intentions are for those sorts of things, especially if 
>  you're scripting a rebuild across 100s of packages for a bump.
>  
>  As both a maintainer and a proven packagers I tend to just assume the 
>  person has the best intentions of the project in mind.
>   
In this case defaulting to cherry-picking would be a safer bet. Branches 
unintentionally separated can be merged, but branches unintentionally 
merged cannot be unmerged.

Best regards,
Julian

[Kevin Kofler]

Julian Sikorski wrote:
>  In this case defaulting to cherry-picking would be a safer bet.
> Branches
>  unintentionally separated can be merged, but branches unintentionally
>  merged cannot be unmerged. 
This is only true if you are talking about merge-commit merges. Not if we 
are keeping the branches fast-forwarded (and using %{?fedora} conditionals 
in the rare event something really needs to differ between the releases). A 
linear history cannot be remade truly linear once it was diverged by a 
cherry-pick (or simply a separate bump from running rpmdev-bumpspec 
separately on each branch, as scripted rebuilds often do). The best we can 
do to restore fast-forwardability is to merge one way and then "merge back", 
which will fast-forward the other branch to the same merge commit. This 
still leaves an ugly knot in the history, but at least the branches can then 
be fast-forwarded again. But a clean linear history is no longer possible 
after someone did an unwanted cherry pick instead of a fast-forward merge.

        Kevin Kofler

[Julian Sikorski]

Am 28.04.24 um 23:44 schrieb Kevin Kofler via devel:
>  Julian Sikorski wrote:
> > In this case defaulting to cherry-picking would be a safer bet. Branches
> > unintentionally separated can be merged, but branches unintentionally
> > merged cannot be unmerged.
>  
>  This is only true if you are talking about merge-commit merges. Not if we
>  are keeping the branches fast-forwarded (and using %{?fedora} conditionals
>  in the rare event something really needs to differ between the releases). A
>  linear history cannot be remade truly linear once it was diverged by a
>  cherry-pick (or simply a separate bump from running rpmdev-bumpspec
>  separately on each branch, as scripted rebuilds often do). The best we can
>  do to restore fast-forwardability is to merge one way and then "merge back",
>  which will fast-forward the other branch to the same merge commit. This
>  still leaves an ugly knot in the history, but at least the branches can then
>  be fast-forwarded again. But a clean linear history is no longer possible
>  after someone did an unwanted cherry pick instead of a fast-forward merge.
>  
>           Kevin Kofler 
Fair enough. Summing up, mass rebuilds are going to mess up whatever the 
maintainer chose to do if the rebuilder decides to use the other approach.

Best regards,
Julian

[Richard W.M. Jones]

On Sun, Apr 28, 2024 at 10:27:26AM +0200, Julian Sikorski wrote:
>  Hello,
>  
>  is there a general recommendation regarding keeping git release
>  branches separate vs merged? I have been keeping mine separate.
>  Originally to avoid release and changelog conflicts when
>  cherry-picking, but I got used to it and kept doing it after
>  converting to %autorelase and %autochangelog. 
I actually don't think this really matters much, but I try to keep
branches merged, until they require cherry picking for a specific
reason.

As a concrete example:

https://src.fedoraproject.org/rpms/nbdkit/commits/rawhide
https://src.fedoraproject.org/rpms/nbdkit/commits/f40

These two branches were merged until a couple of months ago when
rawhide required the bash-completion-devel package (which is not in
F40), and then I switched to cherry picking.  Later still we switched
F40 to a different upstream branch so now they're completely separate.

>  Recently one of my packages got it branches merged by a
>  provenpackager doing a deps rebuild. If there is no policy to merge,
>  this is disappointing as force-pushes as not allowed and branches
>  once merged cannot be unmerged. 
If this last bit true?

>  I know this is just a cosmetic issue, but choices made by the
>  primary maintainers should be respected IMO. 
I agree in general, but sometimes if you're making mechanical changes
across 100s of packages it's hard to do this in practice.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[Gary Buhrmaster]

On Mon, Apr 29, 2024 at 11:35 AM Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  On Sun, Apr 28, 2024 at 10:27:26AM +0200, Julian Sikorski wrote:
>
>  > I know this is just a cosmetic issue, but choices made by the
>  > primary maintainers should be respected IMO.
>
>  I agree in general, but sometimes if you're making mechanical changes
>  across 100s of packages it's hard to do this in practice. 
I make sure to read the (bulk) change proposals
and if I care about how they may impact my
packages I will try to perform the changes in
advance (so any mechanical changes find
nothing to do).  Choosing to let the automation
do whatever it is going to do is still a choice.
I attempt to choose wisely.