"Steven E. Harris" <seh@xxxxxxxxx> writes: > What about the case where an author started his work from the "next" > branch instead? He may have submitted an earlier batch of work that's > still cooking in "next," and now he needs to build something else that > can take advantage of that earlier work. It often is clear that the follow-on topic depends on an earlier topic branch (mostly because the contributor is aware of it and state it in the message). An obvious thing to do in such a case is to create a new branch to queue that topic starting at the tip of the earlier topic. Note that this is never from the tip of "next", as it is very unlikely that such a follow-on topic depends on everything that is not in "master" yet. Sometimes a new work depends on multiple topics that are still cooking, and *all* of these topics that the new work depends on are in good shape. In such a case, I create a new branch by merging these prerequisite topics and then queue new work there. Obviously the new work is taken hostage to *all* of its dependent topics, and cannot graduate until all of the base topics graduate. Sometimes a new work depends on one topic that is still cooking in "next", *and* also needs updates made by other topics that are already in "master". You can guess what should happen---take the tip of that topic that is still cooking in "next", merge the commit on "master" that adds other necessary bits, and then that becomes the base of the new topic. The "commit that adds other necessary bits" could be the tip of "master" (easiest for me, but it makes the new topic unmergeable to "maint" later) or the tip of an old topic that was merged to "master" (more work for me, but it is worth if both the other old topic and the topic that is cooking in "next" are meant to be merged to "maint" later, and the new work is also meant to eventually be merged to "maint"). In a rare cases where a new work depends on millions of uncooked topics, we simply reject the follow-on series and tell the submitter to wait until the dust settles, but in practice it does not happen very often. In other words, the "policy" is not a mechanical recipe to be followed by brainless monkeys; the integrator needs to follow the common sense of keeping the resulting topic branch mergeable to as many relevant contexts as necessary. And the contributor can help in this process, as well. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html