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/
_______________________________________________
wp-testers mailing list
[email protected]
http://lists.automattic.com/mailman/listinfo/wp-testers
