Re: [RFC] 3.1 branching

On sön, 2008-09-14 at 03:26 +1200, Amos Jeffries wrote:

> ### A way of making the code a bit deterministic?
>
> Unlike the earlier recursion race the asynccall timing race is a bit of
> a nightmare to debug postmortem.. which will very likely cause many gray
> hairs while trying to analyze debug reports..
> "
>
> Is this cleared now Henrik?

Not cleared, but Alex is pretty much ontop of things removing my
concern. It's more a design comment than a reservation.

> ### Code formatting
>
> A few issues still to be sorted out. Nothing major though. The
> majority of HEAD can be formatted in an hour or so notice.
>
> - todo: make existing scripts recursive over entire sources.
> - how to automate for commit enforcement in bzr
> - how to fix access_log.cc output (maybe others with same issue)
> - work pattern for propagation to branches.

Do we need to automate and enforce formatting? Should be sufficient to
run the formatting tools every now and then combined with inspecting the
results.

But yes, if the tree is to be reformatted then it's better done before
branching to minimize the merge conflicts in later backports..

> ### source layout
>
> Not a blocker for the branch. Though Alex if you wanted to get in
> touch about the exact plan of attack I'll make the time to help out here.

This is material for the next cycle I think.

> ### bug zapping
>
> New Critical ones are now dead.
> Only important ones now are shared with 3.0.

bug zapping is not a blocker for branching. Branching is determined by
the feature set and pending+upcoming feature merges.

Regards
Henrik
Received on Sun Sep 14 2008 - 12:01:09 MDT