Re: Squid-5 status update and RFI
Alex Rousskov <[email protected]>
| Newsgroups | gmane.comp.web.squid.devel |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected] http://lists.squid-cache.org/listinfo/squid-dev