From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25854 invoked by alias); 12 Jun 2014 17:18:56 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 25839 invoked by uid 89); 12 Jun 2014 17:18:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Jun 2014 17:18:54 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5CHIqBk004796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 12 Jun 2014 13:18:52 -0400 Received: from [10.3.113.204] (ovpn-113-204.phx2.redhat.com [10.3.113.204]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5CHIpOV011479 for ; Thu, 12 Jun 2014 13:18:51 -0400 Message-ID: <5399E0FB.8040304@redhat.com> Date: Thu, 12 Jun 2014 17:18:00 -0000 From: Josh Stone User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: systemtap@sourceware.org Subject: Re: RFC: raise the OS baseline for systemtap.git References: <5398DCD4.1010102@redhat.com> In-Reply-To: <5398DCD4.1010102@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-q2/txt/msg00248.txt.bz2 (I'm not talking to myself, just relaying irc conversations...) Frank is feeling more conservative about this, that we shouldn't deliberately remove code that some people might still want. He conceded that we might just declare pre-RHEL6-ish platforms to be deprecated, no longer actively tested, but still accepting bug reports and patches. This would at least relieve some development burden for now. Jonathan added that we might set a timeline after which we can actively start removing that old code. I think it's likely that those deprecated platforms will bitrot and break pretty quickly, if we're not testing them and developing with them in mind. But perhaps that makes it a good litmus test whether anyone cares. So I'd say we should deprecate them for a set period, say the next two releases, and if we don't see pushback then we can start actively pruning and allow things like C++11.