Just realized this was sent privately *g*
---------- Forwarded message ---------- From: Afuna <[EMAIL PROTECTED]> Date: Mon, Sep 1, 2008 at 12:12 PM Subject: Re: [DW Discuss] Hooking up developers with testers (was: Bugzilla flag for early testing? (before a patch is commited)) To: Mark Smith <[EMAIL PROTECTED]> > Alternately, we could rename this to needs-verification. So the idea is: > > 1) feature is requested > 2) needs-spec? = spec is designed > 3) needs-design? = design is made based on spec > 4) needs-patch? = both of the above are ready (or not needed), coder GO > 5) needs-testing? = new proposed step for someone who wants external > testing (optional?) > 6) needs-review? = ready to review > 7) needs-commit? = ready to commit > 8) needs-verification? = is committed, and someone should verify the > behavior on stage (this is like needs-testing but later?) > 9) needs-merge? = all's good, let's merge this for the next live release > > Wow, that's a lot of steps. Too many? Let's optimize. How can we > make sure this process is NOT overwhelming for everybody? It does seem like a lot of steps, but I think it can be summarized into a couple of bigger chunks: 1) Feature request - request is made; someone decides it should be implemented 2) Design/Architecture/Planning - needs-spec?, needs-design? - What is the major difference between needs-spec and needs-design? I was under the impression that needs-design was for the interface, but now I think that needs-spec is what needs to be done, and needs-design is how you should go about doing it. If that is the case, would need-design usually be done by the person creating the patch? 3) Implementation - need-patch? 4) Quality Control/Committing - needs-testing?, to open up a specific patch to external testers who will likely be focusing on behavior, interaction; needs-review? is more of a code-based review; needs-commit? after the review has been completed successfully, to signal a roving committer to look at the reviewed patch 5) Beta-testing - needs-verification? on the staging server, possibly applied at the same time as any other patches? Basically, test how everything works together, make sure it doesn't break when interacting with other changes...; needs-merge? beta-testing turned up nothing. The changes in staging can be pushed It's still the same process underneath, but hopefully splitting it up into major sections, with multiple flags for some, will make it less intimidating. Some of the specific flags don't look to be used right now, but would definitely be useful once the developer/commiter/reviewer pool gets larger; some of the flags are also optional, depending on the patch. However, I think that the major divisions above are necessary for almost all patches. >>> I think that could work, but I worry that without any way to notify >>> interested parties explicitly, the patch could just sit there and be >>> ignored. >> >> True, but that's also true of the current needs-testing. > > There should be a list of "here, if you're interested in $x, use this > Bugzilla query and bookmark it" sort of things. I have a few right > now, one is "review?" and it shows all OPEN bugs with needs-review? on > an attachment. That would be useful. I have a list of all open unassigned requests, as well as all specced unassigned requests, so I can go quickly over what no one is working on, and pick something up. Hmm. For now I've set up a page of the Bugzilla searches I've found useful: http://dreamwidth.cometheapocalypse.com/notes/Bugzilla_Searches. Hopefully someone else can use that/add to that! > We've talked about having a dw-dev or something. I'm still leaning > towards "not enough traffic to warrant a separate list". Although I > guess there are 280-ish people on dw-discuss... > > If anybody has any strong opinions about separating out development > chatter, feel free to speak up! After sitting on it for a while, I've come to agree that there's not enough traffic at this point to warrant a separate list. I'm worried about splitting up information to the point where everyone has to sign up to a thousand lists in order to compile all the information they need! As a compromise, how about encouraging the use of a [test], or [call for testing] or [dev] in the subject line, so that people who aren't interested can skip over it quickly, and people who are interested can zoom in on it quickly? And if anyone feels strongly about separating out dev stuff, do speak up, yes! _______________________________________________ dw-discuss mailing list [email protected] http://lists.dwscoalition.org/cgi-bin/mailman/listinfo/dw-discuss
