You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Hyrum K Wright <hy...@hyrumwright.org> on 2011/05/23 20:25:33 UTC
Re: "... first release candidate is expected in August 2011." Really?
On Mon, May 23, 2011 at 11:05 AM, C. Michael Pilato <cm...@collab.net>wrote:
> I recently saw the elego post-SvnDay write-up at:
>
> http://www.elegosoft.com/bestof-svnday2011/
>
> Cool stuff, and I'm glad to see that our gracious hosts felt that the day
> was successful. I know I was encouraged by conversations I had with recent
> adopters of Subversion, as well as by the opportunity to meet our two
> newest
> committers!
>
Indeed!
> I do have a question, though, about a portion of that report:
>
> The good news is: after the extensive rewrite of Subversion's working
> copy library has completed, a release branch will be created within a
> month, and the first release candidate is expected in August 2011.
>
> I didn't get the sense at the hackathon that there were enough documented
> blocker issues to delay our putting out our first release candidate for
> another *three months*. Did I miss some critical discussion on Friday?
> Did
> I simply misunderstand the discussions we had earlier in the week? Are
> there some blockers that are living in peoples' minds and *not* in the
> tracker (aka "poor collaboration and communication")? Was the write-up
> just
> a mistake, and August is actually the *release* target date?
I noticed that bit of prose as well, and just chalked it up to
an overzealous PR guy.
The outcome of the hackathon was "we'll start alpha releases in June and
branch when the blockers are gone"
-Hyrum
Re: "... first release candidate is expected in August 2011." Really?
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 05/23/2011 06:24 PM, Michael Diers wrote:
> Sorry, it's a mistake alright. The "PR guys" were rushing the PR stuff
> on Friday. This bit of incongruous information apparently slipped through.
>
>> The outcome of the hackathon was "we'll start alpha releases in June and
>> branch when the blockers are gone"
>
> We'll change that paragraph to read:
>
> The good news is: after the extensive rewrite of Subversion's working
> copy library has completed, we can expect alpha releases in June,
> to be followed by the creation of a release branch, once the
> remaining release blockers have been resolved.
Thanks for clarifying, Michael. And, your suggested edits look great.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: "... first release candidate is expected in August 2011." Really?
Posted by Michael Diers <md...@elegosoft.com>.
On 2011-05-23 20:25, Hyrum K Wright wrote:
> On Mon, May 23, 2011 at 11:05 AM, C. Michael Pilato <cm...@collab.net>wrote:
[...]
>> I do have a question, though, about a portion of that report:
>>
>> The good news is: after the extensive rewrite of Subversion's working
>> copy library has completed, a release branch will be created within a
>> month, and the first release candidate is expected in August 2011.
>>
>> I didn't get the sense at the hackathon that there were enough documented
>> blocker issues to delay our putting out our first release candidate for
>> another *three months*. Did I miss some critical discussion on Friday?
>> Did
>> I simply misunderstand the discussions we had earlier in the week? Are
>> there some blockers that are living in peoples' minds and *not* in the
>> tracker (aka "poor collaboration and communication")? Was the write-up
>> just
>> a mistake, and August is actually the *release* target date?
>
> I noticed that bit of prose as well, and just chalked it up to
> an overzealous PR guy.
Sorry, it's a mistake alright. The "PR guys" were rushing the PR stuff
on Friday. This bit of incongruous information apparently slipped through.
> The outcome of the hackathon was "we'll start alpha releases in June and
> branch when the blockers are gone"
We'll change that paragraph to read:
The good news is: after the extensive rewrite of Subversion's working
copy library has completed, we can expect alpha releases in June,
to be followed by the creation of a release branch, once the
remaining release blockers have been resolved.
--
Michael Diers, elego Software Solutions GmbH, http://www.elego.de
Re: "... first release candidate is expected in August 2011." Really?
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Mon, May 23, 2011 at 9:10 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Tue, May 24, 2011 at 08:02, Greg Stein <gs...@gmail.com> wrote:
>>
>> On May 23, 2011 10:21 PM, "Ivan Zhakov" <iv...@visualsvn.com> wrote:
>>>
>>> On Tue, May 24, 2011 at 01:44, Mark Phippard <ma...@gmail.com> wrote:
>>>...
>>> >
>>> > I think they should stay in 1.7.0 until such point that we make a
>>> > decision to change the defaut and branch without them. As long as we
>>> > intend for Serf to remain the default, and as I understand it that is
>>> > the intent, we should keep these items in 1.7.0.
>>> >
>>> >
>>> +1, personally I prefer switch back on neon before releasing alphas.
>>
>> The stated intent has been to try and get ra_serf in people's hands. That
>> also means putting it into the alphas.
>>
>> You've opened issues to track the showstoppers. If they are fixed, then
>> we're good.
>>
> Is it makes sense to release ra_serf in alphas if there are known
> showstopper bugs?
To answer the more general question "are we going to release alphas
with known blockers?" Yes. We'll tell people what those blockers
are, but we will still release the alphas. (The blockers are all
relatively uncommon corner cases by this point, and I believe that
applies to serf, too.)
-Hyrum
Re: "... first release candidate is expected in August 2011." Really?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, May 23, 2011 at 7:39 PM, Stefan Küng <to...@gmail.com> wrote:
> against an 1.6.x server. Mark can't reproduce that, but maybe that's
> because he's building against serf trunk and I'm building against the
> latest release tag, and I'm running the tests with an x64 build while
I added some fixes to serf in the last few weeks that have not yet
been released as I was awaiting Mark to give some more concrete
information about his setup so that I can try to reproduce what he was
seeing.
The only two issues I know of that are outstanding is that serf isn't
a big fan of the server not being available on Windows and so gets
into an infinite retry loop and the out-of-order priority bug when
retrying authorization. Other than that, I don't know of any
outstanding issues that are reproducible. -- justin
Re: "... first release candidate is expected in August 2011." Really?
Posted by Stefan Küng <to...@gmail.com>.
On Tue, May 24, 2011 at 06:37, Greg Stein <gs...@gmail.com> wrote:
> On Tue, May 24, 2011 at 00:10, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> On Tue, May 24, 2011 at 08:02, Greg Stein <gs...@gmail.com> wrote:
>>...
>>> The stated intent has been to try and get ra_serf in people's hands. That
>>> also means putting it into the alphas.
>>>
>>> You've opened issues to track the showstoppers. If they are fixed, then
>>> we're good.
>>>
>> Is it makes sense to release ra_serf in alphas if there are known
>> showstopper bugs?
>
> I've been using ra_serf for 2.5 years. I have had zero productivity
> problems. I see no reason to assume that people will have problems
> with any release based on ra_serf. You have identified some edge cases
> which we need to fix, but I don't see it as a blocker for an alpha.
I've seen quite a few hiccups with serf. Just to mention two issues
from last week:
* tried to checkout a 1.5GB working copy with serf at work. After the
first "unknown error (102)" I continued with an update of the
incomplete working copy. After the seventh "unknown error (102)" I
switched to neon: checkout went through in one go without problems.
* the benchmark tests from Mark which I run every time I update TSVN
to the latest svn trunk crash hard when running them using serf
against an 1.6.x server. Mark can't reproduce that, but maybe that's
because he's building against serf trunk and I'm building against the
latest release tag, and I'm running the tests with an x64 build while
he's running them with his 32-bit build. Maybe someone else can try
and reproduce this?
So from my point of view, serf isn't stable enough to make it the
default. And I fear that since most of you never had any issues with
it that we'll get into serious troubles once 1.7 is out with serf as
the default, because only then all the strange network/server setups
will start showing all the edge cases in serf that never were
tested...
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: "... first release candidate is expected in August 2011." Really?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, May 24, 2011 at 5:58 AM, Greg Stein <gs...@gmail.com> wrote:
> But my point still stands: if I can be productive on it, then I
> presume many others can, too. And until we get *reported* failures
> from those other people, I have little data to suggest the sky is
> falling and ra_serf should be pulled at this time.
+1. -- justin
Re: "... first release candidate is expected in August 2011." Really?
Posted by Greg Stein <gs...@gmail.com>.
On Tue, May 24, 2011 at 11:36, C. Michael Pilato <cm...@collab.net> wrote:
> On 05/24/2011 12:37 AM, Greg Stein wrote:
>...
>> I've been using ra_serf for 2.5 years. I have had zero productivity
>> problems. I see no reason to assume that people will have problems
>> with any release based on ra_serf. You have identified some edge cases
>> which we need to fix, but I don't see it as a blocker for an alpha.
>
> With respect, "it works for me" is not such a useful argument when "me" is
> probably not using ra_serf on every common platform/environment/dataset/etc.
> Surely enough folks here that you trust to not be complete idiots have
> struggled with ra_serf over the past several years to justify at least
> skepticism on this front. :-)
Sure. And until recently, nobody would cough up reproduction recipes
or file bugs. Instead, there was simply a "hand wave" that problems
existed. Not very actionable.
There are now two or three recipes that can be used to track down
issues. This is good.
But my point still stands: if I can be productive on it, then I
presume many others can, too. And until we get *reported* failures
from those other people, I have little data to suggest the sky is
falling and ra_serf should be pulled at this time.
Cheers,
-g
Re: "... first release candidate is expected in August 2011." Really?
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 05/24/2011 12:37 AM, Greg Stein wrote:
> On Tue, May 24, 2011 at 00:10, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> On Tue, May 24, 2011 at 08:02, Greg Stein <gs...@gmail.com> wrote:
>> ...
>>> The stated intent has been to try and get ra_serf in people's hands. That
>>> also means putting it into the alphas.
>>>
>>> You've opened issues to track the showstoppers. If they are fixed, then
>>> we're good.
>>>
>> Is it makes sense to release ra_serf in alphas if there are known
>> showstopper bugs?
>
> I've been using ra_serf for 2.5 years. I have had zero productivity
> problems. I see no reason to assume that people will have problems
> with any release based on ra_serf. You have identified some edge cases
> which we need to fix, but I don't see it as a blocker for an alpha.
With respect, "it works for me" is not such a useful argument when "me" is
probably not using ra_serf on every common platform/environment/dataset/etc.
Surely enough folks here that you trust to not be complete idiots have
struggled with ra_serf over the past several years to justify at least
skepticism on this front. :-)
But sure, I agree that we may go to alpha without addressing every known
major issue here.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: "... first release candidate is expected in August 2011." Really?
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Tue, May 24, 2011 at 08:37, Greg Stein <gs...@gmail.com> wrote:
> On Tue, May 24, 2011 at 00:10, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> On Tue, May 24, 2011 at 08:02, Greg Stein <gs...@gmail.com> wrote:
>>...
>>> The stated intent has been to try and get ra_serf in people's hands. That
>>> also means putting it into the alphas.
>>>
>>> You've opened issues to track the showstoppers. If they are fixed, then
>>> we're good.
>>>
>> Is it makes sense to release ra_serf in alphas if there are known
>> showstopper bugs?
>
> I've been using ra_serf for 2.5 years. I have had zero productivity
> problems. I see no reason to assume that people will have problems
> with any release based on ra_serf. You have identified some edge cases
> which we need to fix, but I don't see it as a blocker for an alpha.
>
Subversion source code tree is relatively small comparing to used by
many Subversion users. You can just try to checkout
subversion/branches folder and see memory exhaustion. Anyway I'm fine
to release ra_serf in alpha even just to prove my point of view :)
--
Ivan Zhakov
Re: "... first release candidate is expected in August 2011." Really?
Posted by Greg Stein <gs...@gmail.com>.
On Tue, May 24, 2011 at 00:10, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Tue, May 24, 2011 at 08:02, Greg Stein <gs...@gmail.com> wrote:
>...
>> The stated intent has been to try and get ra_serf in people's hands. That
>> also means putting it into the alphas.
>>
>> You've opened issues to track the showstoppers. If they are fixed, then
>> we're good.
>>
> Is it makes sense to release ra_serf in alphas if there are known
> showstopper bugs?
I've been using ra_serf for 2.5 years. I have had zero productivity
problems. I see no reason to assume that people will have problems
with any release based on ra_serf. You have identified some edge cases
which we need to fix, but I don't see it as a blocker for an alpha.
Cheers,
-g
Re: "... first release candidate is expected in August 2011." Really?
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Tue, May 24, 2011 at 08:02, Greg Stein <gs...@gmail.com> wrote:
>
> On May 23, 2011 10:21 PM, "Ivan Zhakov" <iv...@visualsvn.com> wrote:
>>
>> On Tue, May 24, 2011 at 01:44, Mark Phippard <ma...@gmail.com> wrote:
>>...
>> >
>> > I think they should stay in 1.7.0 until such point that we make a
>> > decision to change the defaut and branch without them. As long as we
>> > intend for Serf to remain the default, and as I understand it that is
>> > the intent, we should keep these items in 1.7.0.
>> >
>> >
>> +1, personally I prefer switch back on neon before releasing alphas.
>
> The stated intent has been to try and get ra_serf in people's hands. That
> also means putting it into the alphas.
>
> You've opened issues to track the showstoppers. If they are fixed, then
> we're good.
>
Is it makes sense to release ra_serf in alphas if there are known
showstopper bugs?
--
Ivan Zhakov
Re: "... first release candidate is expected in August 2011." Really?
Posted by Greg Stein <gs...@gmail.com>.
On May 23, 2011 10:21 PM, "Ivan Zhakov" <iv...@visualsvn.com> wrote:
>
> On Tue, May 24, 2011 at 01:44, Mark Phippard <ma...@gmail.com> wrote:
>...
> >
> > I think they should stay in 1.7.0 until such point that we make a
> > decision to change the defaut and branch without them. As long as we
> > intend for Serf to remain the default, and as I understand it that is
> > the intent, we should keep these items in 1.7.0.
> >
> >
> +1, personally I prefer switch back on neon before releasing alphas.
The stated intent has been to try and get ra_serf in people's hands. That
also means putting it into the alphas.
You've opened issues to track the showstoppers. If they are fixed, then
we're good.
Cheers,
-g
Re: "... first release candidate is expected in August 2011." Really?
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Tue, May 24, 2011 at 01:44, Mark Phippard <ma...@gmail.com> wrote:
> On Mon, May 23, 2011 at 5:41 PM, Greg Stein <gs...@gmail.com> wrote:
>> On Mon, May 23, 2011 at 17:03, C. Michael Pilato <cm...@collab.net> wrote:
>>> On 05/23/2011 04:27 PM, Greg Stein wrote:
>>>...
>>>> All non-serf blockers should be fixed before we branch. IOW, we get as
>>>> close to a release candidate as possible on trunk. (and if people want
>>>> to code new features, they should HIGHLY CONSIDER doing that on a
>>>> branch, for later reintegration).
>>>
>>> Should we, then, move the Serf issues to 1.7-consider in the tracker?
>>
>> If you like churning issues... sure.
>>
>> I'd kind of like them front-and-center for 1.7.0 queries. But whatevs...
>
> I think they should stay in 1.7.0 until such point that we make a
> decision to change the defaut and branch without them. As long as we
> intend for Serf to remain the default, and as I understand it that is
> the intent, we should keep these items in 1.7.0.
>
>
+1, personally I prefer switch back on neon before releasing alphas.
--
Ivan Zhakov
Re: "... first release candidate is expected in August 2011." Really?
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, May 23, 2011 at 5:41 PM, Greg Stein <gs...@gmail.com> wrote:
> On Mon, May 23, 2011 at 17:03, C. Michael Pilato <cm...@collab.net> wrote:
>> On 05/23/2011 04:27 PM, Greg Stein wrote:
>>...
>>> All non-serf blockers should be fixed before we branch. IOW, we get as
>>> close to a release candidate as possible on trunk. (and if people want
>>> to code new features, they should HIGHLY CONSIDER doing that on a
>>> branch, for later reintegration).
>>
>> Should we, then, move the Serf issues to 1.7-consider in the tracker?
>
> If you like churning issues... sure.
>
> I'd kind of like them front-and-center for 1.7.0 queries. But whatevs...
I think they should stay in 1.7.0 until such point that we make a
decision to change the defaut and branch without them. As long as we
intend for Serf to remain the default, and as I understand it that is
the intent, we should keep these items in 1.7.0.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: "... first release candidate is expected in August 2011." Really?
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 05/23/2011 05:41 PM, Greg Stein wrote:
> On Mon, May 23, 2011 at 17:03, C. Michael Pilato <cm...@collab.net> wrote:
>> On 05/23/2011 04:27 PM, Greg Stein wrote:
>> ...
>>> All non-serf blockers should be fixed before we branch. IOW, we get as
>>> close to a release candidate as possible on trunk. (and if people want
>>> to code new features, they should HIGHLY CONSIDER doing that on a
>>> branch, for later reintegration).
>>
>> Should we, then, move the Serf issues to 1.7-consider in the tracker?
>
> If you like churning issues... sure.
>
> I'd kind of like them front-and-center for 1.7.0 queries. But whatevs...
No, I asked because I rather prefer to see them in the 1.7.0 list, too.
They're a special class of non-blocker blocker. :-) I'll leave them as-as
in the tracker.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: "... first release candidate is expected in August 2011." Really?
Posted by Greg Stein <gs...@gmail.com>.
On Mon, May 23, 2011 at 17:03, C. Michael Pilato <cm...@collab.net> wrote:
> On 05/23/2011 04:27 PM, Greg Stein wrote:
>...
>> All non-serf blockers should be fixed before we branch. IOW, we get as
>> close to a release candidate as possible on trunk. (and if people want
>> to code new features, they should HIGHLY CONSIDER doing that on a
>> branch, for later reintegration).
>
> Should we, then, move the Serf issues to 1.7-consider in the tracker?
If you like churning issues... sure.
I'd kind of like them front-and-center for 1.7.0 queries. But whatevs...
Re: "... first release candidate is expected in August 2011." Really?
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 05/23/2011 04:27 PM, Greg Stein wrote:
> On Mon, May 23, 2011 at 14:51, Hyrum K Wright <hy...@hyrumwright.org> wrote:
>> On Mon, May 23, 2011 at 11:48 AM, C. Michael Pilato <cm...@collab.net>wrote:
>>
>>> On 05/23/2011 02:25 PM, Hyrum K Wright wrote:
>>>> The outcome of the hackathon was "we'll start alpha releases in June and
>>>> branch when the blockers are gone"
>>>
>>> Hrm... that's not quite what I recall. But then, I remained somewhat
>>> under-rested for the duration of the trip. :-)
>>>
>>> Our discussion of the default ra-dav implementation for 1.7.0 implied that
>>> there could be open "blocker" issues even after we branch. (Because if any
>>> of those blockers were serf-ish, that was our signal to restore ra_neon as
>>> the default.) I hate to fuss over such fine details, but I believe we owe
>>> it to ourselves to be clear on this general matter of branching.
>>
>>
>> My recollection is that we essentially said that if there are blocking
>> ra_serf issues when all the other blockers are gone, we'd flip back to
>> ra_neon for the release. (So in a sense, the ra_serf blockers aren't really
>> blockers at all.)
>
> Right.
>
> All non-serf blockers should be fixed before we branch. IOW, we get as
> close to a release candidate as possible on trunk. (and if people want
> to code new features, they should HIGHLY CONSIDER doing that on a
> branch, for later reintegration).
Should we, then, move the Serf issues to 1.7-consider in the tracker?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: "... first release candidate is expected in August 2011." Really?
Posted by Greg Stein <gs...@gmail.com>.
On Mon, May 23, 2011 at 14:51, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> On Mon, May 23, 2011 at 11:48 AM, C. Michael Pilato <cm...@collab.net>wrote:
>
>> On 05/23/2011 02:25 PM, Hyrum K Wright wrote:
>> > The outcome of the hackathon was "we'll start alpha releases in June and
>> > branch when the blockers are gone"
>>
>> Hrm... that's not quite what I recall. But then, I remained somewhat
>> under-rested for the duration of the trip. :-)
>>
>> Our discussion of the default ra-dav implementation for 1.7.0 implied that
>> there could be open "blocker" issues even after we branch. (Because if any
>> of those blockers were serf-ish, that was our signal to restore ra_neon as
>> the default.) I hate to fuss over such fine details, but I believe we owe
>> it to ourselves to be clear on this general matter of branching.
>
>
> My recollection is that we essentially said that if there are blocking
> ra_serf issues when all the other blockers are gone, we'd flip back to
> ra_neon for the release. (So in a sense, the ra_serf blockers aren't really
> blockers at all.)
Right.
All non-serf blockers should be fixed before we branch. IOW, we get as
close to a release candidate as possible on trunk. (and if people want
to code new features, they should HIGHLY CONSIDER doing that on a
branch, for later reintegration).
Cheers,
-g
Re: "... first release candidate is expected in August 2011." Really?
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Mon, May 23, 2011 at 11:48 AM, C. Michael Pilato <cm...@collab.net>wrote:
> On 05/23/2011 02:25 PM, Hyrum K Wright wrote:
> > The outcome of the hackathon was "we'll start alpha releases in June and
> > branch when the blockers are gone"
>
> Hrm... that's not quite what I recall. But then, I remained somewhat
> under-rested for the duration of the trip. :-)
>
> Our discussion of the default ra-dav implementation for 1.7.0 implied that
> there could be open "blocker" issues even after we branch. (Because if any
> of those blockers were serf-ish, that was our signal to restore ra_neon as
> the default.) I hate to fuss over such fine details, but I believe we owe
> it to ourselves to be clear on this general matter of branching.
My recollection is that we essentially said that if there are blocking
ra_serf issues when all the other blockers are gone, we'd flip back to
ra_neon for the release. (So in a sense, the ra_serf blockers aren't really
blockers at all.)
-Hyrum
Re: "... first release candidate is expected in August 2011." Really?
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 05/23/2011 02:25 PM, Hyrum K Wright wrote:
> The outcome of the hackathon was "we'll start alpha releases in June and
> branch when the blockers are gone"
Hrm... that's not quite what I recall. But then, I remained somewhat
under-rested for the duration of the trip. :-)
Our discussion of the default ra-dav implementation for 1.7.0 implied that
there could be open "blocker" issues even after we branch. (Because if any
of those blockers were serf-ish, that was our signal to restore ra_neon as
the default.) I hate to fuss over such fine details, but I believe we owe
it to ourselves to be clear on this general matter of branching.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand