6 Dec
2007
6 Dec
'07
5:40 p.m.
On Dec 6, 2007, at 5:31 PM, Vincent Massol wrote:
On Dec 6, 2007, at 5:22 PM, Ludovic Dubost 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
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... Maybe we can leave the decision on the project
head for each of our
projects.
Ludovic
Vincent Massol 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:
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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
>>
>>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs