Re: [squid-dev] Squid-5 status update and RFI

[Alex Rousskov]

On 12/30/19 11:22 AM, Amos Jeffries wrote:
> On 31/12/19 3:01 am, Alex Rousskov wrote:
>> On 12/30/19 4:46 AM, Amos Jeffries wrote:
>>>
>>> The v5 branch will be bumped to master HEAD
>>> commit in a few hours then the documentation update PRs for stage 2 will
>>> proceed.
>>
>> I would wait for all pending v5 changes to be committed to master before
>> pointing v5 to master's HEAD. There is no pressure to commit to master
>> anything that should not be in v5 right now.


> Problem with that plan is that most of your requested "should be in v5"
> list are new features. 

The new features are not the problem.


> We already have enough features to make v5 a release.

... but we should not release v5 without PRs that should be in v5. Doing
so would effectively grant you unchecked powers to block any change from
being released. Unchecked powers are inherently dangerous, and you are
not impartial, rational, and careful enough to allow this unnecessary risk.


> "Just one more feature" is a very slippery slope that we have been
> sliding down for most of this past year already.

A stream of new features is _not_ the reason why v5 branching time has
been sliding. Improper treatment of the already submitted changes is one
of the reasons behind that slide.


> Frequent release -> fewer feature change -> fewer new bugs -> happier
> community. The sequence is simple and well-known.

With even fewer new features, Squid would have been dead or forked long
time ago...

However, we should not even be discussing new feature frequency in this
thread context because feature frequency does not determine release
frequency. If you want to make more frequent releases, please post a
proposal. FWIW, I would be OK with much more frequent releases, even
monthly ones, if they are done right and somebody has a genuine need
that justifies such an overhead.


> Likewise our versioning policy (published since 2008):
> 
>  *10* features for a new major version.
>  Bi-Monthly stable point release.
>  Monthly beta of next version.
>  Daily alpha of development work.

I do not understand why you are citing a policy that nobody follows. Are
you implying that you will start following this policy soon? FWIW, I am
still OK with the above (bad) policy as long as it is consistently
applied and there is protection from you forever blocking the features
you do not like.

I think that branching is an important enough event to deserve
consistent rules and, if those rules are vague or effectively
non-existent, consensus.


> PS. I see you do have a sense of humour. "There is no pressure to commit
> to master". Thanks for the laugh :-). Though its NYE not April 1st.

I actually said "There is no pressure to commit to master anything that
should not be in v5 right now", and that fact was not a joke.

Alex.
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Squid-5 status update and RFI

[Amos Jeffries]

On 31/12/19 3:01 am, Alex Rousskov wrote:
> On 12/30/19 4:46 AM, Amos Jeffries wrote:
>>
>> The v5 branch will be bumped to master HEAD
>> commit in a few hours then the documentation update PRs for stage 2 will
>> proceed.
> 
> I would wait for all pending v5 changes to be committed to master before
> pointing v5 to master's HEAD. There is no pressure to commit to master
> anything that should not be in v5 right now.


Problem with that plan is that most of your requested "should be in v5"
list are new features. We already have enough features to make v5 a release.

"Just one more feature" is a very slippery slope that we have been
sliding down for most of this past year already. It is not a new one
either; you should well remember the long and painful release process
for v3.0, v3.2 and v4 when we waited on or accepted late feature
additions. It _always_ results in much longer and slower testing phases.


Truth is, most of what we *really* need in v5 is fixes for the bugs in
all those feature creep additions that got into master-to-be-v5 since my
previous arbitrary 'Feb 2019' branching plan. Were it not for those v5
would be stable or already fixing the bugs we have yet to find in those
initial features.

Frequent release -> fewer feature change -> fewer new bugs -> happier
community. The sequence is simple and well-known.


Likewise our versioning policy (published since 2008):

 *10* features for a new major version.
 Bi-Monthly stable point release.
 Monthly beta of next version.
 Daily alpha of development work.


PS. I see you do have a sense of humour. "There is no pressure to commit
to master". Thanks for the laugh :-). Though its NYE not April 1st.

Amos
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Squid-5 status update and RFI

[Alex Rousskov]

On 12/30/19 4:46 AM, Amos Jeffries wrote:
> 
> The v5 branch will be bumped to master HEAD
> commit in a few hours then the documentation update PRs for stage 2 will
> proceed.

I would wait for all pending v5 changes to be committed to master before
pointing v5 to master's HEAD. There is no pressure to commit to master
anything that should not be in v5 right now.

Alex.


