Re: [RFC] 3.1 branching

On Sun, 2008-09-14 at 03:26 +1200, Amos Jeffries wrote:
> please, please, please, lets get this done before any more functionality
> features make it into HEAD. Yeah, I know, I'm still throwing merge
> requests for functionality around myself.

I think we should do it very soon. Personally, I need 10 or 17 days (see
below).

Are there any big trunk changes that are waiting for v3.1 branching?

> The old blocker issues were:
>
> "
> ## I thought you and Alex had thrashed that all out to understanding
> ## weeks back? At least as far as I followed the thread it all made
> ## sense.
>
> We got to the point where there was understanding why this new family of
> races occur, but not sure about the resolution.. and pretty sure nothing
> has been done about it.
> "
>
> Done now with the Sept-11 commits?

Something has been done about it. I am sure we have not fixed all bugs,
and I still want to polish a lot of code, but I think this is not a
blocker for 3.1 branching.

I need to add .dox files with API notes.

> ### 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?

This is probably too vague of a statement/problem to argue about. I find
the current code easier to debug, especially when new style of callbacks
is used, because cache.log contains more structured information.

I also need to polish and publish scripts that track/isolate a given
transaction based on logged async calls.

I do not think this is a blocker for 3.1 branching.

> Others on the TODO:
>
> ### eCAP
>
> Alex is this really, really needed in 3.1 or is it okay pushed to
> early 3.2?

Yes, this is critical for 3.1, and I am focusing on that now. This is
the primary reason I need 10 days starting this Monday.

> ### 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.

Agreed. I think the format change should happen as the last significant
change before the branching of v3.1. Automation can wait if we have
nobody who can work on that.

> ### 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.

It would be nice to get this done before branching. Otherwise, merging
changes between 3.1 branch and trunk would be significantly more
difficult. I can work on this, but will need another 5-7 days in
addition to the 10 days requested for eCAP.

The planning work can be done in parallel though -- we just need to
agree on the table of what goes where and how it is named there. The
table on the wiki page should be used for that, I guess. It already has
a lot of usable stuff.

Thank you,

Alex.
Received on Sun Sep 14 2008 - 22:33:46 MDT