[wp-hackers] Re: Unanswered tickets
spencerp1 at gmail.com
Fri Dec 21 06:03:34 GMT 2007
Woah there! Now that's a book! I'll have to respond to this tomorrow
when I have more time..
> Well, I should have made clear that some of the submitters probably
> wandered off after there was no traction after a certain period of
> time, "Hello, anyone home?" I think with a recent example, once it was
> made clear that the reporter had to clarify, the reporter came back
> and did so, which lead to a resolution. With a year past, I'm not sure
> the original reporter might still be interested in WordPress. I know
> in a year time, whatever ticket I have created and not committed will
> probably have no involvement from me until I once again came back to
> spencerp wrote:
>>> At least that is how I would feel if I had my own open source
>>> project, but I'm pretty sure that with 500+ tickets, limited time,
>>> and various degrees of I-really-don't-care-for-that-ticket that
>>> project might fall into the same state.
>> That's basically why I suggested this earlier:
>> Sure, it's a task in itself... Means they'd have to hack/edit Trac
>> software itself to do what needs to be done. But, at least the
>> tickets wouldn't constantly be bumping from version to version or
>> whatever else.. The tickets would SIT THERE in the "TICKET BIN",
>> assigned to their respected Milestone Bins. They wouldn't need to go
>> any where UNLESS the ones with "SVN Commit Rights" MOVES them to the
>> Milestone it's intended for...
>> So when looking at the RoadMap page there... there wouldn't be 500+
>> tickets sitting under Milestone 2.4... There'd only be what was sent
>> there from bin.. that the SVN Committers moved there from "Ticket
>> Bin". This would help alot too, for like.. setting a certain amount
>> of tickets to be applied to that Milestone for under a certain
>> Release Date schedule. So you don't have to constantly bump tickets
>> from like: 2.4 to 2.5 then those same tickets get bumped from 2.5 to
>> 2.6 or whatever...
>> All those (uncertain with what to do with) type tickets can remain in
>> the Ticket Bin, out of the way, and be there to be able to decide on
>> it's destination later. And if need be, and they think it would be
>> best in another version bin.. they could just move it from 2.4
>> milestone bin to the next one...
> Well, in that, I mean part of the reason there are 500+ tickets is
> because there isn't a lot of love, which until recently a lot of love
> that should have went was not. It is a tough decision to close a
> ticket, because it leaves you to wonder if anyone else will show up to
> resubmit the bug. Some of the bugs might be edge cases, which may
> never show up until a unit test or acceptance test is written that
> finds it again (I keep forgetting the guy that writes those). You take
> the risk closing out old bugs and alienating the bug poster, "WTF?
> That bug still causes me nightmares!"
> I disagreed with your proposal, and I don't know if I replied to say
> that. The good news is that the next version of Trac (0.11) is going
> to have a workflow that might allow for a little of what you say, in
> that you can create more statuses, such as "confirmed" status in that
> someone tested and confirmed. Really, I think your proposal would
> create more work and more red tape to go through to get bugs
> committed. The current rule/suggestion that if a ticket doesn't have a
> patch, then it belongs in the next milestone is a good one. If you
> want to show a ticket some love and write a patch, then those that do
> can bring that patch down the trunk milestone.
> This would keep the trunk milestone with a few tickets that have
> patches and therefore should be debated and committed and all others
> will exist in the next milestone. However, I'm not sure how far the
> core devs are going to take this. It would be much better if someone
> would adopt a ticket and supply a patch for it.
> I suppose my point has always been that there is only so much the core
> devs can do and should do. I don't believe they can provide a patch
> for every 500+ bug, it is a community effort, but really if the
> community doesn't care for a bug then that bug will remain until it is
> superseded or obsoleted. In the best case, every week would be like
> this last week and WordPress milestones wouldn't contain such a large
> amount of old bugs.
> However, I think that most popular open source projects might wish for
> having only 500-600 open bugs. I'm not sure how I feel about closing
> out bugs just because there is no current love for them. Someone might
> come along later and the bug will peak their curiosity and that bug
> will exist no longer in open state. Basically in some ways, bug hunts
> are good to refresh peoples memories of bugs that once knew and
> reclaim old friends, "Dude, I so totally remember that bug, whatever
> happened? Let me take care of you."
>>> I don't particularly agree with your assertion that the more complex
>>> tickets should be committed before the simple ones. You can most
>>> likely knock out 10 simple tickets in the time it would take to
>>> write and argue the points for a more complex one. Take the cookie
>>> authentication change. It took weeks to finish that and it is still
>>> open for opinion/discussion, which I think is a good thing. I think
>>> security is extremely important, but you can't hold back everything.
>> Unless I used the wrong wording, I basically said it would be better
>> to knock out simpler tickets when "you" can... =P Especially when
>> waiting around on whether the Admin Redesign is coming in or not...
>> While the "wait" is there for the BIG stuff... they my as well knock
>> out or squash the simple stuff quick... I wrote this in previous
>> email: "And what better to knock out first, than the simpler
>> tickets... Especially with an Admin redesign coming soon, you can
>> only touch so much tickets without interfering with it.. I know I
>> pointed out SOME tickets that were pending on the Admin redesign...
>> but they were also planned for 2.4 though, as well as the Admin
>> redesign stuff... "
> Hmm, I had thought that was what you meant, but didn't quite know how
> to word my assertion. Please excuse my earlier statement.
> May I suggest, since you don't know that much of PHP, that you become
> involve with automated testing. You really only need to know the
> PHPUnit methods (there is a great resource phpunit.de and you can
> copy/refactor the current tests to your needs), in that way you learn
> PHP, and seriously help the community. I'm probably going to jump onto
> the codex and write up a tutorial on helping the automated tests test
> writing since that needs to have as many people/testers as possible.
> At the very basic, regression testing involves var_dump()-ing
> functions with test input (both correct and *incorrect*) and using
> var_dump() on the output. Once you figured out what the function dumps
> upon given input, you can then use the PHPUnit $this->assert*()
> methods to make sure that whatever input is given is continued to be
> given, else a regression bug occurred.
> That is probably the quickest and easiest automated testing. It
> doesn't drill down into the core of the functions and test all the
> possible branches the function can take, but still, if the regression
> test failed, then somewhere out there, there is a
> function/plugin/theme that is going to break based on the change.
> The best thing would be for more unit tests, since it would prove the
> low level testing of a bug and possible fixes for correcting that bug.
> The best part about regression/acceptance tests is that they can be
> written by non-developers and most of the articles I've read recommend
> that they aren't written by developers.
>  With unit testing or any kind of testing you are purposefully
> trying to break the software. If I enter "-1" instead of a positive
> number, will I break the functionality? In that, you want to write
> unit/functional/acceptance tests with both correct and incorrect input
> and still expect correct output or some fallback value which states
> that you need to enter correct input (acceptable response, meaning the
> function was aware that incorrect input was passed and had checks to
> insure that it would not continue). However, I don't think I've taken
> my own advice since I've tested mostly correct input instead of the
> latter in most cases because well, with regressions, you aren't really
> trying to break the function, just trying to see what it returns. Most
> of my tests would fall in to the regression testing with the plugin in
> line with unit testing.
More information about the wp-hackers