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@xxxxxxxxxxxxxxxx > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel -- Tobin Davis What PROGRAM are they watching? _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
