Re: v3.1 TODO and deadline

> 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.
>

My view of these RoadMap lists/pages is almost exactly that. They are the
lists of items to which we the developers have committed to seeing through
to stable use. There are the TODO files, bugzilla, and the WishList pages
for anything that we can't commit time to yet.

Of course there will always be cases like for example the Comms-Loop,
Adrian added it to the list as the first requirement months ago. But now
finds himself without time, that only means the list is outdated and that
item as you say needs downgrading in the next update.

>
> Finally, how about setting a deadline for v3.1 feature-freeze? How about
> January 31st, 2008?
>

Seems to me we don't have enough info for this one. And won't really until
2.x is closed and the user base start yelling for certain features before
they upgrade.

Amos
Received on Tue Oct 02 2007 - 16:59:03 MDT