[wp-testers] Trunk

[spencerp]

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.