poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Javen O'Neal" <javenon...@gmail.com>
Subject Format of submitted patches
Date Sat, 16 Jan 2016 07:52:31 GMT
>From http://poi.apache.org/guidelines.html#SubmittingPatches
You may create your patch file using either of the following
approaches (the committers recommend the first):
Approach 1 - use Ant
Approach 2 - the manual way
Approach 3 - the git way

What is the current preference among the POI committers and community?
I prefer having a plain text diff attached to the bugs since I'm often
on mobile and can't view the tarballs as easily. This problem would go
away if ant produced a plain text diff plus a tarball of any binary
files or bugzilla showed the tarball contents.

I personally prefer to work with patch files, as it's easier for me to
check changes on my phone. (no tar xvzf business).

Pros to `ant patch`:
* Less likely to forget to include new files, especially binary files
(XLS and XLSX test cases) that don't show up in svn diff output
* Generates a single tarball to upload to bugzilla

Cons to `ant -f patch.xml`:
* Patch includes temporary files that were created but not deleted by unit tests
* Zipped contribution is difficult to read and browse on mobile,
requires an extra step to read it on non-mobile. In all likelihood,
the people who are merely curious but not dependent on the changes or
a committer will read the patch. Fewer eyeballs and
non-mobile-friendliness means less and slower feedback.
* ant -f patch.xml can create a patch tarball with one command. Can
ant apply a patch tarball to a working directory with one command?

Pros to `svn diff`:
* Can cherrypick the files you want to include in diff
* Mobile friendly (the merely curious people can read the patch on
their phone when waiting for the bus)
* Better metadata: encourages also defining svn properties on added
files. `svn copy` shows up in the diff, improving the version control
history graph.

Cons to `svn diff`:
* More likely to forget to include binary files
* More likely to have two attachments: the diff and either single test
case file or a zip of multiple test case files. Could also include the
diff in the zip, but why not use ant at that point?

If we want to stick with ant as the recommended approach, could we do
something to address:
1) for reviewers: make it easier to read the diff on mobile in a web browser
2) mostly for the committer: easier to apply an ant-generated patch
tarball to a working copy

To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org

View raw message