From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29351 invoked by alias); 25 Aug 2011 16:13:23 -0000 Received: (qmail 29335 invoked by uid 22791); 25 Aug 2011 16:13:21 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp22.services.sfr.fr (HELO smtp22.services.sfr.fr) (93.17.128.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 25 Aug 2011 16:13:04 +0000 Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2202.sfr.fr (SMTP Server) with ESMTP id 6C35E70035EB; Thu, 25 Aug 2011 18:13:02 +0200 (CEST) Received: from gimli.local (78.123.193.77.rev.sfr.net [77.193.123.78]) by msfrf2202.sfr.fr (SMTP Server) with ESMTP id 3B28D70002A9; Thu, 25 Aug 2011 18:13:02 +0200 (CEST) X-SFR-UUID: 20110825161302242.3B28D70002A9@msfrf2202.sfr.fr From: Mikael Morin To: fortran@gcc.gnu.org Subject: Re: [Patch, Fortran] PR 50163 - ICE with nonconst expr in init expr Date: Thu, 25 Aug 2011 17:42:00 -0000 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.5.5; amd64; ; ) Cc: Tobias Burnus , gcc patches References: <4E539C93.7070704@net-b.de> <201108241212.42494.mikael.morin@sfr.fr> <4E54FD25.601@net-b.de> In-Reply-To: <4E54FD25.601@net-b.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201108251540.54765.mikael.morin@sfr.fr> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-08/txt/msg02086.txt.bz2 On Wednesday 24 August 2011 15:31:17 Tobias Burnus wrote: > > Isn't there some rules about backporting? The way we do it now, it > > looks completely arbitrary. > > I think it *is* arbitrary - and unavoidable so. > > The main idea behind regression fixing is to make sure that what once > worked should continue to work. But what always had been broken can > remain broken and will be only fixed on the trunk. Reason: If you fix > more, the behaviour on the branch changes and you may introduce > regressions. If thinks are known to be broken, you can simply work > around them. > > Additional ingredients are: How serious is the problem? A wrong-code > issue occurring in a potentially often used part has a different > priority than an accepts-invalid or ice-on-invalid-code issue. Also, a > patch which is huge is less suited than a small "trivial" patch. > Regressions, which existed for a long time are typically also less > important - otherwise they would have been fixed or found before. > > But there are also other items such as: Which is the last maintained > version in GCC, which versions are still being used (such that it makes > sense to backport), and which patches (Linux) distributions want to see. > Additionally, as backporting takes time (bootstrap, regtesting, and > maybe even adapting the patch slightly): How much time wants the > developer spend on backporting. > OK, it's a complex problem, and that's the very reason for my remark. > My impression is that gfortran is currently doing too much > non-regression backporting, which should be left to serious ICE-on-valid > code and wrong-code issues. Especially as older versions do not see as > much testing as the trunk. > I didn't have that impression; a matter of style probably. Yes we could try to be more carefull in the future. > [...] > > But at the end it is question of style. > [...] > Well, I was asking whether we could decide on our own style. > [...] > > I didn't really answer your question, did I? > You exposed your point of view clearly, which is certainly a step forward. There are some basic rules for backports, on which everybody agrees; but in the end the same question is raised over and over again, and nobody seems to know really: how far should we backport? Currently the GCC rules are (basically): not a regression -> no backport (unless serious bug/trivial fix) regression -> backport On the other hand, we have three open branches (trunk apart) and it is not clear to me whether we should apply the same rules to all of them or shade the seriousness and trivialness trigger levels into the 3 levels of backport we have. Furthermore we have to take into account our (lack of) ressources and (amount of) interest for doing the backport. So I was proposing to include version numbers into the rules, and be more specific about them, like for example: - Serious (wrong-code, ice-on-valid) non-regression bugs with a simple fix are backported to N-1 only. [N is trunk] - Non-serious regressions are not backported beyond N-2. - ... Of course in the end, what is simple, what is serious, are arbitrary. Maybe you are right, it's unavoidable. Mikael