You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by darshan <u4...@anu.edu.au> on 2011/05/01 02:25:48 UTC
Want to contribute
Dear All,
I am a post graduate student at the Australian National University
taking a course on Free and Open Source Software Development. Part of
the course requirement is to study an open source project of my choice,
make a contribution and write a report by the end of May 2011.
I have been going through the fop site and documents and from the 'How
you can help' topic on the page
http://xmlgraphics.apache.org/fop/dev/index.html
I thought the best way I could contribute is by testing newly-closed
issues to make sure they are truly closed. By doing this I can gradually
understand how the system works and hopefully start make more
contributions like submitting bug reports and patches.
Can I start from the most recent fix form the page
http://xmlgraphics.apache.org/fop/changes.html#Code_FOP%20Trunk ? please
guide me as to what would be the best way of doing it and also I would
be really glad if you could suggest me any other way to contribute that
would help the project better.
Best regards,
Darshan Pradhan
u4729733@anu.edu.au
Re: Want to contribute
Posted by darshan <u4...@anu.edu.au>.
Hi Andreas,
I was doing a stupid thing by putting the test file into a wrong
directory. Sorry for the unnecessary confusion. I have made the attached
testcase again for the same bug and the test is working with the svn
copy I have. Could you please check it out for me?
Thank you,
Drashan
On 25/05/11 04:08, Andreas L. Delmelle wrote:
> On 24 May 2011, at 03:35, darshan wrote:
>
> Hi Darshan
>
>> <snip />
>>
>> 5. I found out the xpath values using the firefox extention XPather and then filled in the checks accordingly.
> OK, that works too and looks comprehensive.
> There is an easier way, though. If you have FOP set up in an IDE (Eclipse, IntelliJ IDEA...), then, as mentioned on the Wiki, you can just "set up a JUnit Launch configuration", which will allow you to run the test from within your IDE. That's where those variables come into play. If you do not set them, the entire test suite will be run. Specifying '-Dfop.layoutengine.starts-with=...' as a VM parameter would only run those tests whose name starts with the specified string, etc.
>
> In that case, you have the benefit of the standard output we normally get when running the test suite (see the output I posted earlier). If the test passes, you should also get a clear indication that none of the checks failed and the test finished successfully.
>
>> I have attached the .at files as well.
>>
>> Also does follow-up attachment mean that I attached the file to the bugreport https://issues.apache.org/bugzilla/show_bug.cgi?id=50196 and close it?
> Indeed. If we confirmed it on our end, we will then add the test to our suite, and everything remains available in Bugzilla for future reference. If we cannot verify that it has been fixed, we will reopen and will ask you to re-examine.
>
> Thanks!
>
> Regards
>
> Andreas
> ---
Re: Want to contribute
Posted by "Andreas L. Delmelle" <an...@telenet.be>.
On 24 May 2011, at 03:35, darshan wrote:
Hi Darshan
> <snip />
>
> 5. I found out the xpath values using the firefox extention XPather and then filled in the checks accordingly.
OK, that works too and looks comprehensive.
There is an easier way, though. If you have FOP set up in an IDE (Eclipse, IntelliJ IDEA...), then, as mentioned on the Wiki, you can just "set up a JUnit Launch configuration", which will allow you to run the test from within your IDE. That's where those variables come into play. If you do not set them, the entire test suite will be run. Specifying '-Dfop.layoutengine.starts-with=...' as a VM parameter would only run those tests whose name starts with the specified string, etc.
In that case, you have the benefit of the standard output we normally get when running the test suite (see the output I posted earlier). If the test passes, you should also get a clear indication that none of the checks failed and the test finished successfully.
> I have attached the .at files as well.
>
> Also does follow-up attachment mean that I attached the file to the bugreport https://issues.apache.org/bugzilla/show_bug.cgi?id=50196 and close it?
Indeed. If we confirmed it on our end, we will then add the test to our suite, and everything remains available in Bugzilla for future reference. If we cannot verify that it has been fixed, we will reopen and will ask you to re-examine.
Thanks!
Regards
Andreas
---
Re: Want to contribute
Posted by darshan <u4...@anu.edu.au>.
Thank you for the quick response Andreas.
1. In the test file I set the /inline padding-left ="20"/ for the
header and footer in lines 43, 48, 57 and 62.
2. I then generated an area tree using version 0.95 of FOP, I generated
another area tree with the latest build I downloaded
http://ci.apache.org/projects/xmlgraphics
/fop/snapshots/fop-20110514-bin.tar.gz . The xsl file I used for the
transformation was testcase2fo.xsl in the test/layoutengine folder
3. Then I separated the elements in the two .at file on each separate
line and ran the /diff/ command for the two .at files.
4. The .at files had/inlineparent padding-start="20000" /for four
different blocks which I presumed were the header and footer blocks form
the table. I just notice that the /bap="20000 0 0 0"/ values for
/inlineparent /has changed as well. I have added the difference in the
new attached test file. There were differences in the color attributes
for some elements but I ignored them. The difference file that only has
the padding differences is attached.
5. I found out the xpath values using the firefox extention XPather and
then filled in the checks accordingly.
I have attached the .at files as well.
Also does follow-up attachment mean that I attached the file to the
bugreport https://issues.apache.org/bugzilla/show_bug.cgi?id=50196 and
close it?
Thank you,
Darshan
On 23/05/11 05:16, Andreas L. Delmelle wrote:
> On 22 May 2011, at 19:47, darshan wrote:
>
> Hi Darshan
>
>> Thank you for the reply. I created a diff file and then wrote the checks, but I couldn't figure how to verify if the test was working. Also since the pagehttp://xmlgraphics.apache.org/fop/dev/testing.html does not specify how I should submit the test file, I'm attaching the files with this mail. If this is not the right way then please guide me to submit the file properly.
> The best way is to just post them as a follow-up attachment, if you decide to close the bug.
>
>> To run the test, I tried by putting the file in the test/layoutengine/standard-testcases folder and then setting the variable "-Dfop.layoutengine.starts-with" to my test file name, but it didn't run the test. If you could also let me know how to verify if the test works then that would be great.
> Can you describe more in detail the exact steps you are taking? How do you set the variable, and what do you do after that?
>
> I ran your test and it failed:
> java.lang.RuntimeException:
> Expected XPath expression to evaluate to '20000', but got '' (XPath: /areatree/pageSequence/pageViewport[2]/page/regionViewport/regionBody/mainReference/span/flow/block/block[10]/block/linearea/inlineparent/@padding-start)
>
> but this was in my local sandbox (!= trunk), so that may also be due to other changes on my end.
>
>> Lastly for my report I need to write who started the project and what was the reason for starting the project. I know that James Tauber started the project but could you please tell me why he started it?
> I would say it was just to have an open-sourced, free, Java-based XSL-FO implementation to augment the existing initiatives for XML parsing at that time, but I do not know this for certain.
>
>
> Regards
>
> Andreas
> ---
Re: Want to contribute
Posted by "Andreas L. Delmelle" <an...@telenet.be>.
On 22 May 2011, at 19:47, darshan wrote:
Hi Darshan
> Thank you for the reply. I created a diff file and then wrote the checks, but I couldn't figure how to verify if the test was working. Also since the page http://xmlgraphics.apache.org/fop/dev/testing.html does not specify how I should submit the test file, I'm attaching the files with this mail. If this is not the right way then please guide me to submit the file properly.
The best way is to just post them as a follow-up attachment, if you decide to close the bug.
> To run the test, I tried by putting the file in the test/layoutengine/standard-testcases folder and then setting the variable "-Dfop.layoutengine.starts-with" to my test file name, but it didn't run the test. If you could also let me know how to verify if the test works then that would be great.
Can you describe more in detail the exact steps you are taking? How do you set the variable, and what do you do after that?
I ran your test and it failed:
java.lang.RuntimeException:
Expected XPath expression to evaluate to '20000', but got '' (XPath: /areatree/pageSequence/pageViewport[2]/page/regionViewport/regionBody/mainReference/span/flow/block/block[10]/block/linearea/inlineparent/@padding-start)
but this was in my local sandbox (!= trunk), so that may also be due to other changes on my end.
> Lastly for my report I need to write who started the project and what was the reason for starting the project. I know that James Tauber started the project but could you please tell me why he started it?
I would say it was just to have an open-sourced, free, Java-based XSL-FO implementation to augment the existing initiatives for XML parsing at that time, but I do not know this for certain.
Regards
Andreas
---
Re: Want to contribute
Posted by darshan <u4...@anu.edu.au>.
Hi Andreas,
Thank you for the reply. I created a diff file and then wrote the
checks, but I couldn't figure how to verify if the test was working.
Also since the page http://xmlgraphics.apache.org/fop/dev/testing.html
does not specify how I should submit the test file, I'm attaching the
files with this mail. If this is not the right way then please guide me
to submit the file properly.
To run the test, I tried by putting the file in the
test/layoutengine/standard-testcases folder and then setting the
variable "-Dfop.layoutengine.starts-with" to my test file name, but it
didn't run the test. If you could also let me know how to verify if the
test works then that would be great.
Lastly for my report I need to write who started the project and what
was the reason for starting the project. I know that James Tauber
started the project but could you please tell me why he started it?
Thank you,
Darshan
On 17/05/11 06:14, Andreas L. Delmelle wrote:
> On 15 May 2011, at 07:18, darshan wrote:
>
> Hi Darshan
>
>> Thank you all for answering my questions. I could run the test cases using the variables in eclipse. That was great! Should I update the wiki so that other it will be easier for other people using eclipse?
> Yes, if you think that is useful, then by all means, go ahead. Thanks!
>
>> For the bug report 47279 from my previous mail, the bug seems to have been fixed so can it's status be changed to resolved?
> If it is really fixed somehow, then I'd definitely start by adding a comment that describes how you verified this. If the reporter challenges your assessment, he will reopen anyway, so it does no harm to close it if you are convinced.
>
>> Lastly the bug report https://issues.apache.org/bugzilla/show_bug.cgi?id=50196 was reopened because there was no test case for the fix. I have reproduced the error by modifying one of the existing layout test files. The xml file and the output pdfs are attached. However I could not figure out how to write the checks. How can I know which xpath elements should have what values? Could you please guide as to how I can write the checks?
> You will want to take a look at the generated area tree XML in the build/test-results folder (or wherever you have the output sent to). Locate the elements in the tree that play a part in the issue, and figure out which attribute values to check.
>
> Note: if you leave the<checks> element empty, you will still always get a default check for a non-empty areaTree node. I added this once, to have a generic way to check for simple things, like not throwing a NullPointerException, but I see it is not mentioned on the Wiki...
>
> Hope this helps!
>
> Regards
>
> Andreas
Re: Want to contribute
Posted by "Andreas L. Delmelle" <an...@telenet.be>.
On 15 May 2011, at 07:18, darshan wrote:
Hi Darshan
> Thank you all for answering my questions. I could run the test cases using the variables in eclipse. That was great! Should I update the wiki so that other it will be easier for other people using eclipse?
Yes, if you think that is useful, then by all means, go ahead. Thanks!
> For the bug report 47279 from my previous mail, the bug seems to have been fixed so can it's status be changed to resolved?
If it is really fixed somehow, then I'd definitely start by adding a comment that describes how you verified this. If the reporter challenges your assessment, he will reopen anyway, so it does no harm to close it if you are convinced.
> Lastly the bug report https://issues.apache.org/bugzilla/show_bug.cgi?id=50196 was reopened because there was no test case for the fix. I have reproduced the error by modifying one of the existing layout test files. The xml file and the output pdfs are attached. However I could not figure out how to write the checks. How can I know which xpath elements should have what values? Could you please guide as to how I can write the checks?
You will want to take a look at the generated area tree XML in the build/test-results folder (or wherever you have the output sent to). Locate the elements in the tree that play a part in the issue, and figure out which attribute values to check.
Note: if you leave the <checks> element empty, you will still always get a default check for a non-empty areaTree node. I added this once, to have a generic way to check for simple things, like not throwing a NullPointerException, but I see it is not mentioned on the Wiki...
Hope this helps!
Regards
Andreas
Re: Want to contribute
Posted by darshan <u4...@anu.edu.au>.
Hi All,
Thank you all for answering my questions. I could run the test cases
using the variables in eclipse. That was great! Should I update the wiki
so that other it will be easier for other people using eclipse?
For the bug report 47279 from my previous mail, the bug seems to have
been fixed so can it's status be changed to resolved?
Lastly the bug report
https://issues.apache.org/bugzilla/show_bug.cgi?id=50196 was reopened
because there was no test case for the fix. I have reproduced the error
by modifying one of the existing layout test files. The xml file and the
output pdfs are attached. However I could not figure out how to write
the checks. How can I know which xpath elements should have what values?
Could you please guide as to how I can write the checks?
Thank you,
Darshan
On 12/05/11 04:54, Jeremias Maerki wrote:
> Hi Darshan,
>
> system properties are set on the command-line with the "-D" argument.
> Example:
>
> java -cp myjar1.jar;myjar2.jar -Dmy.system.property=foo mysystem.Main
>
> This implicitely does System.setProperty("my.system.property", "foo");
>
> And from an Eclipse launch configuration, you can equally set such -D
> arguments on the second tab "Arguments" in the text box called "VM
> arguments". So you can simply put "-Dfop.layoutengine.starts-with=table"
> in there if you want to run all tests that start with "table".
>
> HTH
>
> On 09.05.2011 23:28:44 darshan pradhan wrote:
> <snip/>
>> Lastly, in the page
>> http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests
>> under the topic *Setting up the Test Suite in your favorite IDE,* I
>> could not figure out how to set the system properties to control the
>> test cases run in Eclipse. Could you please tell me how to do it?
> <snip/>
>
>
> Jeremias Maerki
>
Re: Want to contribute
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Darshan,
system properties are set on the command-line with the "-D" argument.
Example:
java -cp myjar1.jar;myjar2.jar -Dmy.system.property=foo mysystem.Main
This implicitely does System.setProperty("my.system.property", "foo");
And from an Eclipse launch configuration, you can equally set such -D
arguments on the second tab "Arguments" in the text box called "VM
arguments". So you can simply put "-Dfop.layoutengine.starts-with=table"
in there if you want to run all tests that start with "table".
HTH
On 09.05.2011 23:28:44 darshan pradhan wrote:
<snip/>
> Lastly, in the page
> http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests
> under the topic *Setting up the Test Suite in your favorite IDE,* I
> could not figure out how to set the system properties to control the
> test cases run in Eclipse. Could you please tell me how to do it?
<snip/>
Jeremias Maerki
Re: Want to contribute
Posted by Pascal Sancho <pa...@takoma.fr>.
Oh, my bad!
I've read Vincent's comment too quickly. You are right, and sorry about
what I said in this threat regarding this issue.
Apologies again.
Le 11/05/2011 13:45, Chris Bowditch a écrit :
> On 11/05/2011 08:11, Pascal Sancho wrote:
>> Hi Darshan,
>
> Hi Pascal,
>
>> Le 09/05/2011 23:28, darshan pradhan a écrit :
>>> Thank you for the reply. While I was looking at old open issues that
>>> haven't been closed, I came across
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=47279 , this bug
>>> seems to have been fixed. I tried creating a pdf from a xml using xsl
>>> without specifying any font-name, and setting the font-weight to bold. I
>>> didn't get any warning messages form the conversion. Should I change the
>>> state of the bug form open to resolved?
>> As said in issue comments, the test case should send warnings, if this
>> is not the case, then the issues should remain opened.
>>
>
> Sorry Pascal, but I don't see any comment from yourself on bugzilla
> 47279. Vincent created that bugzilla and the only comment is due to the
> attachment of a test case.
>
> Also, IIUC, the problem was that font warnings were logged when no
> reference were made to those exact families and weights. Therefore the
> bug is fixed when the warnings don't appear when running the test case.
> it would be good to know which commit actually resolved the warnings
> though, so we can be certain it works in a generic way and the test case
> isn't fixed by accident.
>
> <snip/>
>
> Chris
--
Pascal
Re: Want to contribute
Posted by Chris Bowditch <bo...@hotmail.com>.
On 11/05/2011 08:11, Pascal Sancho wrote:
> Hi Darshan,
Hi Pascal,
> Le 09/05/2011 23:28, darshan pradhan a écrit :
>> Thank you for the reply. While I was looking at old open issues that
>> haven't been closed, I came across
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=47279 , this bug
>> seems to have been fixed. I tried creating a pdf from a xml using xsl
>> without specifying any font-name, and setting the font-weight to bold. I
>> didn't get any warning messages form the conversion. Should I change the
>> state of the bug form open to resolved?
> As said in issue comments, the test case should send warnings, if this
> is not the case, then the issues should remain opened.
>
Sorry Pascal, but I don't see any comment from yourself on bugzilla
47279. Vincent created that bugzilla and the only comment is due to the
attachment of a test case.
Also, IIUC, the problem was that font warnings were logged when no
reference were made to those exact families and weights. Therefore the
bug is fixed when the warnings don't appear when running the test case.
it would be good to know which commit actually resolved the warnings
though, so we can be certain it works in a generic way and the test case
isn't fixed by accident.
<snip/>
Chris
Re: Want to contribute
Posted by Pascal Sancho <pa...@takoma.fr>.
Hi Darshan,
Le 09/05/2011 23:28, darshan pradhan a écrit :
> Thank you for the reply. While I was looking at old open issues that
> haven't been closed, I came across
> https://issues.apache.org/bugzilla/show_bug.cgi?id=47279 , this bug
> seems to have been fixed. I tried creating a pdf from a xml using xsl
> without specifying any font-name, and setting the font-weight to bold. I
> didn't get any warning messages form the conversion. Should I change the
> state of the bug form open to resolved?
As said in issue comments, the test case should send warnings, if this
is not the case, then the issues should remain opened.
> I wanted to test the resolved bugs as well. I saw that some have test
> cases modified as patches are applied. I wasn't sure how I can go about
> testing for the bug fixes. For instance for the patch in
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50471 , should I
> create a document with a character 1F7E and see if fop runs without errors?
If such test case doesn't exist in FOP source code, you can create and
propose it as a patch (see [1]) in a new bugzilla entry (to keep track
of it).
Just 2 things:
- when running the test-case, the issue should occur before bugfix, IE
before rev 1056518;
- the new bug entry should be related to the #50471
[1] http://xmlgraphics.apache.org/fop/dev/index.html#patches
> Lastly, in the page
> http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests
> under the topic *Setting up the Test Suite in your favorite IDE,* I
> could not figure out how to set the system properties to control the
> test cases run in Eclipse. Could you please tell me how to do it?
I cannot help you on this topic. Someone else?
> I would really appreciate your guidance.
>
> Thank you,
> Darshan
>
> On 03/05/11 20:47, Glenn Adams wrote:
>> Actually, I would encourage testing closed issues, or at least those
>> issues that were resolved without creating a test data set that
>> demonstrates both the bug and the fix, and maintains non-regression.
>>
>> I have noticed a number of issues "fixed" without adding such tests,
>> which should be the norm, not the exception.
>>
>> G.
>>
>> On Tue, May 3, 2011 at 1:24 AM, Pascal Sancho <pascal.sancho@takoma.fr
>> <ma...@takoma.fr>> wrote:
>>
>> Hi,
>>
>> FOP is an open source project, and everybody can contribute in his own
>> way, so you can reopen closed issues as you want if needed, and submit
>> patches as you want.
>>
>> That said, IMHO, apart in a company quality context, testing closed
>> issues will not help very much (typically, an issue is closed after
>> developer's checks, and it is often monitored by the opener who reopen
>> it if needed)
>> But:
>> you can check old opened issues against FOP TRUNK, since there is no
>> systematic checks for opened issues after each commit.
>> You can find fixed issues that haven't been closed.
>>
>> Le 01/05/2011 02:25, darshan a écrit :
>> > Dear All,
>> >
>> > I am a post graduate student at the Australian National University
>> > taking a course on Free and Open Source Software Development.
>> Part of
>> > the course requirement is to study an open source project of my
>> choice,
>> > make a contribution and write a report by the end of May 2011.
>> >
>> > I have been going through the fop site and documents and from
>> the 'How
>> > you can help' topic on the page
>> > http://xmlgraphics.apache.org/fop/dev/index.html
>> > I thought the best way I could contribute is by testing
>> newly-closed
>> > issues to make sure they are truly closed. By doing this I can
>> gradually
>> > understand how the system works and hopefully start make more
>> > contributions like submitting bug reports and patches.
>> >
>> > Can I start from the most recent fix form the page
>> > http://xmlgraphics.apache.org/fop/changes.html#Code_FOP%20Trunk
>> ? please
>> > guide me as to what would be the best way of doing it and also I
>> would
>> > be really glad if you could suggest me any other way to
>> contribute that
>> > would help the project better.
>> >
>> > Best regards,
>> > Darshan Pradhan
>> > u4729733@anu.edu.au <ma...@anu.edu.au>
>>
>> --
>> Pascal
>>
>>
>
--
Pascal
Re: Want to contribute
Posted by darshan pradhan <u4...@anu.edu.au>.
Thank you for the reply. While I was looking at old open issues that
haven't been closed, I came across
https://issues.apache.org/bugzilla/show_bug.cgi?id=47279 , this bug
seems to have been fixed. I tried creating a pdf from a xml using xsl
without specifying any font-name, and setting the font-weight to bold. I
didn't get any warning messages form the conversion. Should I change the
state of the bug form open to resolved?
I wanted to test the resolved bugs as well. I saw that some have test
cases modified as patches are applied. I wasn't sure how I can go about
testing for the bug fixes. For instance for the patch in
https://issues.apache.org/bugzilla/show_bug.cgi?id=50471 , should I
create a document with a character 1F7E and see if fop runs without errors?
Lastly, in the page
http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests
under the topic *Setting up the Test Suite in your favorite IDE,* I
could not figure out how to set the system properties to control the
test cases run in Eclipse. Could you please tell me how to do it?
I would really appreciate your guidance.
Thank you,
Darshan
On 03/05/11 20:47, Glenn Adams wrote:
> Actually, I would encourage testing closed issues, or at least those
> issues that were resolved without creating a test data set that
> demonstrates both the bug and the fix, and maintains non-regression.
>
> I have noticed a number of issues "fixed" without adding such tests,
> which should be the norm, not the exception.
>
> G.
>
> On Tue, May 3, 2011 at 1:24 AM, Pascal Sancho <pascal.sancho@takoma.fr
> <ma...@takoma.fr>> wrote:
>
> Hi,
>
> FOP is an open source project, and everybody can contribute in his own
> way, so you can reopen closed issues as you want if needed, and submit
> patches as you want.
>
> That said, IMHO, apart in a company quality context, testing closed
> issues will not help very much (typically, an issue is closed after
> developer's checks, and it is often monitored by the opener who reopen
> it if needed)
> But:
> you can check old opened issues against FOP TRUNK, since there is no
> systematic checks for opened issues after each commit.
> You can find fixed issues that haven't been closed.
>
> Le 01/05/2011 02:25, darshan a écrit :
> > Dear All,
> >
> > I am a post graduate student at the Australian National University
> > taking a course on Free and Open Source Software Development.
> Part of
> > the course requirement is to study an open source project of my
> choice,
> > make a contribution and write a report by the end of May 2011.
> >
> > I have been going through the fop site and documents and from
> the 'How
> > you can help' topic on the page
> > http://xmlgraphics.apache.org/fop/dev/index.html
> > I thought the best way I could contribute is by testing
> newly-closed
> > issues to make sure they are truly closed. By doing this I can
> gradually
> > understand how the system works and hopefully start make more
> > contributions like submitting bug reports and patches.
> >
> > Can I start from the most recent fix form the page
> > http://xmlgraphics.apache.org/fop/changes.html#Code_FOP%20Trunk
> ? please
> > guide me as to what would be the best way of doing it and also I
> would
> > be really glad if you could suggest me any other way to
> contribute that
> > would help the project better.
> >
> > Best regards,
> > Darshan Pradhan
> > u4729733@anu.edu.au <ma...@anu.edu.au>
>
> --
> Pascal
>
>
Re: Want to contribute
Posted by Glenn Adams <gl...@skynav.com>.
Actually, I would encourage testing closed issues, or at least those issues
that were resolved without creating a test data set that demonstrates both
the bug and the fix, and maintains non-regression.
I have noticed a number of issues "fixed" without adding such tests, which
should be the norm, not the exception.
G.
On Tue, May 3, 2011 at 1:24 AM, Pascal Sancho <pa...@takoma.fr>wrote:
> Hi,
>
> FOP is an open source project, and everybody can contribute in his own
> way, so you can reopen closed issues as you want if needed, and submit
> patches as you want.
>
> That said, IMHO, apart in a company quality context, testing closed
> issues will not help very much (typically, an issue is closed after
> developer's checks, and it is often monitored by the opener who reopen
> it if needed)
> But:
> you can check old opened issues against FOP TRUNK, since there is no
> systematic checks for opened issues after each commit.
> You can find fixed issues that haven't been closed.
>
> Le 01/05/2011 02:25, darshan a écrit :
> > Dear All,
> >
> > I am a post graduate student at the Australian National University
> > taking a course on Free and Open Source Software Development. Part of
> > the course requirement is to study an open source project of my choice,
> > make a contribution and write a report by the end of May 2011.
> >
> > I have been going through the fop site and documents and from the 'How
> > you can help' topic on the page
> > http://xmlgraphics.apache.org/fop/dev/index.html
> > I thought the best way I could contribute is by testing newly-closed
> > issues to make sure they are truly closed. By doing this I can gradually
> > understand how the system works and hopefully start make more
> > contributions like submitting bug reports and patches.
> >
> > Can I start from the most recent fix form the page
> > http://xmlgraphics.apache.org/fop/changes.html#Code_FOP%20Trunk ? please
> > guide me as to what would be the best way of doing it and also I would
> > be really glad if you could suggest me any other way to contribute that
> > would help the project better.
> >
> > Best regards,
> > Darshan Pradhan
> > u4729733@anu.edu.au
>
> --
> Pascal
>
Re: Want to contribute
Posted by Pascal Sancho <pa...@takoma.fr>.
Hi,
FOP is an open source project, and everybody can contribute in his own
way, so you can reopen closed issues as you want if needed, and submit
patches as you want.
That said, IMHO, apart in a company quality context, testing closed
issues will not help very much (typically, an issue is closed after
developer's checks, and it is often monitored by the opener who reopen
it if needed)
But:
you can check old opened issues against FOP TRUNK, since there is no
systematic checks for opened issues after each commit.
You can find fixed issues that haven't been closed.
Le 01/05/2011 02:25, darshan a écrit :
> Dear All,
>
> I am a post graduate student at the Australian National University
> taking a course on Free and Open Source Software Development. Part of
> the course requirement is to study an open source project of my choice,
> make a contribution and write a report by the end of May 2011.
>
> I have been going through the fop site and documents and from the 'How
> you can help' topic on the page
> http://xmlgraphics.apache.org/fop/dev/index.html
> I thought the best way I could contribute is by testing newly-closed
> issues to make sure they are truly closed. By doing this I can gradually
> understand how the system works and hopefully start make more
> contributions like submitting bug reports and patches.
>
> Can I start from the most recent fix form the page
> http://xmlgraphics.apache.org/fop/changes.html#Code_FOP%20Trunk ? please
> guide me as to what would be the best way of doing it and also I would
> be really glad if you could suggest me any other way to contribute that
> would help the project better.
>
> Best regards,
> Darshan Pradhan
> u4729733@anu.edu.au
--
Pascal