"Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> writes: > I am not worried about what it will take time to get the changes I > posted into the integration. I had only envisioned them as good enough > to get the technical ideas across, and had never envisioned them as > being accepted as is. Ah, no worries. By "integration" I did not mean "patches considered perfect, they are accepted, and are now part of the Git codebase". All that happens when the patches become part of the 'master' branch, but before that, patches that prove testable and worthy of getting tested will be merged to the 'next' branch and spend about a week there. What I meant to refer to is a step _before_ that, i.e. before the patches probe to be testable. New patches first appear on the 'seen' branch that merges "everything else" to see the interaction with all the topics "in flight" (i.e. not yet in 'master'). The 'seen' branch is reassembled from the latest iteration of the patches twice of thrice per day, and some patches are merged to 'next' and down to 'master', these "merging to prepare 'master', 'next' and 'seen' branches for publishing" was what I meant by "integration". In short, being queued on 'seen' does not mean all that much. It gives project participants an easy access to view how topics look in the larger picture, potentially interacting with other topics in flight, but the patches in there can be replaced wholesale or even dropped if they do not turn out to be desirable. I resolved textual conflicts and also compiler detectable semantic conflicts (e.g. some in-flight topics may have added callsites to a function your topic changes the function sigunature, or vice versa) to the point that the result compiles while merging this topic to 'seen', but tests are broken the big time, it seems, even though the topic by itself seems to pass the tests standalone. > What I am envisioning as my future directions are: > ... > Does that sound like a reasonable plan? Nice.
