On Tue, Jun 14, 2011 at 8:22 PM, 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.
>
> 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.
I'm as eager to get 1.7.0 out the door as anybody else, and look
forward to the "zero blocking issues" / "branch point" milestone.
Given the fact that we seem to be taking a
two-steps-forward-one-step-back toward that milestone, I've been
mulling the idea of waiting just a few days after the issue tracker is
cleared out before branching, just because that's when stuff seems to
come out of the woodwork. Though, if folks respond to your pleas
below, that could satisfy my concerns.
> 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.
>
> 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".
Agreed (though, I've limited myself to release scripts these days, anyway).
-Hyrum
Received on 2011-06-14 23:08:23 CEST