From: Bruno Haible <bruno@clisp.org>
To: bug-gnulib@gnu.org, Paul Eggert <eggert@cs.ucla.edu>
Subject: Re: transition periods
Date: Sun, 22 Jan 2023 11:04:33 +0100 [thread overview]
Message-ID: <2132971.NOsbNO2B7e@nimes> (raw)
In-Reply-To: <02345fc5-de5e-31cf-549f-b573175216f2@cs.ucla.edu>
Paul Eggert wrote:
> if I see the warning I do the same thing that I
> do if I see the error from the missing #include, so there's not much
> point in having a transition period with the warning.
I see a value for the transition period in three cases:
1)
> Things can be different the transition involves other ports or rarely
> used platforms. But this one involves all GNU/Linux platforms so I see
> the #warning right away.
The package might use the getprogname module only on specific platforms.
Thus, even though our change in Gnulib affected all platforms, in the
specific package it may not be visible immediately.
2) The maintainer may have a fixed release date scheduled. He then
wants to upgrade to a newer Gnulib, to fix some issue, but without
getting dragged into other changes.
3) The package may have a master branch and a release branch. The maintainer
uses "diff -r" to compare the code in the two branches. The two branches
may use different versions of Gnulib (via git submodules). Extra changes
between the two branches are unwelcome, even small ones. Thus the maintainer
will not want to remove '#include "getprogname.h"' statements as long as
his release branch is active; this can be several months.
These are just the scenarios that come out of my experience as maintainer /
release manager. I'm sure distro packagers have their habits, and some of
them will also favour longer transition periods.
Bruno
prev parent reply other threads:[~2023-01-22 10:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-21 8:56 getprogname: Move declaration from "getprogname.h" to <stdlib.h> Bruno Haible
2023-01-21 21:19 ` Paul Eggert
2023-01-22 0:10 ` Bruno Haible
2023-01-22 4:57 ` Paul Eggert
2023-01-22 10:04 ` Bruno Haible [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2132971.NOsbNO2B7e@nimes \
--to=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=eggert@cs.ucla.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).