On Tue, Feb 12, 2008 at 09:09:34AM -0800, Linus Torvalds wrote:
>...
> The other is that once somebody says "ok, I *really* need to cause this
> breakage, because there's a major bug or we need it for fundamental reason
> XYZ", then that person should
>
> (a) create a base tree with _just_ that fundamental infrastructure change,
> and make sure that base branch is so obviously good that there is no
> question about merging it.
>
> (b) tell other people about the reason for the infrastructure change, and
> simply allow others to merge it. You don't have to wait for *me* to
> open the merge window, you need to make sure that the people that get
> impacted most can continue development!
>
> This is where "rebases really are bad" comes in. When the above sequence
> happens, the fundamental infrastructure change obviously does need to be
> solid and not shifting under from other people who end up merging it. I do
> not want to see five different copies of the fundamental change either
> because the original source fixed it up and rebased it, or because the
> people who merged it rebased _their_ trees and rebased the fundamental
> change in the process.
>
> Can that (b) be my tree? Sure. That's been the common case, and I'll
> happily continue it, of course, so I'm not arguing for that to go away.
> Merging is my job, I'll do it. But when the merge window is a problem, my
> merge window should *not* hold up people from using the distributed nature
> of git for their advantage.
>
> But yes, obviously when doing cross-merges, you'd better be really
> *really* sure that the base is solid and will get merged. But let's face
> it, all the really core maintainers should damn well know that by now:
> you've all worked with me for years, so you should be able to trivially be
> able to tell whether you *might* need to worry about something, and when
> it's a slam dunk.
>
> And it's the "it's a slam dunk" cases that I think are (a) the common ones
> and (b) the ones where you can just do cross-merges to satisfy each others
> needs.
>
> Hmm? Does that sound palatable to people?
I'm sure I understand only less than half of what you said.
My current understanding is that all the aspects of your proposal that
are interesting for me can be summarized as follows:
- your tree stops compiling at the beginning of the merge window when
you merge the first subsystem tree
- your tree might compile again at the end of the merge window when you
merge the last subsystem tree
- git-bisect -> /dev/null
What do I miss?
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
