[wp-testers] WordPress 2.0.6 Beta 1

[Mark Jaquith]

On Dec 8, 2006, at 2:03 PM, Brian Layman wrote:

> Ticket #3415 Update "no wp-config.php" help link - The page this error
> linked to no longer existed on WordPress.Org.  The link has been  
> fixed.
> Ticket #3390 Better get_page_uri - This is mainly an optimization  
> for pages
> that display complete page heirarchies / navigation menus.  The DB is
> accessed once rather than many times.
>
> Aren't they both things that we would want to have in 2.0.6?   
> Especially
> 3390 as WP 2.0 is now part of the (what was it?) Debian distro?  I  
> don't see
> any other ticket tying this issue back to 2.0.6/

#3415 was closed as duplicate by the person who submitted it  
(Viper007Bond).  I think he rolled it into another patch.  The  
problem of moving Codex targets might be one that is best solved at  
the .htaccess level

Matt, how about redirecting the old requests to the appropriate Codex  
URL?  That way it only has to change in one place, instead of tens of  
thousands of WordPress blogs.  Who's to say it won't change again?

> May I ask how did you determine this range  
> "&rev=4620&stop_rev=4470".  Did
> you have a reference to this somewhere or is this just something  
> you knew
> based upon familiarity?  (I'll figure out, later, what "Stop on  
> copy" does
> unless you want to explain that quickly too.)

I looked for the 2.0.5 version bump commit, and started with the  
next /branches/2.0/ commit, and then I went until the latest / 
branches/2.0/ commit.   Don't know what "stop on copy" does exactly.

> I'm used to now working in an environment where no code change is made
> without being tied to a ticket.  It seems that is a bad assumption for
> WordPress.  Is this statement true: "The Trac Ticket report will  
> not fully
> describe the feature set for each new release.  To get a complete  
> feature
> set, you have to review the description and content of each patch  
> applied to
> that release's branch.  There is no summary report of all of the  
> changes and
> why they occurred."?

As an outsider who was recently granted commit access, I can  
sympathize.  Commits without tickets (unless they're insignificant,  
whitespace-only, etc) leave a very geeky and hard to describe trail  
for people following along from home.  I've been trying to force  
myself to create Trac tickets, even for stuff I'm 100% sure I'm going  
to commit.  This gives us the mental "attaboy" of saying "hey, this  
issue was brought up, and it was solved," and it creates a nice  
record of what changed and why, in retrospect.  I've also taken to  
letting the tickets sit up there with a patch for a day or two.  That  
gives people time to +1 or -1 it.  Sometimes their -1s are things I  
didn't anticipate, so they save me the embarrassment and save the  
community the frustration of having to fix subpar code.

Your statement is correct because we don't create tickets 100% of the  
time.  Some of that is acceptable, say for security issues where you  
don't want to broadcast the issues before the new version is out, but  
I'd definitely like to see the number of non-trivial non-security  
related commits without tickets go down.  Feel free to call me on it,  
if you catch me becoming lazy.

Even if the tickets are created after the fact, they're helpful, as  
they create a point for objections or improvements to the code to  
gather, and they create that helpful record of what changed and why.

> Anyway, thanks for your time.

No prob.

--
Mark Jaquith
http://txfx.net/