[wp-hackers] Probably best to move tickets to 2.7 instead
wordpress at santosj.name
Mon Mar 10 00:24:25 GMT 2008
That seems to be a good solution, but I remember a similar one that was
also suggested and nothing has come of it yet or may never will.
I think the standard is that if a ticket has a patch, it is slated for
the (trunk) release, whatever it may be. If the patch does not have a
patch, then it is moved to the next release. However, this usually only
happens during the feature freeze when it is decided what tickets will
be seriously slated for the current release.
The effort is mostly dependent on the community and the core commit
team. With any open source project, community members make patches for
tickets that they feel like creating patches for. The current standard
would work best and does currently, but mostly, I can't see nor do I
want to see that many tickets pushed to the next release filling up my
mailbox with sends to the next release.
I will say that with each feature added, it adds that many more bugs,
and as the cycle continues so too will the increase of bugs. It would be
nice if Test Driven Development were practiced, but I am not one that
has the power to force anything.
If you don't know what TDD is, then I highly suggest you look into it.
It is a whole lot of fun! It also helps fix issues before they come up,
which as a developer who always tried to pinpoint problems *after*, TDD
is a god send. There is also Behavior Driven Development (BDD), which
also seems really sexy. I can't wait until PHPUnit 4.0 comes out! Please
note that BDD is available in the latest PHPUnit 3.2.x branch. Might
require the library developed in part by Padraic Brady and Travis(? I
think it is Travis Snoozy (misspelled last name), and I could be wrong
as to who the second person is).
Jared Bangs wrote:
>> Jacob Santos wrote:
>>> Is that good or would it be just plain terrible to move that many
>>> tickets out of 2.6 and put them into 2.7? 2.6 is most likely going to
>>> have 700+ open tickets. That will be a lot of fun.
> My opinion, for what it's worth, is that pushing the milestone out to 2.7 on
> these tickets would only be perpetuating (or delaying) the problem.
> As I see it, the "problem" is that there are tons of tickets with a
> milestone set to whatever the next release happens to be at that time. This
> usually leads to some degree of confusion, and at least one post on this
> list (and elsewhere) shortly before release time to the effect of "OMG there
> are still N... open tickets for the next release!"
> My suggestion would be a more conservative use of the "milestone" field, in
> which the value is only set when the fix (or whatever) for a particular
> ticket is actually planned to be released in the version that the milestone
> For the default tickets which don't have a *true* version target (yet), I
> would suggest either leaving / setting the milestone field to blank, or
> creating pseudo-milestones to indicate "future release", etc.
> I think this practice (if adhered to) might produce the desired result: a
> more manageable and realistic list of tickets that are actually being
> targeted for a given release.
> - Jared
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
http://www.santosj.name - blog
http://funcdoc.wordpress.com - WordPress Documentation Blog/Guide Licensed under GPLv2
Also known as darkdragon and santosj on WP trac.
More information about the wp-hackers