> On 5/09/19 10:37 pm, Amos Jeffries wrote:
>> Hi all,
>>
>> A request today for backporting large changes to v4 has prompted me to
>> take a look at where Squid-5 is in terms of being ready for branching.
>>
>> As of a few weeks ago it passed the criteria for feature count.
>>
>> There are 3 new major or higher bugs right now, 23 new ones in total
>> already known. Which is small enough to accept as a starting point.
>>
>>
> 
>>
>>
>>
>> So as a tentative plan, lets say 2 weeks away:
>>
>> 27 Sep 2019
>>
>> For the branching Squid-5 and a v5.0.1 Beta release shortly after.
>>
>> Note: PR under review by the branching date will be ported should they
>> complete that review and be merged during the v5 beta series.
>>
>>
>> To get a late-PR exemption from the "no new features" or "no UI changes"
>> policy please reply to this message with a brief (one-liner) description
>> of the project and an ETA for PR review submission.
>>
>>
> 
> 
> On 12/09/19, 2:59 pm, Alex Rousskov wrote:
>>
>> FWIW, below is a list of Factory projects that should be submitted for
>> the official review soon. It is difficult to give a reliable ETA for
>> individual project submission because it depends, in part, on the
>> activity surrounding already submitted PRs, which is largely outside our
>> control. Said that,
>>
>> * The projects closer to the top of the list have completed primary
>> development and testing cycles; they are being massaged for the official
>> submission. 10-15 days?
>>
>> * The projects in the middle of the list may need another internal
>> polishing round or two, but no major rewrites are expected.
>>
>> * The projects at the very end of the list still need serious
>> development work which may take 3-5 weeks or longer.
>>
> 
> After eliding the PRs already submitted and/or merged we currently have
> this list of Factory projects without any PR submitted:
> 
>>
>> SQUID-392: Maintain cache metadata when updating headers
>> SQUID-291: Support slow cache_peer_access ACLs
>> SQUID-448: Critical collapsed forwarding regressions
>> SQUID-216: log the number of request sending attempts
>> SQUID-340: Detail TLS client handshake errors
>> SQUID-357: Detail TLS server handshake errors
>> SQUID-425: Bug 4906: src ACL mismatches when access logging TCP probes
>> SQUID-464: %>connection_id logformat code
>>
> 
> Of these only 216, 291 and 464 appear to relate the Squid API. But not
> in a way that would prevent the beta series starting.
> 
> I will try to keep an eye out for these in the backports, but they still
> have to be submitted and approved just like anything else.
> 
> 
> The PRs already submitted have been marked to distinguish which will get
> my attention during v5 beta cycle with the plan being to backport unless
> there is a major blocker found that prevents it being merged.
> 
> 
> Amos
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
> 

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Squid-5 status update and RFI

[Amos Jeffries]

Summary:

 


 Stage 1 is now complete. The v5 branch will be bumped to master HEAD
commit in a few hours then the documentation update PRs for stage 2 will
proceed.




On 5/09/19 10:37 pm, Amos Jeffries wrote:
> Hi all,
>
> A request today for backporting large changes to v4 has prompted me to
> take a look at where Squid-5 is in terms of being ready for branching.
>
> As of a few weeks ago it passed the criteria for feature count.
>
> There are 3 new major or higher bugs right now, 23 new ones in total
> already known. Which is small enough to accept as a starting point.
>
>

>
>
>
> So as a tentative plan, lets say 2 weeks away:
>
> 27 Sep 2019
>
> For the branching Squid-5 and a v5.0.1 Beta release shortly after.
>
> Note: PR under review by the branching date will be ported should they
> complete that review and be merged during the v5 beta series.
>
>
> To get a late-PR exemption from the "no new features" or "no UI changes"
> policy please reply to this message with a brief (one-liner) description
> of the project and an ETA for PR review submission.
>
>


On 12/09/19, 2:59 pm, Alex Rousskov wrote:
>
> FWIW, below is a list of Factory projects that should be submitted for
> the official review soon. It is difficult to give a reliable ETA for
> individual project submission because it depends, in part, on the
> activity surrounding already submitted PRs, which is largely outside our
> control. Said that,
>
> * The projects closer to the top of the list have completed primary
> development and testing cycles; they are being massaged for the official
> submission. 10-15 days?
>
> * The projects in the middle of the list may need another internal
> polishing round or two, but no major rewrites are expected.
>
> * The projects at the very end of the list still need serious
> development work which may take 3-5 weeks or longer.
>

After eliding the PRs already submitted and/or merged we currently have
this list of Factory projects without any PR submitted:

>
> SQUID-392: Maintain cache metadata when updating headers
> SQUID-291: Support slow cache_peer_access ACLs
> SQUID-448: Critical collapsed forwarding regressions
> SQUID-216: log the number of request sending attempts
> SQUID-340: Detail TLS client handshake errors
> SQUID-357: Detail TLS server handshake errors
> SQUID-425: Bug 4906: src ACL mismatches when access logging TCP probes
> SQUID-464: %>connection_id logformat code
>

Of these only 216, 291 and 464 appear to relate the Squid API. But not
in a way that would prevent the beta series starting.

I will try to keep an eye out for these in the backports, but they still
have to be submitted and approved just like anything else.


