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/07/04 16:26:54 UTC
Third (and probably last) alpha coming later this week
Seeing Philip's commit of the libtool fixes makes me want to roll
another alpha before we branch and start the RC train. We American
revolutionaries are busy celebrating our independence today, so expect
tarballs Tuesday or Wednesday, with the hope of releasing them by
week's end.
Let me know if there are any objections.
-Hyrum
RE: Third (and probably last) alpha coming later this week
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
> Sent: maandag 4 juli 2011 19:34
> To: Philip Martin
> Cc: Bert Huijben; Subversion Development
> Subject: Re: Third (and probably last) alpha coming later this week
>
> On Mon, Jul 4, 2011 at 10:37 AM, Philip Martin
> <ph...@wandisco.com> wrote:
> > "Bert Huijben" <be...@qqmail.nl> writes:
> >
> >> The issue Ivan Zhakov is looking at (r1141845, r1142065 and related)
> >> potentially breaks all current serf (and in some cases neon) clients
against
> >> a HTTPv2 server.
> >>
> >> (And without that patch serf always retrieves full-texts over HTTPv2)
> >>
> >> Please don't call out almost-RCs before we got that worked out :)
> >
> > Is there an issue describing the problem?
>
> Not that I can see. As per our project-wide consensus regarding
> branching and releasing and release candidates and such, nothing in
> the issue tracker means that there isn't a blocking issue.
I leave it to Ivan to create issues for this as he asked me *not* to fix
this issue on trunk because he needed more time to look for different ways
to resolve this problem.
(In one of his mails he also noted that there is a related problem with
neon, where I don't know the details or how to reproduce).
What I do know about this issue is:
In HTTPv2 for updates serf sends separate requests for every file/directory
that needs to be updated. As part of this request a header is sent which
indicates: Instead of the full text you can also send me an svndiff based on
this file at this revision.
In HTTPv1 we used to provide the dav-cached path for this (which works ok),
but in HTTPv2 we generate the path and revision based on local knowledge of
the working copy. But currently we still forget to look at switched paths,
so we often send some completely unrelated base-delta url, while we apply
the diff to the real base.
A bug in mod_dav_svn, which was fixed in r1141845 made us ignore the
base-delta header for all HTTPv2 requests, so the server always transferred
full-texts. So we didn't see the original problem at all, but fixing this in
mod_dav_svn uncovered the other problem.
With my knowledge on how the reporting and update phase of the update work I
was able to fix this problem. (This problem was actually found years ago but
never resolved: see the commented block in serf about guessing urls). I
committed the fix in r1142065, but only inside a #if 0 block.
Ivan then decided to revert his fix in mod_dav_svn as a temporary measure
until he had more time to look into this.
But now we have a compatibility problem: If we fix mod_dav_svn all serf
clients using HTTPv2 that don't have the currently still commented fix will
break.
So the reason that I asked to hold the 'almost-rc' a bit is that I don't
want it to be an 'almost-rc' that will certainly break against a final 1.7.0
which has a fixed mod_dav_svn.
But +1 for releasing the almost RC if we apply my fix first and (optionally)
fix mod_dav_svn.
Bert
RE: Third (and probably last) alpha coming later this week
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: dinsdag 5 juli 2011 20:15
> To: Mark Phippard
> Cc: Hyrum K Wright; dev@subversion.apache.org
> Subject: Re: Third (and probably last) alpha coming later this week
>
> On Tue, Jul 5, 2011 at 09:44, Mark Phippard <ma...@gmail.com> wrote:
> > On Tue, Jul 5, 2011 at 8:51 AM, Hyrum K Wright <hy...@hyrumwright.org>
> wrote:
> >
> >>> We want to ship the best product possible. This mailing list is
defined to
> >>> be our decision-making focus. It seems incorrect to disregard a
reported
> >>> problem simply because (for whatever reason) an issue is not in the
> tracker.
> >>
> >> I don't claim that we should disregard the problem. I *do* claim that
> >> we should more widely publicize blocking issues so that everybody can
> >> be aware of them.
>
> Done. It was posted to this list.
>
> >> The greater point was that this seems to be something that various
> >> people have kicking around in their heads. We agreed in Berlin (and
> >> then discussed on this list) to use the issue tracker to record
> >> blocking issues. I really don't want to be in the position of rolling
> >> a possible release candidate, only to find out we're got all these
> >> hidden issues that aren't being tracked in the agreed-upon public
> >> manner.
>
> Certainly, but you're not the only one to decide what will be a
> release candidate. As we've seen in this thread, hidden issues will be
> raised.
>
> Is it as efficient as it could be? No. But it *works*.
>
> > I am with Hyrum on this one. If there are blockers people need to
> > create issues for them or at least formally raise them on dev@ so that
> > someone else can create an issue. We should not be waiting for Hyrum
> > to announce the plans to make a release to suddenly reveal there are
> > blockers.
>
> It happens. So we deal with it and move on. This issue *has been*
> formally raised here on dev@, in this very thread. Some people just
> don't like to take time away from their coding to file an issue. I
> don't like to do it, and I suspect the same for Ivan. That is just the
> way people work.
>
> An issue has been filed now, for all the issue-oriented people. Done.
> Process works.
>
> My issue was with Hyrum's statement:
>
> "Not that I can see. As per our project-wide consensus regarding
> branching and releasing and release candidates and such, nothing in
> the issue tracker means that there isn't a blocking issue."
>
> To me, that reads as a casual disregard to Bert requesting that we do
> NOT roll a release candidate until the issue is fixed.
Note that I now enabled my fix in r1143089, which removes/resolves my main
concern on why we shouldn't release a new alpha 'now'.
I would like to see the deltas working though... But I don't understand
Ivan's concern/alternate solution.
(I just hope he is not working on a new crawl that gets the same information
from the WC again in additional db queries, as what we started the update
request with and now used by my patch)
Bert
Re: Third (and probably last) alpha coming later this week
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Tue, Jul 5, 2011 at 1:14 PM, Greg Stein <gs...@gmail.com> wrote:
>
> On Tue, Jul 5, 2011 at 09:44, Mark Phippard <ma...@gmail.com> wrote:
> > On Tue, Jul 5, 2011 at 8:51 AM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> >
> >>> We want to ship the best product possible. This mailing list is defined to
> >>> be our decision-making focus. It seems incorrect to disregard a reported
> >>> problem simply because (for whatever reason) an issue is not in the tracker.
> >>
> >> I don't claim that we should disregard the problem. I *do* claim that
> >> we should more widely publicize blocking issues so that everybody can
> >> be aware of them.
>
> Done. It was posted to this list.
Sure, but that's not where people are looking for blocking issues. As
agreed upon by the community, the place to look for those issues is
the issue tracker. Someone looking to answer the question "what's
blocking 1.7.0?" shouldn't be expected to troll through the last 2
months of mailing list archives and come up their own list.
> >> The greater point was that this seems to be something that various
> >> people have kicking around in their heads. We agreed in Berlin (and
> >> then discussed on this list) to use the issue tracker to record
> >> blocking issues. I really don't want to be in the position of rolling
> >> a possible release candidate, only to find out we're got all these
> >> hidden issues that aren't being tracked in the agreed-upon public
> >> manner.
>
> Certainly, but you're not the only one to decide what will be a
> release candidate. As we've seen in this thread, hidden issues will be
> raised.
Certainly agree. One of the main purposes of throwing out dates and
deadlines is to try and smoke out all of these phantom issues from the
woodwork. I just kinda wish it didn't take a "hey, we're getting
close to an RC" mail before folks brought that stuff up.
> Is it as efficient as it could be? No. But it *works*.
>
> > I am with Hyrum on this one. If there are blockers people need to
> > create issues for them or at least formally raise them on dev@ so that
> > someone else can create an issue. We should not be waiting for Hyrum
> > to announce the plans to make a release to suddenly reveal there are
> > blockers.
>
> It happens. So we deal with it and move on. This issue *has been*
> formally raised here on dev@, in this very thread. Some people just
> don't like to take time away from their coding to file an issue. I
> don't like to do it, and I suspect the same for Ivan. That is just the
> way people work.
>
> An issue has been filed now, for all the issue-oriented people. Done.
> Process works.
Sure, but I think the greater point of this discussion is not to
address this particular instance, but rather to help increase
awareness for people the next time. I don't want to have this
discussion tomorrow or next week or next month.
> My issue was with Hyrum's statement:
>
> "Not that I can see. As per our project-wide consensus regarding
> branching and releasing and release candidates and such, nothing in
> the issue tracker means that there isn't a blocking issue."
>
> To me, that reads as a casual disregard to Bert requesting that we do
> NOT roll a release candidate until the issue is fixed.
I'm sorry, that's not what I meant (though reading my statement, I can
see how it could be taken that way). I certainly want as many issues
addressed before the RCs as possible: I just would like those issues
identified and documented in the heretofore agreed-upon manner (if
they can't be fixed expeditiously, of course).
fwiw, I think we're not really that far apart ideologically. We both
want to ship great software. For whatever reason, I'm the guy that
volunteered with helping to shepherd the release. Having as much
information as possible makes that role much less frustrating.
Unfortunately my mind-reading-fu is still lacking, so I like to use
the issue tracker.
-Hyrum
PS - I've probably spent way to much time on this as it is, and as the
marginal utility of my mails in this thread is rapidly decreasing,
I'll stop now. :)
Re: Third (and probably last) alpha coming later this week
Posted by Philip Martin <ph...@wandisco.com>.
Greg Stein <gs...@gmail.com> writes:
> An issue has been filed now, for all the issue-oriented people. Done.
> Process works.
No, it has not. I filed issue 3946, but that's not the problem that
Bert first mentioned. I suppose I could put Bert's second email into an
issue, but I don't really understand the problem or why we don't simply
revert r1141995 and say the problem is solved.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Third (and probably last) alpha coming later this week
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Jul 5, 2011 at 09:44, Mark Phippard <ma...@gmail.com> wrote:
> On Tue, Jul 5, 2011 at 8:51 AM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
>
>>> We want to ship the best product possible. This mailing list is defined to
>>> be our decision-making focus. It seems incorrect to disregard a reported
>>> problem simply because (for whatever reason) an issue is not in the tracker.
>>
>> I don't claim that we should disregard the problem. I *do* claim that
>> we should more widely publicize blocking issues so that everybody can
>> be aware of them.
Done. It was posted to this list.
>> The greater point was that this seems to be something that various
>> people have kicking around in their heads. We agreed in Berlin (and
>> then discussed on this list) to use the issue tracker to record
>> blocking issues. I really don't want to be in the position of rolling
>> a possible release candidate, only to find out we're got all these
>> hidden issues that aren't being tracked in the agreed-upon public
>> manner.
Certainly, but you're not the only one to decide what will be a
release candidate. As we've seen in this thread, hidden issues will be
raised.
Is it as efficient as it could be? No. But it *works*.
> I am with Hyrum on this one. If there are blockers people need to
> create issues for them or at least formally raise them on dev@ so that
> someone else can create an issue. We should not be waiting for Hyrum
> to announce the plans to make a release to suddenly reveal there are
> blockers.
It happens. So we deal with it and move on. This issue *has been*
formally raised here on dev@, in this very thread. Some people just
don't like to take time away from their coding to file an issue. I
don't like to do it, and I suspect the same for Ivan. That is just the
way people work.
An issue has been filed now, for all the issue-oriented people. Done.
Process works.
My issue was with Hyrum's statement:
"Not that I can see. As per our project-wide consensus regarding
branching and releasing and release candidates and such, nothing in
the issue tracker means that there isn't a blocking issue."
To me, that reads as a casual disregard to Bert requesting that we do
NOT roll a release candidate until the issue is fixed.
>...
Cheers,
-g
Re: Third (and probably last) alpha coming later this week
Posted by Philip Martin <ph...@wandisco.com>.
Mark Phippard <ma...@gmail.com> writes:
> On Tue, Jul 5, 2011 at 9:52 AM, Philip Martin
> <ph...@wandisco.com> wrote:
>>
>> If I enable both Bert's code and Ivan's reverted change the regression
>> tests PASS.
>
> Yes, Bert said as much. The issue was that Ivan asked him not to
> commit until he examined the problem in more detail.
It wasn't clear to me, Ivan's change was reverted before Bert's commit.
> BTW, Bert, Ivan indicated the Neon problem happens if you add the
> directive "SVNAllowBulkUpdates off" to the server. This makes Neon
> behave like Serf in terms of doing a GET for each file.
I've raised issue 3946, but it's not clear that it is related.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Third (and probably last) alpha coming later this week
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/05/2011 09:57 AM, Mark Phippard wrote:
> BTW, Bert, Ivan indicated the Neon problem happens if you add the
> directive "SVNAllowBulkUpdates off" to the server. This makes Neon
> behave like Serf in terms of doing a GET for each file.
... and I looks like Philip filed an issue for exactly that recently:
http://subversion.tigris.org/issues/show_bug.cgi?id=3946
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Third (and probably last) alpha coming later this week
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Jul 5, 2011 at 9:52 AM, Philip Martin
<ph...@wandisco.com> wrote:
> Mark Phippard <ma...@gmail.com> writes:
>
>> Anyway, from what I see this still has not been entered in the issue
>> tracker. Also, if Bert seems to have a fix for the problem why are we
>> not just putting that in place? I do not get the "waiting for Ivan"
>> part. Is there anything blocking Ivan from making the fix a
>> better/different way if he finds the time?
>
> If I enable both Bert's code and Ivan's reverted change the regression
> tests PASS.
Yes, Bert said as much. The issue was that Ivan asked him not to
commit until he examined the problem in more detail.
BTW, Bert, Ivan indicated the Neon problem happens if you add the
directive "SVNAllowBulkUpdates off" to the server. This makes Neon
behave like Serf in terms of doing a GET for each file.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Third (and probably last) alpha coming later this week
Posted by Philip Martin <ph...@wandisco.com>.
Mark Phippard <ma...@gmail.com> writes:
> Anyway, from what I see this still has not been entered in the issue
> tracker. Also, if Bert seems to have a fix for the problem why are we
> not just putting that in place? I do not get the "waiting for Ivan"
> part. Is there anything blocking Ivan from making the fix a
> better/different way if he finds the time?
If I enable both Bert's code and Ivan's reverted change the regression
tests PASS.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Third (and probably last) alpha coming later this week
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Jul 5, 2011 at 8:51 AM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
>> We want to ship the best product possible. This mailing list is defined to
>> be our decision-making focus. It seems incorrect to disregard a reported
>> problem simply because (for whatever reason) an issue is not in the tracker.
>
> I don't claim that we should disregard the problem. I *do* claim that
> we should more widely publicize blocking issues so that everybody can
> be aware of them.
>
> The greater point was that this seems to be something that various
> people have kicking around in their heads. We agreed in Berlin (and
> then discussed on this list) to use the issue tracker to record
> blocking issues. I really don't want to be in the position of rolling
> a possible release candidate, only to find out we're got all these
> hidden issues that aren't being tracked in the agreed-upon public
> manner.
I am with Hyrum on this one. If there are blockers people need to
create issues for them or at least formally raise them on dev@ so that
someone else can create an issue. We should not be waiting for Hyrum
to announce the plans to make a release to suddenly reveal there are
blockers.
I do not think Hyrum was being flippant, I think he was basically
saying "how am I supposed to know there are blockers if you wait to
tell me when I announce plans for the release?"
Anyway, from what I see this still has not been entered in the issue
tracker. Also, if Bert seems to have a fix for the problem why are we
not just putting that in place? I do not get the "waiting for Ivan"
part. Is there anything blocking Ivan from making the fix a
better/different way if he finds the time?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Third (and probably last) alpha coming later this week
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Mon, Jul 4, 2011 at 10:07 PM, Greg Stein <gs...@gmail.com> wrote:
>
> On Jul 4, 2011 10:18 PM, "Greg Stein" <gs...@gmail.com> wrote:
>>
>>
>> On Jul 4, 2011 1:34 PM, "Hyrum K Wright" <hy...@hyrumwright.org> wrote:
>> >
>> > On Mon, Jul 4, 2011 at 10:37 AM, Philip Martin
>> > <ph...@wandisco.com> wrote:
>> > > "Bert Huijben" <be...@qqmail.nl> writes:
>> > >
>> > >> The issue Ivan Zhakov is looking at (r1141845, r1142065 and related)
>> > >> potentially breaks all current serf (and in some cases neon) clients
>> > >> against
>> > >> a HTTPv2 server.
>> > >>
>> > >> (And without that patch serf always retrieves full-texts over HTTPv2)
>> > >>
>> > >> Please don't call out almost-RCs before we got that worked out :)
>> > >
>> > > Is there an issue describing the problem?
>> >
>> > Not that I can see. As per our project-wide consensus regarding
>> > branching and releasing and release candidates and such, nothing in
>> > the issue tracker means that there isn't a blocking issue.
>>
>> Don't be pedantic.
>>
>> -g
>
> That was probably a bit too flip, but the point is that we want to have
> problems *reported*. Saying it doesn't exist, despite one of our devs
> *clearly* stating that it *does* ... is just being ridiculous.
Agreed. I wasn't trying to be flippant (but probably came off that way).
> We want to ship the best product possible. This mailing list is defined to
> be our decision-making focus. It seems incorrect to disregard a reported
> problem simply because (for whatever reason) an issue is not in the tracker.
I don't claim that we should disregard the problem. I *do* claim that
we should more widely publicize blocking issues so that everybody can
be aware of them.
The greater point was that this seems to be something that various
people have kicking around in their heads. We agreed in Berlin (and
then discussed on this list) to use the issue tracker to record
blocking issues. I really don't want to be in the position of rolling
a possible release candidate, only to find out we're got all these
hidden issues that aren't being tracked in the agreed-upon public
manner.
-Hyrum
Re: Third (and probably last) alpha coming later this week
Posted by Greg Stein <gs...@gmail.com>.
On Jul 4, 2011 10:18 PM, "Greg Stein" <gs...@gmail.com> wrote:
>
>
> On Jul 4, 2011 1:34 PM, "Hyrum K Wright" <hy...@hyrumwright.org> wrote:
> >
> > On Mon, Jul 4, 2011 at 10:37 AM, Philip Martin
> > <ph...@wandisco.com> wrote:
> > > "Bert Huijben" <be...@qqmail.nl> writes:
> > >
> > >> The issue Ivan Zhakov is looking at (r1141845, r1142065 and related)
> > >> potentially breaks all current serf (and in some cases neon) clients
against
> > >> a HTTPv2 server.
> > >>
> > >> (And without that patch serf always retrieves full-texts over HTTPv2)
> > >>
> > >> Please don't call out almost-RCs before we got that worked out :)
> > >
> > > Is there an issue describing the problem?
> >
> > Not that I can see. As per our project-wide consensus regarding
> > branching and releasing and release candidates and such, nothing in
> > the issue tracker means that there isn't a blocking issue.
>
> Don't be pedantic.
>
> -g
That was probably a bit too flip, but the point is that we want to have
problems *reported*. Saying it doesn't exist, despite one of our devs
*clearly* stating that it *does* ... is just being ridiculous.
We want to ship the best product possible. This mailing list is defined to
be our decision-making focus. It seems incorrect to disregard a reported
problem simply because (for whatever reason) an issue is not in the tracker.
-g
Re: Third (and probably last) alpha coming later this week
Posted by Greg Stein <gs...@gmail.com>.
On Jul 4, 2011 1:34 PM, "Hyrum K Wright" <hy...@hyrumwright.org> wrote:
>
> On Mon, Jul 4, 2011 at 10:37 AM, Philip Martin
> <ph...@wandisco.com> wrote:
> > "Bert Huijben" <be...@qqmail.nl> writes:
> >
> >> The issue Ivan Zhakov is looking at (r1141845, r1142065 and related)
> >> potentially breaks all current serf (and in some cases neon) clients
against
> >> a HTTPv2 server.
> >>
> >> (And without that patch serf always retrieves full-texts over HTTPv2)
> >>
> >> Please don't call out almost-RCs before we got that worked out :)
> >
> > Is there an issue describing the problem?
>
> Not that I can see. As per our project-wide consensus regarding
> branching and releasing and release candidates and such, nothing in
> the issue tracker means that there isn't a blocking issue.
Don't be pedantic.
-g
Re: Third (and probably last) alpha coming later this week
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Mon, Jul 4, 2011 at 10:37 AM, Philip Martin
<ph...@wandisco.com> wrote:
> "Bert Huijben" <be...@qqmail.nl> writes:
>
>> The issue Ivan Zhakov is looking at (r1141845, r1142065 and related)
>> potentially breaks all current serf (and in some cases neon) clients against
>> a HTTPv2 server.
>>
>> (And without that patch serf always retrieves full-texts over HTTPv2)
>>
>> Please don't call out almost-RCs before we got that worked out :)
>
> Is there an issue describing the problem?
Not that I can see. As per our project-wide consensus regarding
branching and releasing and release candidates and such, nothing in
the issue tracker means that there isn't a blocking issue.
-Hyrum
Re: Third (and probably last) alpha coming later this week
Posted by Philip Martin <ph...@wandisco.com>.
"Bert Huijben" <be...@qqmail.nl> writes:
> The issue Ivan Zhakov is looking at (r1141845, r1142065 and related)
> potentially breaks all current serf (and in some cases neon) clients against
> a HTTPv2 server.
>
> (And without that patch serf always retrieves full-texts over HTTPv2)
>
> Please don't call out almost-RCs before we got that worked out :)
Is there an issue describing the problem?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Third (and probably last) alpha coming later this week
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Mon, Jul 4, 2011 at 18:49, Bert Huijben <be...@qqmail.nl> wrote:
>> -----Original Message-----
>> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
>> Sent: maandag 4 juli 2011 16:27
>> To: Subversion Development
>> Subject: Third (and probably last) alpha coming later this week
>>
>> Seeing Philip's commit of the libtool fixes makes me want to roll
>> another alpha before we branch and start the RC train. We American
>> revolutionaries are busy celebrating our independence today, so expect
>> tarballs Tuesday or Wednesday, with the hope of releasing them by
>> week's end.
>>
>> Let me know if there are any objections.
>
> The issue Ivan Zhakov is looking at (r1141845, r1142065 and related)
> potentially breaks all current serf (and in some cases neon) clients against
> a HTTPv2 server.
>
> (And without that patch serf always retrieves full-texts over HTTPv2)
>
> Please don't call out almost-RCs before we got that worked out :)
>
Sorry, I was really busy with my day job.
I've fixed the problem in r1143860: I removed all the complexity and
made behavior as in ra_neon.
--
Ivan Zhakov
RE: Third (and probably last) alpha coming later this week
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
> Sent: maandag 4 juli 2011 16:27
> To: Subversion Development
> Subject: Third (and probably last) alpha coming later this week
>
> Seeing Philip's commit of the libtool fixes makes me want to roll
> another alpha before we branch and start the RC train. We American
> revolutionaries are busy celebrating our independence today, so expect
> tarballs Tuesday or Wednesday, with the hope of releasing them by
> week's end.
>
> Let me know if there are any objections.
The issue Ivan Zhakov is looking at (r1141845, r1142065 and related)
potentially breaks all current serf (and in some cases neon) clients against
a HTTPv2 server.
(And without that patch serf always retrieves full-texts over HTTPv2)
Please don't call out almost-RCs before we got that worked out :)
Bert
>
> -Hyrum
Re: Third (and probably last) alpha coming later this week
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Hyrum K Wright wrote on Mon, Jul 04, 2011 at 09:26:54 -0500:
> Seeing Philip's commit of the libtool fixes makes me want to roll
> another alpha before we branch and start the RC train. We American
> revolutionaries are busy celebrating our independence today, so expect
> tarballs Tuesday or Wednesday, with the hope of releasing them by
> week's end.
>
> Let me know if there are any objections.
>
Not an objection to alpha3, but:
Issue #3944, concerning refactoring the way FSFS f5 stores revision
properties, should be solved (one way or another prior to RC'ing.
To my recollection the issue is currently at the "Gather consensus for
which suggestion to implement" phase, with the last mails having been
exchanged late last week.
> -Hyrum
Re: Third (and probably last) alpha coming later this week
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Mon, Jul 4, 2011 at 9:26 AM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> Seeing Philip's commit of the libtool fixes makes me want to roll
> another alpha before we branch and start the RC train. We American
> revolutionaries are busy celebrating our independence today, so expect
> tarballs Tuesday or Wednesday, with the hope of releasing them by
> week's end.
>
> Let me know if there are any objections.
It sounds like whatever concerns there were have been addressed, so
I'll roll alpha3 this afternoon.
-Hyrum