Hi Vincent, On Jul 17, 2012, at 12:10 PM, Vincent Hennebert wrote:
> On 13/07/12 22:52, Alexios Giotis wrote: >> A change log or "release notes" can be generated by Jira [1]. For example, >> [2] is the release notes for Apache PDFBox 1.7. Bug or issue titles (at >> least) tend to be better, if it is known that the change log is generated by >> such a system. Glenn wrote very good points. It will help the FOP community >> if everybody is recording in BZ or Jira substantial changes, whether this is >> an existing practice or not. > > An automatically generated change log is definitely desirable. But we > already have that with status.xml. What else does Bugzilla/JIRA bring? It improves documentation. For example, I frequently execute "svn annotate", read the usually brief commit message and then refer to the bug for more info (and context in my case). I don't like the fact that I have to rely to another system, but it helps, especially for old change sets. > At the moment, adding an entry to status.xml is easy: > • edit status.xml > • commit it with the rest of the patch > > Doing it in a BTS sounds much more cumbersome to me: > • loading the appropriate page in the web browser > • fill in all the appropriate entries for a new bug > • upload a test file illustrating the defect > • click on the upload button > • click several times in the ‘Open File’ dialog box to find the test > file on our system > • click on upload > • click on enter > • ... You get the idea Yes, filing a bug is definitely much more cumbersome than updating status.xml and nobody would like wasting the time of the few experienced developers. But I expect it will take less than 15 minutes to file a bug and that this time should be small compared to the time spend to make a substantive change. Small improvements, javadoc updates, typo fixes, renaming of variables, checkstyle / findbug fixes ... don't deserve a new bug. Test files illustrating the defect are not mandatory and in most cases, they are committed as part of the unit tests (which are also not mandatory as well but good to have). > > If the end result is to have to very same change log as what is > generated from status.xml right now, then I’m not sure I see the point. The end result is to provide a documentation trail. I initially replied to this thread because Jira is not (yet) used in FOP and it happens to provide this feature. > > If the community decides to move to a BTS to log changes, I won’t oppose > it but I will do it reluctantly. Also, I would be even more bothered to > have to both 1) add an entry to status.xml 2) add a BZ entry. So I would > suggest that we deprecate status.xml as soon as we make the move, and > find a way to integrate the new change list to the website. You are right about deprecating status.xml. I hope that in the long term you will see the benefits of this practice and willingly file bugs (BZ) or create issues (Jira). Alexios > > > Vincent > > >> [1] https://confluence.atlassian.com/display/JIRA/Creating+Release+Notes >> [2] >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310760&version=12316940 >> >> Alexios Giotis >> >> On Jul 13, 2012, at 6:08 PM, Vincent Hennebert wrote: >> >>> We can decide to change that and use a bug tracking system instead, but >>> in the same time we do that we will have to have in place a new >>> mechanism to generate the changes [1] page. Also, we will most likely >>> have to find a way to feed the BTS with the content of status.xml that >>> is not there yet. >>> >>> [1] http://xmlgraphics.apache.org/fop/changes.html >> >