The PRs already submitted have been marked to distinguish which will get
my attention during v5 beta cycle with the plan being to backport unless
there is a major blocker found that prevents it being merged.


Amos
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] Squid-5 status update and RFI

[Amos Jeffries]

Hi all,

A request today for backporting large changes to v4 has prompted me to
take a look at where Squid-5 is in terms of being ready for branching.

As of a few weeks ago it passed the criteria for feature count.

There are 3 new major or higher bugs right now, 23 new ones in total
already known. Which is small enough to accept as a starting point.

 




So as a tentative plan, lets say 2 weeks away:

27 Sep 2019

For the branching Squid-5 and a v5.0.1 Beta release shortly after.

Note: PR under review by the branching date will be ported should they
complete that review and be merged during the v5 beta series.


To get a late-PR exemption from the "no new features" or "no UI changes"
policy please reply to this message with a brief (one-liner) description
of the project and an ETA for PR review submission.


Amos

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Squid-5 status update

[eliezer]

First:
https://www.ietf.org/archive/id/draft-rousskov-icap-trailers-01.txt

Looks very nice.
Second, Le t me know when the beta will be ready and packages will be up and 
running for testing purposes.
I am still testing 4.5 but it seems like working as expected with all the new 
refresh_pattern removal of overrides.

Eliezer


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il


-Original Message-
From: squid-dev  On Behalf Of Amos 
Jeffries
Sent: Sunday, January 27, 2019 10:41
To: Squid Developers 
Subject: [squid-dev] Squid-5 status update

Hi all,

 So being January and fielding questions about when v5 will be released
I have taken a look at the state of trunk/HEAD/master code to see
whether or not there is enough change to be worth a new Squid series.

Right now things are looking close but not quite enough.


The details I am looking at right now:

 * 8 new functionality features. Either specifically named features
  that have their own release notes section, or a bunch of related
  UI setting changes that add together to be noteworthy.

  see <https://wiki.squid-cache.org/Squid-5> for the list as of today.

 Ideally what I look for is an arbitrary 10 features. So this is close
enough, but also has room to wait for more.


 * approx. 30k LOC unique to master/v5

Historically there have been around 100k per year. v4 was an oddity with
having to wait for compiler support and some major late-added features.

Higher LOC change tends to mean we have made a lot of progress on the
code polishing and features added actually are significant. If we let it
get too high before beta the expected bug count goes up likewise and
beta testing takes a lot longer.
 If the v3 past is a good indicator of future bug finds, then this 30k
LOC would indicate 8-12 months of beta ahead already.


 * the LOC changes appear to be roughly evenly split in this past two
years between v5 changes, v4 fixes.

This is quite a bit higher than previous cycles and a good indicator
that we are not really ready to stop working on those fixes and move on
to testing stability of the new v5 code.


 * ~6 weeks to accumulate changes sufficient to pass the arbitrary
watermark for new packaging to be worthwhile.

Ideally that series would be stable enough that it takes regularly 8
week turnarounds before focus could be switched to a new series.


These last two are the main reasons I have now to delay starting v5
beta. Next look in a few months to see if/how things have changed.

That said we are getting close, so please start considering what
features you want to finish off to get included.


Amos

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] Squid-5 status update

[Amos Jeffries]

Hi all,

 So being January and fielding questions about when v5 will be released
I have taken a look at the state of trunk/HEAD/master code to see
whether or not there is enough change to be worth a new Squid series.

Right now things are looking close but not quite enough.


The details I am looking at right now:

 * 8 new functionality features. Either specifically named features
  that have their own release notes section, or a bunch of related
  UI setting changes that add together to be noteworthy.

  see  for the list as of today.

 Ideally what I look for is an arbitrary 10 features. So this is close
enough, but also has room to wait for more.


 * approx. 30k LOC unique to master/v5

Historically there have been around 100k per year. v4 was an oddity with
having to wait for compiler support and some major late-added features.

Higher LOC change tends to mean we have made a lot of progress on the
code polishing and features added actually are significant. If we let it
get too high before beta the expected bug count goes up likewise and
beta testing takes a lot longer.
 If the v3 past is a good indicator of future bug finds, then this 30k
LOC would indicate 8-12 months of beta ahead already.


 * the LOC changes appear to be roughly evenly split in this past two
years between v5 changes, v4 fixes.

This is quite a bit higher than previous cycles and a good indicator
that we are not really ready to stop working on those fixes and move on
to testing stability of the new v5 code.


 * ~6 weeks to accumulate changes sufficient to pass the arbitrary
watermark for new packaging to be worthwhile.

Ideally that series would be stable enough that it takes regularly 8
week turnarounds before focus could be switched to a new series.


These last two are the main reasons I have now to delay starting v5
beta. Next look in a few months to see if/how things have changed.

That said we are getting close, so please start considering what
features you want to finish off to get included.


Amos

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev