[wp-hackers] Probably best to move tickets to 2.7 instead

[Jacob Santos]

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
> suggests.
>
> 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://lists.automattic.com/mailman/listinfo/wp-hackers
>   


-- 

Jacob Santos

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.