public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Michael Haubenwallner <michael.haubenwallner@ssi-schaefer.com>
Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>,
	Paolo Bonzini	<bonzini@gnu.org>, DJ Delorie <dj@redhat.com>,
	Nathanael Nerode	<neroden@gcc.gnu.org>,
	Alexandre Oliva <aoliva@redhat.com>,
	Ralf Wildenhues	<ralf.wildenhues@gmx.de>,
	Jan-Benedict Glaw <jbglaw@lug-owl.de>,
	GCC Patches	<gcc-patches@gcc.gnu.org>,
	Janne Blomqvist <jb@gcc.gnu.org>, Kai Tietz	<ktietz@redhat.com>,
	Jeff Law <law@redhat.com>
Subject: Re: [patch 1/28] top-level: Use automake-1.11.6
Date: Tue, 12 May 2015 15:28:00 -0000	[thread overview]
Message-ID: <alpine.DEB.2.10.1505121520370.23269@digraph.polyomino.org.uk> (raw)
In-Reply-To: <5551BDC3.5070002@ssi-schaefer.com>

On Tue, 12 May 2015, Michael Haubenwallner wrote:

> On 05/11/2015 07:55 PM, Joseph Myers wrote:
> > On Sat, 9 May 2015, Bernd Edlinger wrote:
> > 
> >> But maybe you would like it better if we update, for instance, to:
> >> automake-1.14  _and_  autoconf-2.69 ?
> > 
> > Updating to current automake and autoconf release versions (but still 
> > using git versions of the toplevel scripts, not those from particular 
> > releases) is a good thing 
> 
> Agreed - but that seems to require additional source changes, which is
> beyond my knowledge (and need). Besides that: wouldn't such commits be
> of better quality when starting from identical old (1.11.6) versions?

I don't see any real difference.  Updating to 1.11.6 is useful in the 
absence of anyone working on the more major update, but if someone's 
working on the more major update, whether there's an update first to 
1.11.6 shouldn't matter much.

> > - remembering that toplevel is shared with the 
> > binutils-gdb and newlib-cygwin repositories
> 
> Just curious: I do remember this from the old CVS days, but given that
> gcc has its own Subversion repository, how is that organized now?

When someone changes a shared directory, they should apply the changes to 
all three repositories.  Simply copying a shared file from one place to 
another isn't safe without checking that all changes in the destination 
repository since the files were last in sync were properly applied to the 
source repository, so that copying the file doesn't lose changes; no one 
repository is the master.

