Re: 2-year old change not pulled into 9.2

[Matthias Petermann]

Hello Jan,

On 22.09.21 03:05, Jan Schaumann wrote:

Hello,

Back in 2019, I reported a bug in cp(1):
https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=54564

This was promptly fixed in src/bin/cp/utils.c rev 1.47
on 2019-09-23, but it looks like this change is not
included in cp(1) in NetBSD 9.2:

$ ident `which cp` | grep utils.c
/bin/cp:
      $NetBSD: utils.c,v 1.46 2018/07/17 13:04:58 darcy Exp $
$ uname -a
NetBSD apue 9.2 NetBSD 9.2 (GENERIC) #0: Wed May 12 13:15:55 UTC 2021
mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
$

I see that the last revision to be tagged
netbsd-9-2-RELEASE was 1.46.  But 9.2 was released on
2021-05-12 -- wouldn't it be reasonable to expect that
release to include changes a bit more recent than from
1.5 years prior?  How come later versions were not
tagged for this release?

-Jan

    https://www.netbsd.org/releases/release-map.html#graph1



    https://www.netbsd.org/developers/releng/pullups.html



    http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=52630



Kind regards
Matthias

your question reminds me of a similar one I had a few years ago. With the exception that there are currently no "teeny" releases, I find the presentation in the Release Glossary helpful: In your case, the release branch "netbsd-9" was probably already created when your patch was merged into current. This means that a transfer to the release branch requires a pull-up request: I am not a NetBSD developer, but I understood that there is no automatism for this, but the pull-up-request is made by the respective NetBSD developer, who puts the patch into current. Whether a pull-up request is made is decided on a risk/benefit basis. The developer may not always be able to decide this immediately. It might help to include the risk/benefit assessment when submitting the patch, opening the discussion to the potential pull-up-request. For a minor issue, I have also asked a PR for a pull-up request when I saw that it was already fixed in current - kind of in the similar situation as you: That had worked well back then and it would be worth a try to aim for that for 9.3.

smime.p7s
Description: S/MIME Cryptographic Signature