On Dec 6, 2007, at 5:45 PM, Sergiu Dumitriu wrote: > Vincent Massol wrote: >> On Dec 6, 2007, at 5:31 PM, Vincent Massol wrote: >> >>> On Dec 6, 2007, at 5:22 PM, Ludovic Dubost wrote: >>> >>>> I'm for a +1 on this one . This would allow to introduce testers in >>>> our >>>> process. >>>> I understand this is difficult for the platform but this would be >>>> easier >>>> for the products. >>> 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... >> >> 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. >> > > +1, but lately not even you write tests...
Yes, I was thinking about exactly this this morning... and was wondering why.... I think it's a combination of: 1) I feel lonely 2) I'm in a hurry for the new xwiki.org site and I haven't taken the time to write the test for the latest fixes I've done. That's bad. :( -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 >>>>>>> <[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 > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
