Felipe Contreras <felipe.contre...@gmail.com> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to