From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.CeBiTec.Uni-Bielefeld.DE (smtp.CeBiTec.Uni-Bielefeld.DE [129.70.160.84]) by sourceware.org (Postfix) with ESMTPS id EF9053858D33 for ; Mon, 29 Apr 2024 12:21:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EF9053858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=CeBiTec.Uni-Bielefeld.DE Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cebitec.uni-bielefeld.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EF9053858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.70.160.84 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714393310; cv=none; b=xZFKB0bh1jZcoFuJXKsVCtmSfuYjtokAwwJeQ51gQgcNXZDyWa7beEcY72YxPD9jyv8ecRWDb5azvEPtm1/1dPvAdDtmftq805WHqO34+XaWbF3gFpmpouq/HUuj/taJP70XZ1rW+I4DX5CphzbbQgEGU8Cfv81MXy3QtF+tuc4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714393310; c=relaxed/simple; bh=WkoXW+fyp8yhCwulQZ+YcPqCGz0D/86XP4Gk5NfIkWw=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=QMM0RBKZ4DA6iFjB03DVHkn1exWEuf48xXu4bbv3EJHtAOxSmRq4oCDOjIyJAgK++aLWrx77ZBx72jHvzhaOMa1EgWellSGPDSOAl8HfTbhxebDyjvT5NXfSVFveLy6K5nhbJ93goJDj47HOt3pURtUXN/NqooU0kOSftOM3XdQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from localhost (localhost [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 02D87A9102; Mon, 29 Apr 2024 14:21:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= cebitec.uni-bielefeld.de; h=content-type:content-type :mime-version:user-agent:message-id:in-reply-to:date:date :references:subject:subject:from:from:received:received; s= 20200306; t=1714393306; bh=WkoXW+fyp8yhCwulQZ+YcPqCGz0D/86XP4Gk5 NfIkWw=; b=WRF70z46kyy1TDR0xmN5JzKCuSkGz1Fmd6V2PsE3aT8whCIe1qSyx IxuRR5RzxhTUaMZgIEUErk+zk3n1H/dYBk2faetqeExl/mCJrWDXY3fCeyU+JPTf uwunr93GQEwZmB0A95R1xfxkoCJ2kHwYK5t52imzyPTnJj1PJF/39VpnAYtgC9eC VpBVQMwW83bpmXN20YNx/uQsFgcpyD2Eee2KcC6plK+gPBbFiwhM1zQ7u7gX/NB+ /jWtDfJ655rzGYeEpVpo3NwosPpf9s2Moxhosf2MKM+WwuLOMWyj6t4mUprT4Rk3 1y2C1tLsYyUCuUF58rJ6ruf4FpNnEGf3A== X-Virus-Scanned: amavisd-new at cebitec.uni-bielefeld.de Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GAG5L0iUu5QD; Mon, 29 Apr 2024 14:21:46 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p4fddbd87.dip0.t-ipconnect.de [79.221.189.135]) (Authenticated sender: ro) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id 5C2EBA901C; Mon, 29 Apr 2024 14:21:46 +0200 (CEST) From: Rainer Orth To: Lorenzo Salvadore Cc: Lorenzo Salvadore via Gcc , Gerald Pfeifer , Jonathan Wakely , Andreas Tobler Subject: Re: GCC testing on FreeBSD References: <866dda5e-c983-ac16-de71-05b685536cd7@pfeifer.com> <2NOYgLhrt383ftNn2yo8eJLmLnwYY4E64y6QdA3c_TvNghHor6dnmW7pCvWlUktDHpEvMrLsCopjv0KOhEVTDTgvQI0BX2OhSUeasjMtIPw=@lorenzosalvadore.it> Date: Mon, 29 Apr 2024 14:21:45 +0200 In-Reply-To: <2NOYgLhrt383ftNn2yo8eJLmLnwYY4E64y6QdA3c_TvNghHor6dnmW7pCvWlUktDHpEvMrLsCopjv0KOhEVTDTgvQI0BX2OhSUeasjMtIPw=@lorenzosalvadore.it> (Lorenzo Salvadore's message of "Sun, 28 Apr 2024 18:38:07 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.90 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3783.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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