From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936264AbYEUSuH (ORCPT ); Wed, 21 May 2008 14:50:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757682AbYEUStz (ORCPT ); Wed, 21 May 2008 14:49:55 -0400 Received: from cantor2.suse.de ([195.135.220.15]:60702 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756636AbYEUStz (ORCPT ); Wed, 21 May 2008 14:49:55 -0400 Date: Wed, 21 May 2008 20:49:53 +0200 Message-ID: From: Takashi Iwai To: david@lang.hm Cc: Linus Torvalds , Rene Herman , alsa-devel@alsa-project.org, Linux Kernel Subject: Re: [alsa-devel] HG -> GIT migration In-Reply-To: References: <200805211430.06653.linux@audioscience.com> <483415E7.5080402@keyaccess.nl> <48341DF5.4090307@keyaccess.nl> <48344271.3090700@keyaccess.nl> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.5 (beta28) (fuki) (+CVS-20070806) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Wed, 21 May 2008 11:25:25 -0700 (PDT), david@lang.hm wrote: > > On Wed, 21 May 2008, Linus Torvalds wrote: > > > [ The corrollary to this all is that when downstream does a merge, think > > about what the merge message can say. How would you descibe the merge? > > > > Can you give a good description of what you merged, and why? That's one > > thing that merging with releases can give you: you can say "merge with > > release 'xyz'", and people actually understand the *meaning* of it. Your > > merge message makes sense - and that implies that the merge itself > > likely made sense. > > > > If you cannot explain what and why you merged, you probably shouldn't be > > merging - that's a good rule of thumb right there! Maybe that rule in > > itself should already be seen as sufficient ] > > one thing that you have missed in your explination in this thread > (although you have made the point in other threads) is that subsystem > maintainers have the fear that there are other changes that will interfere > with their stuff and want to catch it early. > > per your instructions in prior threads, what they should do is to have a > seperate branch on their system that they use as a throw-away branch to > pull from your tree, and from their tree to spot problems. As they find > problems they can then address them (cherry pick, or whatever) > > so it's not that the ALSA people should only look at your tree at the > merge points, it's that they shouldn't pollute their tree that they are > going to publish to you with this checking. Ah, that's what I missed. This suggestion actually makes sense. Takashi