On Tue, Jun 14, 2011 at 16:22, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> Our 1.7.0 blocking issues collection currently looks like so:
>
> 3875 Serf SEGV in pool handling on error
> 3888 ra_serf unbound memory usage on checkout/export/update
> 3899 Auto-resolve conflicts at wc-wc copy/move destination
> 3915 upgrade should detect checksum mismatch
> 3917 can't checkout from s.a.o with serf 0.7.2
> 3920 wq item refers to file that does not exist
>
> Six (6) issues. That's it.
>
> Three of those (3875, 3888, and 3917) are Serf-related.
I'm actively working on 3888. Haven't looked at the other two.
>
> Issue 3899 is not, in my opinion, convincingly blocker-worthy, but...
>
> That leaves 3915 (which could be as easy as "just fail the upgrade") and the
> newly opened 3920.
>
> I'm cautiously optimistic that we're approaching a branchable point, and
> just wanted to give a heads-up that the very second that I notice that there
> remain zero or Serf-only issues into the 1.7.0 milestones, I will -- in
> accordance with sentiments formerly expressed by others among us -- formally
> propose that we branch this release.
Sure, though I'm with Hyrum on waiting about a week before the branch
is made. Invariably, something will come up.
I would also request that should the serf issues be resolved during
our stabilization period, that we ship with the default as serf. ie.
don't toss it because it may miss the branchpoint by a couple days
(trying to avoid that, tho!)
> If anybody is sitting on blocking issues which are being tracked solely in
> their heads, it's time to put them into the tracker. Please do not delay.
I started reviewing ### markers in the code. I would suggest that
others consider doing the same, particularly in libsvn_wc.
> If anybody (ahem, Stefan Küng) is sitting on API improvements or
> requirements tracked solely in their heads, it's time to put them into the
> tracker. Please do not delay.
>
> Finally, if anybody is planning to submit code changes that are *not*
> directly aimed at getting 1.7.0 out the door, I beg of you to please
> carefully consider if now is the best time for those changes, or if it
> wouldn't be wiser (and more respectful of the community's overall desire to
> see this release come to a conclusion) to defer until the trunk becomes
> "1.8.0-dev".
As we were reaching the 1.6.x branchpoint, Hyrum and I started the
wc-ng work on a branch. After 1.6.x branched, we reintegrated the work
back onto trunk. If "you" are considering some cool new work, then I'd
offer that suggestion as a good way to avoid being blocked.
Received on 2011-06-15 18:37:01 CEST