On Wed, Jun 15, 2011 at 16:46, Mark Phippard wrote:
>...
> I want to reiterate my objections to further delaying our release
> process with these interim releases.
In my mind, I was just thinking of a couple weeks with a label
("beta") that people might actually try out.
>...
> I do not think an
On Wed, Jun 15, 2011 at 4:19 PM, Hyrum K Wright wrote:
>> ps. and if you *don't* think it is good enough for 1.7.0, then it sure
>> isn't an RC1. if we roll RC*, then we can't say "oh, but it isn't
>> final. we'll have bugs to fix." that isn't an RC. seen too much of
>> that nonsense in the past..
On Wed, Jun 15, 2011 at 8:10 PM, Greg Stein wrote:
> On Wed, Jun 15, 2011 at 15:08, Stefan Sperling wrote:
>> On Wed, Jun 15, 2011 at 02:33:04PM -0400, Mark Phippard wrote:
>>> Given that the most common distinction between alpha and beta is
>>> "feature complete" I have been arguing all along th
On Wed, Jun 15, 2011 at 15:08, Stefan Sperling wrote:
> On Wed, Jun 15, 2011 at 02:33:04PM -0400, Mark Phippard wrote:
>> Given that the most common distinction between alpha and beta is
>> "feature complete" I have been arguing all along that the existing
>> "alpha" release should have been label
On 06/15/2011 03:13 PM, Stefan Küng wrote:
> On 14.06.2011 22:22, C. Michael Pilato wrote:
>
>> 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.
>
> Point taken :)
>
>
On 14.06.2011 22:22, C. Michael Pilato wrote:
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.
Point taken :)
Filed the following issues:
http://subversion.tigris.org/issu
On Wed, Jun 15, 2011 at 02:33:04PM -0400, Mark Phippard wrote:
> Given that the most common distinction between alpha and beta is
> "feature complete" I have been arguing all along that the existing
> "alpha" release should have been labelled "beta". I would be +1 on
> changing that for the next r
On 06/15/2011 02:23 PM, Greg Stein wrote:
> I dunno what kind of review the alpha is getting. Moving it to "beta"
> would get more users. Of course, we still wouldn't know what kind of
> review it is getting, but I would say "more" :-)
Yeah, I rather suspect that the alphas serve exactly one purpo
On Wed, Jun 15, 2011 at 2:23 PM, Greg Stein wrote:
> On Wed, Jun 15, 2011 at 14:18, Hyrum K Wright wrote:
>> On Wed, Jun 15, 2011 at 4:40 PM, C. Michael Pilato
>> wrote:
>>> On 06/15/2011 12:36 PM, Greg Stein wrote:
I would also request that should the serf issues be resolved during
o
On Wed, Jun 15, 2011 at 14:18, Hyrum K Wright wrote:
> On Wed, Jun 15, 2011 at 4:40 PM, C. Michael Pilato
> wrote:
>> On 06/15/2011 12:36 PM, Greg Stein wrote:
>>> I would also request that should the serf issues be resolved during
>>> our stabilization period, that we ship with the default as s
On Wed, Jun 15, 2011 at 4:40 PM, C. Michael Pilato wrote:
> On 06/15/2011 12:36 PM, Greg Stein wrote:
>> 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
On Wed, Jun 15, 2011 at 12:40, C. Michael Pilato wrote:
> On 06/15/2011 12:36 PM, Greg Stein wrote:
>...
>> 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 branchpoi
On 06/15/2011 12:36 PM, Greg Stein wrote:
> On Tue, Jun 14, 2011 at 16:22, C. Michael Pilato wrote:
>> 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 th
On Tue, Jun 14, 2011 at 16:22, C. Michael Pilato 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
>
C. Michael Pilato wrote on Tue, Jun 14, 2011 at 16:22:08 -0400:
> 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.
I've been intending to review some more of the cache API
On Tue, Jun 14, 2011 at 8:22 PM, C. Michael Pilato 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
Our 1.7.0 blocking issues collection currently looks like so:
3875Serf SEGV in pool handling on error
3888ra_serf unbound memory usage on checkout/export/update
3899Auto-resolve conflicts at wc-wc copy/move destination
3915upgrade should detect checksum mismatch
3917can't check
17 matches
Mail list logo
