From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 718 invoked by alias); 24 Jan 2014 07:56:59 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 708 invoked by uid 89); 24 Jan 2014 07:56:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout22.012.net.il Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Jan 2014 07:56:56 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MZW00700BEKGO00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Fri, 24 Jan 2014 09:56:50 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZW007DKBEPCD30@a-mtaout22.012.net.il>; Fri, 24 Jan 2014 09:56:50 +0200 (IST) Date: Fri, 24 Jan 2014 07:56:00 -0000 From: Eli Zaretskii Subject: Re: reject merges on gdb release branches? In-reply-to: To: Ricard Wanderlof Cc: brobecker@adacore.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83ha8tersb.fsf@gnu.org> References: <20140122051133.GB4762@adacore.com> <83r480f2r2.fsf@gnu.org> <20140122161520.GF4762@adacore.com> <83bnz4ezst.fsf@gnu.org> <83wqhqekpp.fsf@gnu.org> X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00916.txt.bz2 > Date: Fri, 24 Jan 2014 08:36:25 +0100 > From: Ricard Wanderlof > CC: "brobecker@adacore.com" , > "gdb-patches@sourceware.org" > > On Thu, 23 Jan 2014, Eli Zaretskii wrote: > > >> > >> I think it's not the merging per se that is a problem, only if it is done > >> incorrectly, i.e. merging from a branch that was was broken off from > >> master a long time ago, which brings in a lot of unwanted stuff. > > > > There's any number of ways one can make a mistake and screw up master. > > That cannot be the reason for forcing a particular workflow on > > everyone, certainly not before any such problems actually happened > > even once. > > > > And I don't understand your fear of unwanted stuff from a divergent > > branch: what exactly is special about this situation? Surely, > > examining the diffs before committing and pushing would show what is > > about to land on master, so where's the danger that doesn't exist in > > any other commit? > > I'm not trying to advocate one or the other, rather just trying to > understand the reasoning behind the decision. So am I. And I still don't understand that reasoning. Let me turn the table and ask: are there any objections to removing this restriction on master, and leaving it only on the branch? If there are no objections, can we please remove the restriction?