tika-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Jira / Subversion / Patch / Commit Questions
Date Thu, 13 Sep 2007 13:07:12 GMT

On 9/11/07, kbennett <kbennett@bbsinc.biz> wrote:
> I've submitted a patch for TIKA-10 (by attaching the patch file to the Jira
> issue).  Does someone update the Jira issue when the patch is applied, or do
> I just check the repository periodically?

The typical workflow is for a committer to mark the issue as resolved
(or comment on the issue if the solution is partial) once the patch
has been applied.

> There are a few more patches I'd like to contribute that have already been
> approved in concept.  How does this work, regarding the sequence of the
> patches?  I realize that it is possible to submit multiple patches if none
> of them modify the same file(s).  If they do modify the same file(s),
> though, am I correct to assume that I must wait for a pending patch to be
> applied, and then update my local working copy, before creating the patch
> file for the next issue?

If the patches don't depend on each other (i.e. they fix two
independent issues in the same file) then you can make separate
patches for the issues (just start from a clean checkout for both
fixes). Typically it'll be quite easy to merge such changes.

If the patches do depend on each other, i.e. one patch is required for
the other to work, then you could well create a single issue that
covers all the proposed changes and just submit one big patch.

> Regarding TIKA-11, "Consolidate test classes into a src/test/java directory
> tree.", where the fix consists of moving a couple of files and changing the
> pom file, would it be easier for the committer to do the svn move
> him/herself rather than my sending a patch to do that?  In this case I would
> add a comment with the svn move information and also upload a patch for the
> pom file.

Sending the svn move commands as a comment and attaching a patch for
the remaining changes is a good approach.


Jukka Zitting

View raw message