On Sat, Nov 15, 2008 at 5:58 PM, Branko Èibej <brane_at_xbc.nu> wrote:
> Neels J. Hofmeyr wrote:
>...
>> Should we maybe think of a Plan B? What parts of tree-conflicts handling
>> could just be disabled so that 1.6 becomes stable without removing
>> tree-conflicts altogether?
I'd posit that "most of us" cannot answer that question. "You guys"
need to figure out where to can cut/splice when push comes to shove.
What can be trimmed or unimplemented, while leaving some/most of the
good code? Where are the fringes that can be tied off?
Worst case, how does it all get disabled? For example, maybe it is "as
simple" as leaving all the code in there, but anything that *sets* the
tree conflict markers just gets disabled. Therefore, none of the
conflict code ever triggers cuz a conflict is never recorded. (of
course, this might not work if *other* types of conflict were merged
into the tree conflict code, so we need all that now)
>> What are your views, everyone...
>
> I think it is *always* better to say, "sorry, we couldn't do this in the
> time available", rip out an unstable feature, and roll 1.6 with the
> other improvements already on trunk; than to have to keep apologizing
> for either delaying the release, or shipping a crap implementation.
Agreed. I'd suggest a time-bound.
People keep holding up "December release" as some mighty Must
Accomplish. Seriously, that isn't a holy grail. We *can* easily slip
to January or Feburary. No big deal. What we DON'T WANT is to slip to
December of NEXT YEAR.
So. I'd suggest that the tree conflict folks need to come up with a
schedule here. What is the likely outcomes here? What time frames are
likely to be associated with those?
Obviously, this is called "Research & Development" for a reason.
Something can always come up. But when it is *likely* to be finished?
What sections can remain unimplemented? What is the final set of
features? *SOME* kind of idea is needed here, along with various
triage options.
I'd suggest the tree conflict folks focus on four possible plans:
* cut it out altogether so we can ship "now"
* code/cut to fit a ONE WEEK stabilization timeline
* code/cut to fit a three week timeline
* code/cut to fit end-of-year timeline
The one week means "wrap it now and we'll definitely hit EOY release".
Three weeks is "we might hit EOY". EOY release obviously means end of
January or so.
Personally, I would give the tree conflict folks until first/second
week of January (i.e. just post-break) to wrap their work. And by
"wrap", I mean finish or cut. I think it is TOTALLY acceptable for us
to ship 1.6 in a Jan/Feb timeframe, so I'm more than willing to give
them the *proper* time to get the work done and make it solid. I fear
that putting this feature "under the gun" will be a bad outcome for
everybody. It also seems to be reasonable/close enough that we can
take a month or two to get it wrapped (or cut, worst case).
Cheers,
-g
Received on 2008-11-16 04:35:40 CET