Re: Is there a policy for branches being merged or not

2024-04-30 Thread 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
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a policy for branches being merged or not

2024-04-29 Thread Gary Buhrmaster 
On Mon, Apr 29, 2024 at 11:35 AM Richard W.M. Jones  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.
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a policy for branches being merged or not

2024-04-29 Thread 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
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a policy for branches being merged or not

2024-04-28 Thread 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
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a policy for branches being merged or not

2024-04-28 Thread Julian Sikorski 

Am 28.04.24 um 10:36 schrieb Peter Robinson:



On Sun, 28 Apr 2024, 09:28 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.
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
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a policy for branches being merged or not

2024-04-28 Thread Peter Robinson 
On Sun, 28 Apr 2024, 09:28 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.
> 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@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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Is there a policy for branches being merged or not

2024-04-28 Thread 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
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue