Stefan Gybas wrote: > I've added you to the project. Welcome and have fun! :-)
Thanks! I have a few questions about the SVN policies. Why am I not allowed to check in the whole upstream source tree? Are we concerned about disk space? I need to repack the upstream sources to remove jar files etc, and it would be much easier to commit the modified upstream source tree to SVN and work from that, instead of keeping a local tree. Also, I really dislike using dpatch/quilt in conjunction with SVN since it defeats the purpose of having version control (which is to track changes). Instead one can use branches for debian-specific changes. My preferred SVN layout would be something like: branches/nekohtml/upstream/0.9.5 (modified upstream source goes here) branches/nekohtml/feature/debian (copy of upstream with debian/ dir added) branches/nekohtml/feature/fix-compile-warnings (another copy of upstream with some build fixes) branches/nekohtml/feature/broken-links-in-docs (another branch for doc-related bugfixes) trunk/nekohtml: this is the "integration branch" where all feature branches are merged to produce a release. All the Debian-specific work happens on one of the feature branches (which would correspond to individual dpatches or sets of patches). Then these are merged onto trunk. The result is released and tagged as usual. Moreover I find it convenient to store the repacked orig tarballs in SVN. This enables everybody to build the package with a simple svn-buildpackage command. Otherwise there would be no official source for the tarballs, which would complicate cooperative maintenance. Regards, Marcus _______________________________________________ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers