On Tue, 2009-03-17 at 09:22 -0300, Otavio Salvador wrote: > > It would be misleading to take the output of something like "git log > > 2.6.3..2.6.99.901" since that would list several bug fixes as being > > "new" since 2.6.3 when in fact the same fixes were already cherry-picked > > to the 2.6 branch and were present in 2.6.3. > > A better way is when it is target to the maint branch (2.6 in your case) > you should try to commit on it and merge it from time to time at master > (or 2.7 in your case).
I'm still failing to explain things I think. :-) The 2.6.3 release was made on the maintenance branch named "2.6". Our 2.7 release candidates, (including 2.6.99.901), are being made from a *new* maintenance branch named "2.7". Oh, or maybe you understood that just fine. Perhaps you're saying that instead of committing to master and cherry-picking to the master branch, we could instead commit bug fixes to the maintenance branch and then merge that into master periodically? Yes, that's certainly possible, and I've had good success doing that kind of thing with other projects. That's just not the way the xf86-video-intel team has been doing things before. But maybe we'll try that at some point. -Carl
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