-- 
Joseph S. Myers
joseph@codesourcery.com

  reply	other threads:[~2015-05-12 15:23 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-05 16:03 [patch 0/27] RFC: Use automake-1.11.6 across the tree Michael Haubenwallner
2015-05-06  8:51 ` [patch 1/28] top-level: Use automake-1.11.6 Michael Haubenwallner
2015-05-06  9:37   ` Jakub Jelinek
2015-05-06 15:56   ` Joseph Myers
2015-05-07  9:59     ` Bernd Edlinger
2015-05-07 15:25       ` Joseph Myers
2015-05-08 11:39         ` Bernd Edlinger
2015-05-08 16:41           ` Joseph Myers
2015-05-08 18:41             ` Bernd Edlinger
2015-05-08 20:21               ` Joseph Myers
2015-05-09  6:16                 ` Bernd Edlinger
2015-05-11 17:55                   ` Joseph Myers
2015-05-12  8:49                     ` Michael Haubenwallner
2015-05-12 15:28                       ` Joseph Myers [this message]
2015-05-12 16:44                       ` Michael Haubenwallner
2015-05-12 17:22                         ` Joseph Myers
2015-05-06  8:55 ` [patch 2/28] boehm-gc: " Michael Haubenwallner
2015-05-06  8:58 ` [patch 3/28] fixincludes: Use automake-1.11.6 (across the tree) Michael Haubenwallner
2015-05-07 22:10   ` Bruce Korb
2015-05-08  9:26     ` Michael Haubenwallner
2015-05-06  9:02 ` [patch 4/28] gotools: " Michael Haubenwallner
2015-05-07 14:35   ` Ian Lance Taylor
2015-05-06  9:04 ` [patch 0/27] RFC: Use automake-1.11.6 across the tree Michael Haubenwallner
2015-05-06  9:06 ` [patch 6/28] libatomic: Use automake-1.11.6 Michael Haubenwallner
2015-05-06  9:09 ` [patch 7/28] libbacktrace: Use automake-1.11.6 (across the tree) Michael Haubenwallner
2015-05-06  9:13 ` [patch 8/28] libcc1: " Michael Haubenwallner
2015-05-06  9:16 ` [patch 9/28] libcilkrts: Use automake-1.11.6 Michael Haubenwallner
2015-05-06  9:18 ` [patch 10/28] libcpp: " Michael Haubenwallner
2015-05-06  9:19 ` [patch 11/28] libdecnumber: " Michael Haubenwallner
2015-05-06  9:22 ` [patch 12/28] libffi: Use automake-1.11.6 (across the tree) Michael Haubenwallner
2015-05-06  9:27 ` [patch 13/28] libgfortran: Use automake-1.11.6 Michael Haubenwallner
2015-05-06  9:29 ` [patch 14/28] libgomp: Use automake-1.11.6 (across the tree) Michael Haubenwallner
2015-05-06  9:32 ` [patch 15/28] libgo: " Michael Haubenwallner
2015-05-06  9:33 ` [patch 16/28] libitm: " Michael Haubenwallner
2015-05-06  9:38 ` [patch 17/28] classpath: Use automake-1.11.6 Michael Haubenwallner
2015-05-06 10:07 ` [patch 19/29] libjava: " Michael Haubenwallner
2015-05-06 10:09 ` [patch 20/29] libmpx: Use automake-1.11.6 (across the tree) Michael Haubenwallner
2015-05-06 10:11 ` [patch 21/29] libobjc: " Michael Haubenwallner
2015-05-06 10:13 ` [patch 22/29] liboffloadmic: Use automake-1.11.6 Michael Haubenwallner
2015-05-06 10:37   ` Michael Haubenwallner
2015-05-06 10:14 ` [patch 18/29] libltdl " Michael Haubenwallner
2015-05-06 10:15 ` [patch 23/29] libquadmath: Use automake-1.11.6 (across the tree) Michael Haubenwallner
2015-05-06 10:17 ` [patch 24/29] libsanitizer: Use automake-1.11.6 Michael Haubenwallner
2015-05-06 10:18 ` [patch 25/29] libssp: " Michael Haubenwallner
2015-05-06 10:21 ` [patch 26/29] libstdc++-v3: Use automake-1.11.6 (across the tree) Michael Haubenwallner
2015-05-13 10:37   ` Jonathan Wakely
2015-05-13 11:59     ` Michael Haubenwallner
2015-05-06 10:27 ` [patch 27/29] libvtv: " Michael Haubenwallner
2015-05-06 10:33 ` [patch 28/29] lto-plugin: " Michael Haubenwallner
2015-05-06 10:34 ` [patch 29/29] zlib: Use automake-1.11.6 Michael Haubenwallner
2015-05-06 13:01 ` [patch 0/27] RFC: Use automake-1.11.6 across the tree Bernd Edlinger
2015-05-07  9:22   ` [patch 0/29] " Michael Haubenwallner
2015-05-07 16:52   ` [patch 0/27] " Michael Haubenwallner
2015-05-08 11:22     ` Bernd Edlinger
2015-05-12  7:45       ` Michael Haubenwallner
2015-05-08 11:55     ` Andreas Schwab
2015-05-06 14:09 ` Jeff Law
2015-05-07 15:52   ` [patch 0/29] " Michael Haubenwallner
2015-05-08 18:49     ` Jeff Law
2015-05-08 20:22       ` Joseph Myers
2015-05-08 20:48         ` Jeff Law
2015-05-13 11:59 ` [committed] [patch 0/27] " Michael Haubenwallner
2015-05-18  9:14 ` [patch 0/27] RFC: " Michael Haubenwallner

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=alpine.DEB.2.10.1505121520370.23269@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=aoliva@redhat.com \
    --cc=bernd.edlinger@hotmail.de \
    --cc=bonzini@gnu.org \
    --cc=dj@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jb@gcc.gnu.org \
    --cc=jbglaw@lug-owl.de \
    --cc=ktietz@redhat.com \
    --cc=law@redhat.com \
    --cc=michael.haubenwallner@ssi-schaefer.com \
    --cc=neroden@gcc.gnu.org \
    --cc=ralf.wildenhues@gmx.de \
    /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).