No replies yet... On Oct 11, 2007 5:33 PM, Sergiu Dumitriu <sergiu.dumitriu(a)gmail.com> wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On Dec 5, 2007, at 3:13 PM, Vincent Massol wrote: 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 _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On Dec 6, 2007, at 5:22 PM, Ludovic Dubost wrote: 2 points: 1) I'd prefer a new state rather than Resolved. Something like "Tested" or "Externally Tested" or "Verified by Tester" or whatever

2) We'll need to write issues from a user point of view (which I've always wanted) and not from an internal point of view. This means that for each issue fixed technically we need to find a user use case that was failing because of it and use that as the description rather than a technical description. Otherwise an external tester won't be able to test it. anyway let's wait for a tester to come on board first... -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.

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