Re: HG -> GIT migration

[Tobin Davis <tdavis@dsl-only.net>]

I updated the Developers Zone wiki to reflect the new source repository,
making it a little easier to find.

Question:  How do we get rss feeds?  Is it similar to the HG method?  I
like being able to monitor the updates via rss, to determine when I need
to refresh my tree, as I only really work on the hda-intel stuff at the
moment.

Tobin

On Wed, 2008-05-21 at 18:51 +0200, Takashi Iwai wrote:

> At Wed, 21 May 2008 09:16:05 -0700 (PDT),
> Linus Torvalds wrote:
> > 
> > 
> > 
> > On Wed, 21 May 2008, Takashi Iwai wrote:
> > > 
> > > But, this means that the fixes done outside the subsystem tree cannot
> > > be in the subsystem tree itself until the next release.  It's a pretty
> > > weird situation.
> > 
> > No it is NOT.
> > 
> > Why should you have stuff from outside the subsystem tree?
> 
> Well, what I meant is about the fixes to the subsystem (say, ALSA) by
> people in the outside.  Not every ALSA-bugfix patch goes into the
> upstream from ALSA tree.  You, Andrew and others pick individually
> ALSA-fix patches.  They will be missing in the ALSA subsystem tree.
> 
> And, what if that you need a fix for the fix that isn't in ALSA
> tree...?  IMO, either a rebase or a merge is better than
> cherry-picks.
> 
> > And quite frankly, the only reason to *need* those fixes in the first 
> > place is if you merge random test-kernels during the merge window. What 
> > you should strive for is to merge at the stable point, not random kernels 
> > to keep you "up-to-date", and suddenly you don't need to make more merges 
> > just to get (possibly) new fixes.
> > 
> > See?
> > 
> > If it's the ALSA tree, then what is it doing pulling all the random other 
> > stuff that I merge?
> > 
> > In other words - merging my random stuff, THAT is the "weird situation". 
> > You should be doing ALSA development, not "random kernel" development.
> 
> Hmm, that makes me thinking of the development model.
> We can leave ALSA tree without upstream fixes as is if user always
> pull both ALSA and upstream trees.  This works for users that are
> using the latest development kernel.
> 
> > > The method Linus suggested is suitable for random patches like tirival
> > > tree, but apparently not for every case.
> > 
> > Umm. Bigger subsystems than ALSA are successfully using it and have no 
> > problems, and don't think they need to merge backwards:
> > 
> > 	[torvalds@woody linux]$ git rev-list v2.6.25.. drivers/net/ | wc -l
> > 	739
> > 	[torvalds@woody linux]$ git rev-list v2.6.25.. sound/ | wc -l
> > 	291
> > 
> > iow, the only reason you seem to think that you need to merge more is that 
> > you merged too much, or from a too-unstable base, to begin with.
> > 
> > Aim for basing things on releases, or at least for merging just at stable 
> > points (and only when you *need* to, and it will make your life much 
> > easier. And the history will automatically be cleaner and less confusing.
> 
> Yes, I see the point.
> 
> But, my question is about the divergence between the development and
> for-linus branches: how to apply patches that exist only in for-linus
> tree back.
> 
> 
> thanks,
> 
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- 
Tobin Davis 


What PROGRAM are they watching?