Andy Green wrote: > Something I didn't see you mention is that upstream is interested in > living patches against their HEAD, not what we ship (2.6.24).
Yes, good point. Seems that we're close to being able to move forward with our stable branch as well. That would be a good thing to do in general, since there's already a number of bugs that have been fixed in upstream but that still exist in our tree. How would you feel about switching to *-tracking once Om2008.9 is out ? > Carsten had an interesting way to come at a general attack on upstream > that I think you should reconsider since you didn't get anywhere with > your automated method the last six months. Well, I didn't actually have more than about a week to spend on actually trying to make this thing work, so it's not quite *that* bad :-) > His concept was to blow through our git history by essentially diffing > upstream and our patched tree in a single flat diff, then carving it up > by hand into chunks to be fed upstream. That's the traditional way, yes. I have used that approach many times in the past and I would do it again if we could just freeze other development on our tree while everybody is working on pushing things upstream. But I don't think this is a realistic model. The broken-down diff method would basically be equivalent to returning to the quilt topic patches as we had them in SVN, and restructuring them. That might have been an acceptable approach while we were using that as our principal structure, but now that the code is maintained on a changeset basis in git, that isn't compatible with our development model anymore. And in any case, since even many of the topic patches in SVN weren't properly structured, we would have needed some tools for rearranging them as well. Manually shifting lots of hunks from one patch to another and then - again, manually - fixing the rejects without any feedback on the overall change that this accomplished just leads to insanity. Since I expect the total time from starting to prepare for upstream to completing most of the merges to be measured in months (the merge windows only open so often, and I'm sure we will get feedback that will take more than just a few days to process), we need to be able to keep on going while this is happening. One could of course do another big diff, etc., but that very quickly leads to an accumulation of human error, particularly given that it's usually difficult to remember if you've done something once or more than once. We can of course still cherry-pick small changes that don't depend on the rest, and push them upstream without waiting for the rest. That won't reduce the bulk, but it'll make the overall task less daunting. The problem is of course that I don't think there are quite so many of these at the moment. (The obvious ones, such as S3C and ALSA fixes, have already found their way upstream long ago.) By doing the cleanup and breaking unnecessary dependencies, we can increase their number a little, which certainly won't hurt. By the way, "the cleanup" isn't something horrible. Holger did some of that janitorial work some months ago, and that fit very smoothly with the rest of our development work. - Werner
