[wp-testers] WordPress 2.0.6 Beta 1
mark.wordpress at txfx.net
Sat Dec 9 08:11:50 GMT 2006
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
> 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?
> 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
> 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.
More information about the wp-testers