At Tuesday 06 July 2010, Ralf Wildenhues wrote: > > I just thought that the feature could be a reasonable candidate > > for a new branch, which BTW would have given me a first > > opportunity to mess around with remote branching and pushing > > without touching/endangering the master/maint branches. > Indeed. Does this mean "OK, you can create and push the branch, I'll review that instead of your git-formatted patches"? > > > it shouldn't be necessary to post updated patches nor push a > > > branch; I have your patches in an old branch sitting here. > > > > Agreed. But I think it would be a good idea anyway to edit the > > ChangeLog of the [PATCH 2/6] to cite also Solaris 10 > > /usr/xpg4/bin/make rather than only Heirloom make. > > Sure. I didn't mean that I would push the old branch; just that > for reviewing I won't necessarily need an update. The update wasn't meant to ease the review, just to avoid any merge conflict (which would have been spurious anyway), and to improve the ChangeLog entry w.r.t. the make implementations affected.
> > Yes, it's definitely possibile. But why maint? I'm not so sure > > the change should to be considered as maintainance/bugfixing > > only... > > Oh, I didn't mean that the patch series should be committed to the > maint branch. Rather, that it should be committed to a new branch > which itself is based off of the maint branch, rather than based > off of master. This doesn't mean that the patch series should be > merged into maint at some point into the future, but that it > *could* be done; IOW, I would like to be able to postpone the > decision about where to merge the branch to. A more likely > scenario, namely that it is merged into master only but not maint > nor branch-1.11, is still possible, and rarely more work. Oh. This makes sense, and sounds like a good idea too. Regards, Stefano