public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
To: Lorenzo Salvadore <developer@lorenzosalvadore.it>
Cc: Lorenzo Salvadore via Gcc <gcc@gcc.gnu.org>,
	 Gerald Pfeifer <gerald@pfeifer.com>,
	 Jonathan Wakely <jwakely.gcc@gmail.com>,
	 Andreas Tobler <andreast@freebsd.org>
Subject: Re: GCC testing on FreeBSD
Date: Mon, 29 Apr 2024 14:21:45 +0200	[thread overview]
Message-ID: <ydd7cggz7dy.fsf@CeBiTec.Uni-Bielefeld.DE> (raw)
In-Reply-To: <2NOYgLhrt383ftNn2yo8eJLmLnwYY4E64y6QdA3c_TvNghHor6dnmW7pCvWlUktDHpEvMrLsCopjv0KOhEVTDTgvQI0BX2OhSUeasjMtIPw=@lorenzosalvadore.it> (Lorenzo Salvadore's message of "Sun, 28 Apr 2024 18:38:07 +0000")

Hi Lorenzo,

> I totally agree with you: upstreaming patches is important! It is not
> only for the upstream project itself, but for the target as well: having
> patches sitting in a ports collection also requires more maintainance,
> they require to be kept up to date with the upstream progresses.

indeed: e.g. some mechanical changes that affect your port can be dealt
with easily when the developer in question finds the code in tree.
Otherwise, this is only noticed during your next merge, possibly months
later.

> Unfortunately, it is not always possible to upstream a patch. Sometimes,
> patches are too specific to a target to be suitable for upstream.

Those are called hacks ;-)  True: the code needs to be general to avoid
the codebase slowly becoming unmaintainable.  Maintainers keep the
general code structure in mind, which may create more work for the
submitter to develop a cleaner implementation.  However, this ensures
that the hack isn't broken subsequently and the code is more
understandable to everyone.

> For example, smaller projects might be interested in supporting only
> very popular platforms and would not accept (or could not accept)
> the complexity of supporting a less known target.
> Hopefully this is not the case for GCC.

I don't think so: the primary question is if the code is actively tested
and maintained.  And even so, we do have several ports in tree that have
seen barely any maintenance in a long time.  If they become a burden,
this may lead to them being obsoleted and removed.

> Other times, developers do try to upstream a patch, but fail. This
> happened to myself in GCC too, when I was unable to get any
> attention to a patch I submitted, and could not do any better
> than keep the patch into the FreeBSD ports collection:
> https://gcc.gnu.org/pipermail/jit/2023q3/001642.html
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491#c5

It happens to all of us.  It usually helps to include the maintainers in
question in the Cc:  I've often also had better success by pinging not
in the patch submission thread (where the pings can become lost in the
noise), but by posting a separate message to gcc-patches with subject
and URL to the latest version and perhaps a short indication who's
required to review the patch, also Cc'ing the relevant maintainers.

> If you are able to help with this upstreaming, I would appreciate
> it a lot. Thanks.

Probably not much: for one I'm pretty busy with my own Solaris work, and
I've also stopped testing on FreeBSD even with the issues I've found and
developed workarounds for.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

  reply	other threads:[~2024-04-29 12:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-26 11:06 Jonathan Wakely
2024-04-28 10:24 ` Gerald Pfeifer
2024-04-28 10:32   ` Rainer Orth
2024-04-28 13:39   ` Lorenzo Salvadore
2024-04-28 17:19     ` Rainer Orth
2024-04-28 18:38       ` Lorenzo Salvadore
2024-04-29 12:21         ` Rainer Orth [this message]
2024-04-28 16:17   ` Jonathan Wakely

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

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

  git send-email \
    --in-reply-to=ydd7cggz7dy.fsf@CeBiTec.Uni-Bielefeld.DE \
    --to=ro@cebitec.uni-bielefeld.de \
    --cc=andreast@freebsd.org \
    --cc=developer@lorenzosalvadore.it \
    --cc=gcc@gcc.gnu.org \
    --cc=gerald@pfeifer.com \
    --cc=jwakely.gcc@gmail.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.
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).