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

2019-12-30 Thread 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

2019-12-30 Thread 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

2019-12-30 Thread 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

2019-12-30 Thread 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