[xwiki-devs] Reintroduce the Resolved state in JIRA
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
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
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
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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. 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
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... -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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
Even better. I agree with you that forcing each issue to be tested is not a good idea (it would be in an ideal world), so the best we can do is have an optional state or a boolean property of an issue which signals the fact that there are tests written for that feature. Anyway, I still think that we should have something for this, as I don't like having documentation issues like XWIKI-1867. We could have filters for "My undocumented closed tasks", "Undocumented tasks for the current release", "Undocumented closed tasks".
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 <[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.
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. -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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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...
-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
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (4)
-
Ludovic Dubost -
Sergiu Dumitriu -
Sergiu Dumitriu -
Vincent Massol