Flagging stable patches

[Martin Geisler]

Greg Ward <greg-hg at gerg.ca> writes:

> On Mon, Jul 13, 2009 at 7:18 AM, Dirkjan Ochtman<dirkjan at ochtman.nl> wrote:
>> I think in most cases stableness is reasonably obvious anyway.
>
> Disagree.  On more than one occasion, I've sent an "obviously stable"
> patch that would benefit from getting into the next bugfix release
> pushed to crew rather than crew-stable.

I think there has been some confusion (at least from my side) about just
what should go into crew-stable and what should go into crew.

It used to be so that only *important bugfixes* went into crew-stable
and everything else went into crew. It was rare that stuff got into
crew-stable and I didn't even have a crew-stable clone on my machine for
a long time.

But after 1.3, Matt has indicated that the defaults have changed. As I
understand it, we now push *straight-forward bugfixes* to crew-stable
and everything else to crew. In that way, crew-stable is in perpetual
feature freeze.

I actually like this and think it's important to get bugfixes of all
kinds out sooner. I have just been slow to get used to the new policy.

I guess that also means that I can base mercurial-i18n on stable since
that repository will see more updates now? But then the "big
re-wrapping" patch should have gone into crew, otherwise translators
will only see it shortly before the next major release :-/


Perhaps we should begin a new practice and push just once from hg to
hg-stable and do it earlier, say 2-3 weeks before the release. That will
automatically mark the beginning of the feature freeze since no new
features to into hg-stable.

That way hg-stable will always be in preparation for the next point or
major release and translators will have time to update the translations
for new stuff introduced in crew since the last major release.

Development can even continue in hg and crew while hg-stable and
crew-stable are made ready for the release.

> And my most recent bugfix got pushed twice, because Martin pushed to
> crew and then Matt queued it for stable. Surely we can do better than
> that.

I think it's mostly a matter of finding the new balance. I'll now try to
look at each patch and figure out if it's straight-forward enough to be
put in crew-stable and otherwise put it in crew.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.