git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Ramsay Jones <ramsay@ramsayjones.plus.com>, git@vger.kernel.org
Subject: Re: [PATCH] ci: do not die on deprecated-declarations warning
Date: Sun, 15 Jan 2023 15:08:26 -0500	[thread overview]
Message-ID: <Y8RdOt02JTvDnLiX@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqq4jssi8qh.fsf@gitster.g>

On Sat, Jan 14, 2023 at 10:59:18PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > On the other hand, I don't know how useful those deprecations are going
> > to be, as it depends on the timeframe. If the deprecation is added for
> > the same version of libcurl that implements the alternative (which is
> > roughly the case here), then we'd always be stuck supporting the old and
> > new forms (old for backwards compatibility, and new to silence the
> > deprecation warning).
> 
> ... or just keep the warning without promoting, with "-Wno-error=...".

I'm pretty strongly against that solution for anything long-term. Having
to see those warnings is not only ugly, but it's confusing and trains
people to ignore them (and many times I've noticed ugly warnings
floating by and realized that oops, I had temporarily disabled -Werror
because I had been working with some older code).

> > We care a lot more about the deprecation once the
> > alternative has been around for a while, and/or the old way of doing
> > things is about to be removed. And if we just wait until that removal,
> > then we do not have to rely on deprecation warnings. The build will
> > break just fine on its own. :)
> 
> Yes and no.  It is not always like "this symbol is now known under
> this different name", which is trivial to adjust.  I briefly tried
> to see how IOCTL -> SEEK change should look like until I realized
> that the new way was invented too recently and stopped looking, but
> it would involve changes to the function logic in the callback
> functions, as the function signature---both parameters and its
> return values---of the callback changes.  I do not want to see us
> scrambling to make such adjustments to the code at the last minute,
> so some sort of advance warning is a good thing to have.

True.

I do think the IOCTL/SEEK one is old enough that we can do, though. The
deprecation is newer, but the SEEK interface was added in an old enough
version.

-Peff

  reply	other threads:[~2023-01-15 20:10 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-14  3:47 [PATCH] ci: do not die on deprecated-declarations warning Junio C Hamano
2023-01-14 14:29 ` Ramsay Jones
2023-01-14 15:14   ` Ramsay Jones
2023-01-14 16:13   ` Junio C Hamano
2023-01-14 14:47 ` Jeff King
2023-01-14 14:57   ` Jeff King
2023-01-14 16:15   ` Junio C Hamano
2023-01-14 17:15     ` Jeff King
2023-01-15  6:59       ` Junio C Hamano
2023-01-15 20:08         ` Jeff King [this message]
2023-01-15 21:38           ` Junio C Hamano
2023-01-14 16:55   ` Junio C Hamano
2023-01-15  7:02     ` Junio C Hamano
2023-01-15 20:09       ` Jeff King
2023-01-15 20:10         ` [PATCH 1/3] http-push: prefer CURLOPT_UPLOAD to CURLOPT_PUT Jeff King
2023-01-15 20:54           ` Ramsay Jones
2023-01-15 23:13             ` Jeff King
2023-01-15 23:49               ` Jeff King
2023-01-15 20:10         ` [PATCH 2/3] http: prefer CURLOPT_SEEKFUNCTION to CURLOPT_IOCTLFUNCTION Jeff King
2023-01-15 21:11           ` Ramsay Jones
2023-01-15 21:45           ` Junio C Hamano
2023-01-15 23:17             ` Jeff King
2023-01-15 20:12         ` [PATCH 3/3] http: support CURLOPT_PROTOCOLS_STR Jeff King
2023-01-15 21:37           ` Ramsay Jones
2023-01-15 23:22             ` Jeff King
2023-01-16 13:06           ` Ævar Arnfjörð Bjarmason
2023-01-16 16:05             ` Junio C Hamano
2023-01-16 16:26               ` Junio C Hamano
2023-01-16 17:23               ` Jeff King
2023-01-16 17:27             ` Jeff King
2023-01-17  3:03         ` [PATCH v2] avoiding deprecated curl options Jeff King
2023-01-17  3:04           ` [PATCH v2 1/3] http-push: prefer CURLOPT_UPLOAD to CURLOPT_PUT Jeff King
2023-01-17  3:04           ` [PATCH v2 2/3] http: prefer CURLOPT_SEEKFUNCTION to CURLOPT_IOCTLFUNCTION Jeff King
2023-01-17  3:04           ` [PATCH v2 3/3] http: support CURLOPT_PROTOCOLS_STR Jeff King
2023-01-18  1:03           ` [PATCH v2] avoiding deprecated curl options Ramsay Jones
2023-01-14 14:56 ` [PATCH] ci: do not die on deprecated-declarations warning Jeff King
2023-01-16  0:39   ` Ramsay Jones
2023-01-16 17:13     ` Jeff King
2023-01-14 17:13 ` [PATCH v2] " Junio C Hamano
2023-01-14 17:17   ` Jeff King
2023-01-17  3:03     ` [PATCH 1/3] http-push: prefer CURLOPT_UPLOAD to CURLOPT_PUT Jeff King
2023-01-17  3:04       ` Jeff King

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: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y8RdOt02JTvDnLiX@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ramsay@ramsayjones.plus.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).