Re: [xwiki-devs] Reintroduce the Resolved state in JIRA

On Dec 6, 2007, at 5:31 PM, Vincent Massol wrote: and yes I agree it's a per project setting. Also, I keep my very strong belief that developers need to write their own tests and verify all works.

-Vincent >> Maybe we can leave the decision on the project head for each of our >> projects. >> >> Ludovic >> >> Vincent Massol wrote: >>> On Dec 5, 2007, at 3:13 PM, Vincent Massol wrote: >>> >>> >>>> I don't like it. >>>> >>>> The developer is reponsible for testing what he commits. Period. >>>> Anything that implies otherwise should be banned IMO. >>>> >>> Just to qualify my answer a bit ;) >>> >>> It can work but only when there's a very rigid process with one >>> person >>> working full time to manage it. Unfortunately we don't have that >>> person yet. Maybe in the future we'll be able to get someone to do >>> functional tests for us. When this happens we could possibly add a >>> new >>> state for whether the issue has been validated by an external tester >>> or not. But even when that happens every developer still needs to >>> ensure that: >>> 1) he's fully tested it (with automated tests as much as possible) >>> 2) written documentation for it >>> >>> -Vincent >>> >>> >>>> On Dec 5, 2007, at 2:54 PM, Sergiu Dumitriu wrote: >>>> >>>> >>>>> No replies yet... >>>>> >>>>> On Oct 11, 2007 5:33 PM, Sergiu Dumitriu >>>>> <sergiu.dumitriu(a)gmail.com> >>>>> 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