Use of "Future"
Christian Robottom Reis
kiko at async.com.br
Thu Mar 18 22:27:35 UTC 2004
On Thu, Mar 18, 2004 at 05:07:20PM -0500, David Miller wrote:
> If we move things to future, then we need to remember to go through and
> triage future bugs every so often.
Question is whether that will be done. The push for a release makes
everybody happy to go through targetted bugs and move them off (didn't
make it, sorry). This is less likely to interest people during the
normal development cycle, and I don't see it being done during release
which is normally occam's razor for planned changes.
> Lots of third-party folks looking at Bugzilla see the target milestone and
> say "oh, that'll be in 2.18" then when 2.18 comes out they're disappointed
> :) That in itself is probably the biggest reason to target as little as
Well, as I said, I think the solution to that part of the problem is
providing a strong "target" concept for future releases (2.20 could be
mod_perl and cleanups and user-facing templatization, for instance; 2.22
could be multiple database support and custom fields; 2.22 could be
multiple database support and custom fields; 2.24 could be UI
css-ification and redesign; etc). That way we both know what sort of
problems to pick up, and what should be expected to go in. Setting
reasonable (i.e. not a lot) goals for each release would avoid the
eternal "upcoming features" saga.
I think setting some policy and triaging bug milestones according to
this policy is a good idea; I would offer to help plan these targets if
people think it's a good idea.
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331
More information about the developers