xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexios Giotis <alex.gio...@gmail.com>
Subject Re: SVN/Jira integration was: [Re: svn commit: r1360665 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/layoutmgr/ test/java/org/apache/fop/intermediate/ test/java/org/apache/fop/layoutengine/]
Date Thu, 19 Jul 2012 16:09:58 GMT
Hi Mehdi,

I will continue the hijacking of the commit message ..... I feel that opening a new thread
might be disturbing and I don't know if the FOP community is interested. I hope I am helping
a little to improve the processes and not spamming your inbox. I am not familiar with the
Apache infrastructure but some years ago I updated our own development infrastructure (SVN
/ Jira / Jenkins / Artifactory / Confluence / ...) and are currently migrating from svn to

On Jul 19, 2012, at 11:39 AM, mehdi houshmand wrote:

> Having worked a little bit with PDFBox, they seem to have quite tight integration between
the two such that (I think) JIRA prefixes SVN commits automatically with JIRA IDs (the JIRA
number.) I don't know if this integration comes out the box or whether we need to do something
to get it working, but it seems like a good idea.

Actually JIRA has no write access to SVN and is not changing commit messages or anything.
By looking at SVN [1] and Jira [2], I can tell that PDFBox committers are simply following
the good practice of prefixing most commits with the related Jira issue. I guess that this
is now going to be followed by FOP committers too. Although all SVN/Jira integration methods
search the whole commit message for something looking like a Jira issue number, I suggest
that you agree on a pattern. Two commonly used patterns for commit messages are:

FOP-1: Commit message
[FOP-1] Commit message

We follow the 2nd as we may easily spot it, it is used by other tools (e.g. maven release
plugin) and it's easier to track it with an SVN post commit hook that may reject the commit,
send notification emails etc.

[1] http://svn.apache.org/repos/asf/pdfbox/trunk
[2] https://issues.apache.org/jira/browse/PDFBOX

Related to the SVN / Jira integration, all the methods that I know, require someone with admin
access to the infrastructure, and they are:

** A plugin installed to Jira. It adds an additional tab that shows the commits related to
the Jira issue, see [3].

** Attlassian FishEye [4]. The Apache Camel project is somehow using it, for example scroll
a little down and click the "Source" tab in [5]. Looks good but it seams that Attlassian is
hosting the service.

** A plugin [6] installed in Jenkins (continuous integration tool) that adds a comment in
Jira with the revision and the changed files when a new build has been created. Strangely
[6] is currently showing a random plugin page each time refresh the page. If this is happening
while you are reading this, use a google cached page.

I selected and deployed the plugin for Jenkins because when the comment appears, the reporter
of the issue knows that she could get and test an updated snapshot version of that project.
The Apache infrastructure hosts Jenkins at [7]. I am a very happy Jenkins (Hudson) user and
I recommend it. It should be very easy for everyone to set up a FOP build (needs SVN location,
ant target and a selection of some options).

[3] https://studio.plugins.atlassian.com/wiki/display/SVN/Subversion+JIRA+plugin
[4] http://www.atlassian.com/software/fisheye/overview
[5] https://issues.apache.org/jira/browse/CAMEL-4954
[6] https://wiki.jenkins-ci.org/display/JENKINS/JIRA+Plugin
[7] https://builds.apache.org/

> Also, I know Jeremias is a PDFBox committer and this applies to anyone else familiar
with these tools, if they could chime in and give us some suggestions as to either useful
tools and/or process best-practices. I should confess (as has probably been made abundantly
obvious from silly mistakes) I despise SVN and eagerly anticipate the inevitable migration
to a DSCVS of some type (preferably but not exclusively Git.)

I have been using git for over a year and have decided to switch most projects to git. It
seems to be the preferred distributed version control system at the Apache foundation as it
provides mirrors of the projects [8]. The learning curve is steeper compared to other systems
but it should be OK with the few and experienced FOP developers.

[8] http://git.apache.org/

Alexios Giotis

View raw message