Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: >> At this point, both have been cooking for a week or more in 'next', >> there is no existing users, they are on the fringe so breakages in >> them won't negatively affect anybody anyway. So it doesn't matter >> much if they are merged to 'master' and then fixed up with follow up >> patches after that, or fixed up with follow up patches while they >> are in 'next', as they won't be rewound and restarted from scratch. > > The fixes are affecting some people, that's why I did them. Some were > reported here in the mailing list, and some in my github's clone: > > https://github.com/felipec/git/issues?page=1&state=closed Are you talking about -hg or -bzr or both? In any case, I am mostly concerned about *my* next release, whose rc0 will be tagged sometime this week or the next week. People who have been bitten by bugs from *your* tree or versions in 'next' do not count. When I said "no existing users", I was talking about the end users who need rock solid stable "releases" because tagged versions are the only ones they use. If the code of these topics is still in flux and needs constant fixes, probably it is a better idea to cook them longer in 'next', skipping the upcoming 1.8.1 release. If we are going to go that route, we can drop the v2 fc/remote-bzr and queue v3 when we rewind the tip of 'next' after 1.8.1 release (by that time you may have v4 of the series, but then we can skip v3). Is that more preferrable than rushing these topics forward before they are ready for general audience? -- 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