NTPsec 1.2.2a released

[Fred Wright]

On Fri, 4 Aug 2023, James Browning via devel wrote:
>> On 08/04/2023 6:35 PM PDT Fred Wright via devel <devel at ntpsec.org> wrote:
>>
> :::snip:::
>>
>> I notice that the two commits for that don't seem to be in any branch.
>> Having commits only "owned" by a tag and not a branch seems fragile.
>
> I do not think it is particularly fragile; I mean the garbage
> collector is that aggressive, is it?

It's not just about the garbage collector.  Git's general philosophy is 
that non-transient commits are exepected to exist on at least one branch, 
and some of the tools for moving commits around are branch-oriented.  It 
happens that "git fetch" manages to pick up this commit via the tag, but 
in general, expecting branchless commits to be handled fully correctly is 
pushing one's luck.

>> In the process of investigating this, I noticed that only the master
>> branch is visible in the WebGUI, even though there are actually 25
>> branches in the repo.
>
> I also only see the branch master. Then again I am not expecting to
> see 26 branches because we have 25 tags and master. BTW master at one
> point or another contained all of those tags.

This is about branches, not tags.  The number was 25 including master, but 
24 of those were leftovers in my local repo, due to not having done a 
prune.  So master-only is actually correct at the moment.

>> Having a separate branch for each patch release could get somewhat
>> cluttered, but it's straightfoward to use a single branch for all patch
>> releases, as long as folks aren't allergic to merge commits.
>
> If it bothers you, I could add a merge request to add a 1.2.2 branch.

As I mentioned, a branch for each patch release doesn't scale well, though 
it's probably better than nothing.  Using a release branch in general 
would have additional benefits besides handling the patch release case 
reasonably.

On Mon, 7 Aug 2023, Richard Laager via devel wrote:

> On 2023-08-04 20:35, Fred Wright via devel wrote:
>> I notice that the two commits for that don't seem to be in any branch. 
>> Having commits only "owned" by a tag and not a branch seems fragile.
>
> I think it's fine for a backport fix release like this.

See above.

> That said, I did advocate for merging it back in to master (as a no-op). But 
> I don't feel particularly strongly about that.

Attempting to merge it into master now would just result in a conflict 
that would have to be resolved by turning it into an empty commit (and 
giving git explicit permission to do that).

The real problem at that level is that the patch wasn't originally created 
via "git cherry-pick", which is because the original master commit 
combined multiple changes into one commit.  This is one example of why 
that should be avoided.

Fred Wright