On 6/30/20 6:59 PM, Amos Jeffries wrote: > I have been asked a few weeks ago about what the "goal for Squid-6" is > going to be.
What does it mean to claim that "Squid v6 goal is X"? Does "reaching X" become a precondition for the v6 release? Something else? Our RoadMap page talks of _features_ (with specific properties) driving release process, not goals. I assume the two concepts are different, but I do not know what the term "goal" really means here. Does the paragraph quoted below represent a complete answer to my question or just a partial description of what we are trying to define here? > It just gives people some rough direction to > consider when struggling with selecting of new work to start. IMHO, Squid work selection should be primarily driven by developer-specific factors that usually have little to do with Project-declared release goals, whatever they are. Until the meaning of "release goal" is clear to me, I can only comment on the validity of the proposed goals from a general "What is a good goal in a software development project?" point of view. Please do not misinterpret my responses below as an agreement (or disagreement) regarding adding those items as v6 release goals. As of now, I see no reason to have release goals other than the already established practice of tracking TODO features on the RoadMap. I am very open to changing my position, but that change would require developing a shared definition of the term "release goal". Hence my question above... > The last few version we have focused on C++11 optimizations and code > upgrades. I do not think this summary is meaningful or accurate, but it is a matter of opinion/perspective. > 0) the ongoing project to clarify OS support and testing. I would support that project if you replace "clarify" with "define" or something similarly meaningful/measurable. > 1) remove features that have been deprecated since Squid-3 days. This goal needs polishing: All such features? Some features we agree on (e.g., the two you listed explicitly -- WAIS and ICP)? What determines that feature F has been deprecated "since v3 days"? > 2) proposing some next features to be removed ASAP, possibly removing > them this release. > - send-announce removal > - SMB_LM helper removal This needs to be rephrased as a meaningful goal. Perhaps you meant "Removal of the following features: ..."? If yes, we need to make a decision for each feature. It is not clear (to me) whether the two specific examples have something in common here. > 3) drop (all?) bitrotten code Even with "all" in place, this is not a valid goal due to the vagueness of the term "bitrotten code". > 4) statistic addition to measure feature use. To improve admin ability > to answer our "are you using this feature" requests. I think Squid usage reporting would be a very nice feature (at virtually any granularity) _if_ we have enough admin support to enable such reporting by default. Perhaps we should ask on squid-users first? HTH, Alex. _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
