Alex Rousskov wrote:
On Fri, 2008-09-26 at 13:35 +1200, Amos Jeffries wrote:
On Thu, 2008-09-25 at 13:43 -0600, Alex Rousskov wrote:
I can probably fix it myself, but it would help a lot if somebody
could
document (briefly!) the overall purpose of deferred reads and the
exact
purposes of these
On Fri, 2008-09-26 at 13:35 +1200, Amos Jeffries wrote:
> > On Thu, 2008-09-25 at 13:43 -0600, Alex Rousskov wrote:
> >>
> >> I can probably fix it myself, but it would help a lot if somebody
> >> could
> >> document (briefly!) the overall purpose of deferred reads and the
> >> exact
> >> purposes
> On Thu, 2008-09-25 at 13:43 -0600, Alex Rousskov wrote:
>>
>> I can probably fix it myself, but it would help a lot if somebody
>> could
>> document (briefly!) the overall purpose of deferred reads and the
>> exact
>> purposes of these two nearly identical methods (one brief description
>> for ea
> On Thu, 2008-09-25 at 22:40 +0200, Henrik Nordstrom wrote:
>
>> My vote:
>>
>> 1. Finish any pending major restucturing/reorganisations/reformmatting
>> first. For example if the code is to be restyled before 3.1 is "old and
>> mature" then it must be done before 3.1 is branched. Such changes is
> On tor, 2008-09-25 at 12:57 -0600, Alex Rousskov wrote:
>
>> Understood. What do you think is better:
>>
>> A) Branch and commit waiting stuff to trunk now. Deal with a large
>> volume of complicated commit traffic between the 3.1 branch and trunk.
>>
>> B) Branch and commit waiting stuff later.
On Thu, 2008-09-25 at 17:42 -0600, Alex Rousskov wrote:
> Is the order in which reads are "done" or "kicked" important? Does it
> have to be FIFO?
FIFO was the behaviour of the code before I refactored into a manager
object; I suspect FIFO prevents starvation of individual fds, so it
shouldn't b
On Fri, 2008-09-26 at 09:24 +1000, Robert Collins wrote:
> On Thu, 2008-09-25 at 13:43 -0600, Alex Rousskov wrote:
> >
> > I can probably fix it myself, but it would help a lot if somebody
> > could
> > document (briefly!) the overall purpose of deferred reads and the
> > exact
> > purposes of the
On Thu, 2008-09-25 at 22:40 +0200, Henrik Nordstrom wrote:
> My vote:
>
> 1. Finish any pending major restucturing/reorganisations/reformmatting
> first. For example if the code is to be restyled before 3.1 is "old and
> mature" then it must be done before 3.1 is branched. Such changes is a
> maj
On Thu, 2008-09-25 at 13:43 -0600, Alex Rousskov wrote:
>
> I can probably fix it myself, but it would help a lot if somebody
> could
> document (briefly!) the overall purpose of deferred reads and the
> exact
> purposes of these two nearly identical methods (one brief description
> for each, plea
On Thu, 2008-09-25 at 22:53 +0200, Henrik Nordstrom wrote:
> On tor, 2008-09-25 at 13:32 -0600, Alex Rousskov wrote:
>
> > If we use RC label for selected/last 4-digit releases, then we will not
> > have the above problems. If a 4-digit release proves stable, we post
> > 3.1.1 (an exact copy of th
On tor, 2008-09-25 at 13:32 -0600, Alex Rousskov wrote:
> If we use RC label for selected/last 4-digit releases, then we will not
> have the above problems. If a 4-digit release proves stable, we post
> 3.1.1 (an exact copy of the last successful 4-digit release, except for
> the version number) a
On tor, 2008-09-25 at 12:57 -0600, Alex Rousskov wrote:
> Understood. What do you think is better:
>
> A) Branch and commit waiting stuff to trunk now. Deal with a large
> volume of complicated commit traffic between the 3.1 branch and trunk.
>
> B) Branch and commit waiting stuff later. Focus o
On tor, 2008-09-25 at 12:40 -0600, Alex Rousskov wrote:
> Understood. Well, if we branch now, I think you will not have cycles to
> work on the above for at least a month, because of the back/forward
> porting overhead, _especially_ if the trunk becomes open again.
trunk being open is not that bi
On Thu, 2008-09-25 at 13:50 -0600, Alex Rousskov wrote:
> On Thu, 2008-09-25 at 21:34 +0200, Henrik Nordstrom wrote:
>
> > Which is the time where 3.1.2 is labelled a RC. Tarball rolled, but not
> > yet on the FTP server or announced on squid-announce, and labelled as an
> > release candidate on t
On Thu, 2008-09-25 at 21:34 +0200, Henrik Nordstrom wrote:
> Which is the time where 3.1.2 is labelled a RC. Tarball rolled, but not
> yet on the FTP server or announced on squid-announce, and labelled as an
> release candidate on the web server.
>
> Before that there is also the nightly snapshot
On Thu, 2008-09-25 at 11:32 -0600, Alex Rousskov wrote:
> On Thu, 2008-09-25 at 14:08 +0800, Adrian Chadd wrote:
> > 2008/9/25 Alex Rousskov <[EMAIL PROTECTED]>:
> >
> > > The DescriptorSet class has O(1) complexity for search, insertion,
> > > and deletion. It uses about 2*sizeof(int)*MaxFD bytes
On tor, 2008-09-25 at 08:40 -0600, Alex Rousskov wrote:
> I do not want the meaningful words like "RC" or "STABLE" to be in the
> version string. And I want a way to release many times with a specific
> version (not an automated snapshot) before the branch is marked as
> stable.
Same here, but I
On tor, 2008-09-25 at 08:11 -0600, Alex Rousskov wrote:
> This is a different issue, but I do not think that limiting access is a
> good idea until the branch becomes stable. When 3.1 is branched (which
> you want to happen soon), there will be a lot of cleanup work still
> going on. I see no reaso
On Thu, 2008-09-25 at 21:12 +0200, Henrik Nordstrom wrote:
> On tor, 2008-09-25 at 23:36 +1200, Amos Jeffries wrote:
> > Hmm, so rolling DEVEL + PRE + RC into one version called a.b.0.N
> > Well, I'm a little doubtful but can't argue against that yet.
>
> No, not quite.
>
> There is no point of D
On tor, 2008-09-25 at 23:36 +1200, Amos Jeffries wrote:
> Hmm, so rolling DEVEL + PRE + RC into one version called a.b.0.N
> Well, I'm a little doubtful but can't argue against that yet.
No, not quite.
There is no point of DEVEL releases in the current form of the
development cycle. So we skip th
On Fri, 2008-09-26 at 05:28 +1200, Amos Jeffries wrote:
> The merge queues need to be maintained manually. With this branch there
> are going to be three to process and the more committers, the harder it
> gets to sync them. Thats ignoring Henriks 2.x queues as well for the
> cross-port feature
On Fri, 2008-09-26 at 05:45 +1200, Amos Jeffries wrote:
> Alex Rousskov wrote:
> > On Thu, 2008-09-25 at 22:41 +1200, Amos Jeffries wrote:
> >
> >> Like they are confusing trunk stabilization with branch stabilization.
> >
> > FWIW, my stabilization expectations are based on your intent to branch
Alex Rousskov wrote:
On Thu, 2008-09-25 at 22:41 +1200, Amos Jeffries wrote:
Like they are confusing trunk stabilization with branch stabilization.
FWIW, my stabilization expectations are based on your intent to branch
3.1 soon. I know that it will take at a few releases to get 3.1 to a
stabl
On Thu, 2008-09-25 at 14:08 +0800, Adrian Chadd wrote:
> 2008/9/25 Alex Rousskov <[EMAIL PROTECTED]>:
>
> > This revision resurrects 1 check/sec limit, but hopefully with fewer
> > bugs. In my limited tests, CPU usage seems to be back to normal.
>
> Woo, thanks!
Committed.
> > The DescriptorSet
Alex Rousskov wrote:
On Thu, 2008-09-25 at 17:49 +1200, Amos Jeffries wrote:
So how do we tell users to try something between 3.1.0 and 3.1.1? Refer
to some specific daily snapshot? Kinkie+ scheme would use numbered beta
releases: 3.1.0.1, 3.1.0.2, etc.
I think numbered releases are better than
On Thu, 2008-09-25 at 17:49 +1200, Amos Jeffries wrote:
> >
> > So how do we tell users to try something between 3.1.0 and 3.1.1? Refer
> > to some specific daily snapshot? Kinkie+ scheme would use numbered beta
> > releases: 3.1.0.1, 3.1.0.2, etc.
> >
> > I think numbered releases are better than
On Thu, 2008-09-25 at 23:36 +1200, Amos Jeffries wrote:
> Hmm, so rolling DEVEL + PRE + RC into one version called a.b.0.N
> Well, I'm a little doubtful but can't argue against that yet.
The progression from DEVELs to PREs to RCs reflects (or should reflect)
the change in one parameter -- code st
On Thu, 2008-09-25 at 22:41 +1200, Amos Jeffries wrote:
> Like they are confusing trunk stabilization with branch stabilization.
FWIW, my stabilization expectations are based on your intent to branch
3.1 soon. I know that it will take at a few releases to get 3.1 to a
stable point from where the
On Thu, 2008-09-25 at 22:41 +1200, Amos Jeffries wrote:
> Henrik Nordstrom wrote:
> > On tor, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote:
> >
> >> So we have
> >>> 1. Branch when trunk is considered a suitable startingpoint for getting
> >>> to stable, and tag a x.y.0 release at the branchpoi
#2468.
Also, I'm still chasing a bug that's been affecting for much of the
2.7 series; it shows as very deeply nested contexts in cache.log,
coupled with a blow-out in the size of the AIO queue. It's better but
still present in STABLE4, and 2464 makes it better (hence my comment
there), b
Henrik Nordstrom wrote:
On tor, 2008-09-25 at 22:41 +1200, Amos Jeffries wrote:
So I should simply say 'X is how we are doing it'? I think not.
Kinkie has somehow convinced Alex of a different way of numbering then
simply omitting the word 'STABLE', I'm pondering it but need a good
reason to
2.7.STABLE5 is being planned for release, and if you know any relevant
patches or important bugs in bugzilla or otherwise please speak up now.
What's collected so far can be seen in the changesets. Not much, but one
rather critical one.. (2464)
http://www.squid-cache.org/Versions/v2/2.7/changeset
On tor, 2008-09-25 at 22:41 +1200, Amos Jeffries wrote:
> So I should simply say 'X is how we are doing it'? I think not.
> Kinkie has somehow convinced Alex of a different way of numbering then
> simply omitting the word 'STABLE', I'm pondering it but need a good
> reason to agree.
No, it's si
Henrik Nordstrom wrote:
On tor, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote:
So we have
1. Branch when trunk is considered a suitable startingpoint for getting
to stable, and tag a x.y.0 release at the branchpoint (or at least set
this version in configure.in).
2a. Release X.Y.0.1 when re
On tor, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote:
> So we have
> >
> > 1. Branch when trunk is considered a suitable startingpoint for getting
> > to stable, and tag a x.y.0 release at the branchpoint (or at least set
> > this version in configure.in).
> >
> > 2a. Release X.Y.0.1 when ready
35 matches
Mail list logo
