Jacob wrote:
Charles E. Frees-Melvin wrote:
For the QA side we could do a system like for the track hunt. We
should try
at least one to see if it helps. Maybe the day before a "Feature lock
before
release"
trac-hunted - fixed at patched
trac-hunted-confirmed - where a second party confirms it before being
sent
to trac
trac-hunted-irrelivent - and then close it
trac-hunted-sendnext - and send to next release
I think that your idea is great, except I would drop the "trac-" since
well, it is redundant. Also, it might be better to just use these
instead.
"trac-hunted" -> "has-patch commit"
"trac-hunted-confirmed" -> "confirmed"
"trac-hunted-irrelevant" -> close as invalid and leave a message.
Remember to clear milestone. If you are unsure, then use
"reporter-feedback" or "2nd-opinion"
"trac-hunted-sendnext" -> "sendnext"
However, "sendnext" means nothing to the core devs and there is no
report for automatically getting that information. They would have to
manually search for it. I also used "hunted-sendnext" myself, so I
will go back and change that. I'm also unsure if "confirmed" means
anything.
Actually, (not being rude here) but I really don't see this happening at
all. I don't think they'll go with this whole "idea". IMHO, "they"
should just do up another Developer version quick... Slap ALL of the
commits into it, then we testers test it all out. Report back on
whatever, decide on what can/should be committed into the Trunk version.
That way, you're not only testing just TRUNK, but you're testing all the
patches that were committed originally, as well as committed things from
months and months ago too. You'd also have a heads-up on how those
things would work, where it would be best placed in "version wise" and
so forth.
As is now, most of the Testers use Trunk on live sites. (Which of course
isn't always the best thing to do, we know there are consequences to it
too.) But, to have the chance / ability to Test it ALL (all committed
patches/fixes/etc) out on a testbed site, would / could possibly help it
the long run- maybe.
Then testers could just report back; have DB errors on the following
ticket commits, patches were resubmitted on such tickets, then once
those patches/fixes get applied, report back again if said patches fixed
errors/problems. Then bang, all those tickets that have been lingering
for months and or whatever, get a chance to get tested / fixed / etc in
one swoop. However, it has it's downfalls though too.
It would take some time, but heck, we testers usually just spend alot of
time waiting here for something to test anyway. My as well give the
testers something to test, and it helps/benefits everyone / everything
all the way around... Think about it though, if you made another
Developer version... testers can constantly test whatever is submitted
for patches (wise), BEFORE it even makes it into Trunk. There'd be a
head-start on (what is the result of this "fix", what needs fixed for
it, etc etc) everything then.
_______________________________________________
wp-testers mailing list
[email protected]
http://lists.automattic.com/mailman/listinfo/wp-testers
