Wolfgang Denk wrote:
Dear Scott Wood,
In message 20091215201449.GA4731@loki.buserror.net you wrote:
I don't follow -- why can't people base patches on the tree they're expecting them to be applied to?
In the end, people expect to have their patches applied to mainline, which means "master" or "next", right?
Yes, as part of the set of patches in the custodian tree. Why introduce conflicts by targetting an older tree? What if the new patch depends on previous patches that have gone into the custodian branch?
Any custodian trees are just staging areas on that way, and custodian should take care to keep he difference between their trees (at least their master branches) to mainline as small as possible.
Obviously we aren't going to keep the trees gratuitously different -- but sometimes there will be patches in there, and we should encourage, not discourage, patch submitters targetting the tree that they will actually be applied to.
I also don't see what is different about this patch than all the other patches on the list that target some custodian tree. If you're trying to change common practice, a general announcement would be nice rather than picking an arbitrary patch to make an example out of.
I always try to handle any pull requests really quickly.
So I should send a request immediately after every set of patches I apply, with no time for futher testing or review? What if the next branch hasn't opened yet?
If I am supposed to test something, I don;t want to have to bother about some 30+ custodian trees hanging around, and finding the right branch in the right tree
I'm fine with asking people to specify exactly what branch/repo they had in mind for the patch.
I don't want to have to resolve merge conflicts (inevitably sometimes incorrectly) in every patch because they were based on code which has been modified by a previously-applied patch.
-Scott