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?

Well, I'll call for a partial hold right now. Please only commit bug
fixes, minor cleanups, and features already on the roadmap for 3.1. The
rest can be queued for commit post branch.

Now that Henrik has withdrawn his blocker opinion on AsynCalls, there is
only these to go:

* HTTP/1.1 pieces for the error negotiation
   (Content-Language and Vary headers) already in merge queue, needs
another eyeball and vote, but I'm happy enough to commit anyway.

* connection pinning
  I thinking it's been outstanding long enough we should get it into 3.1,
even if we have to hold PRE1 a week after the branch to stabilize it (or
test it in PRE1 ?).

* kerberos helper
  Markus has supplied another set of code, I assume its been tested
externally and just needs a drop-in.

* eCAP

* source layout
  see below.

* source formatting
  scripts committed for use already, I was planning on starting the
re-format and testbed run today here.

I was hoping to branch this weekend, I'm away in 10 days, but 14 days or
so would be the next mutual point. HEAD will only be commit-closed for a
day or less while I get sorted.

Lets set a date: 29 September?

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

Last time around I had that opinion too. Now that I've given it a closer
look I think we can do it in sections by folder at any time. As long as
any branches with big changes (your eCAP?, my portability-cleanup,
others?) get formatted separately before they next merge from trunk.

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

I've added a column (left side) where we can use smilies to indicate what
we are currently moving (prevent clashes) and whats done. The table should
already contain the list of files involved with each folder, if not it
needs updating as we find bits.
I think that committing each folder move tested in isolation and committed
to trunk individually would be a good way to do it.

Amos
Received on Mon Sep 15 2008 - 03:03:43 MDT