I don't like it. The developer is reponsible for testing what he commits. Period. Anything that implies otherwise should be banned IMO. -Vincent On Dec 5, 2007, at 2:54 PM, Sergiu Dumitriu wrote:
No replies yet...
On Oct 11, 2007 5:33 PM, Sergiu Dumitriu <[email protected]> wrote:
Hi,
We should reintroduce the Resolved state in the issue workflow, and it should work like this:
- When closing an issue, it will go in the Resolved state, which means that somebody provided a fix and it is committed in the repository. - Somebody else can test (manually) that the issue is indeed fixed/implemented, and it works as expected. If no, then it goes back to Open, otherwise it goes to Verified. - When all the needed tests and documentation are written, the issue can be closed completely, entering the Closed state.
This should improve the way we write code, meaning that we don't just commit some quick fix code which nobody sees, and claim that the issue is fixed. Right now we're trying to do peer reviewing either by first attaching patches to the issue and have somebody review it, or by hoping that someone is reading the commit mails and notices if something is wrong. We should never make a release that has issues in the Resolved state, as it has unverified code, probably with missing documentation and proper tests. We should reserve a few days before each release for moving any Resolved issue to the Closed state, by verifying, testing and documenting it.
Verifying issues can be done by outsiders, too, so we could involve the community more. Perhaps it would be a good idea to require two verifiers before moving the issue to verified, as testing on different systems can spot some bugs, like the full screen editor not working in Safari issue.
Sergiu -- http://purl.org/net/sergiu
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs