On Tue, 2007-10-02 at 19:16 +1300, Amos Jeffries wrote:
> > We already have "a TODO list" draft for 3.1:
> > http://www.squid-cache.org/bugs/buglist.cgi?query_format=advanced&product=Squid&version=3.0&target_milestone=---&target_milestone=3.1&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIED
> >
> > This is not exact, complete, or comprehensive (e.g., I assume IPv6
> > support will be in v3.1 but ESI may not be), but can be a good starting
> > point for the discussion.
>
> There is also this one with a few more items:
> http://wiki.squid-cache.org/Squid-3.1#head-533b554b1cc28966bbe9409b58a19bb1fe2ee7f1
If I disagree with the order of the wiki items, want to add new items,
or delete old ones, how should I edit that wiki page? I think the format
of the page should be changed from the current ordered list of items to
an unordered set of items under consideration. This would make it easier
to add or comment on ideas without a conflict until the final decision
must be made.
Moreover, before talking about specific items, I believe we should first
decide on what the criteria for inclusion or prioritization should be. I
will use the term "feature" loosely; any change, including general code
improvement is a "feature". I suggest to have two groups of v3.1
features:
1) "Prime candidates": Documented features that have at least one
developer or sponsor behind them, ready to commit time to fully develop
(i.e., write, test, document, commit, and provide initial support) the
proposed feature within v3.1 release timeline.
2) "Wish List": Other features somebody wants to see implemented. It
would still be nice to have a "shepherd" for each feature. Features from
this group can be propagated to the Prime set once they gain a little
bit of documentation and a dedicated developer.
For example, if I want to rewrite events and callbacks to add native
support for exceptions-safe asynchronous calls, I have to promise to
actively develop that feature. I have to spend at least a few minutes
documenting my idea. Only then I can add it to the Prime set.
Needless to say, situation may change and the developer may not be able
to fulfill his promises. The feature will then be downgraded to the Wish
List or removed.
While it would be nice to implement most important features first, we
need to be realistic about developer availability and focus on those
features that are likely to be implemented.
Finally, how about setting a deadline for v3.1 feature-freeze? How about
January 31st, 2008?
Thank you,
Alex.
Received on Tue Oct 02 2007 - 08:19:53 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Oct 30 2007 - 13:00:03 MDT