Hi Holger,
Martijn Faassen wrote:
Holger Joukl wrote:
Inline diff output or attached diff files, and based on which file versions/revisions?
Small attachments easiest, I think.
Text attachments are always better than inline patches. Most mail programs make them directly visible and, being attached files, they do not loose any character encodings or suffer from line wrapping.
BTW: we try to limit lines to 80 characters, which also tends to pass some mail programs.
Either to trunk or 1.0 branch, depending on whether you're doing a feature change or something that can be construed as a "bug fix" (documentation clarifications are bugfixes to me, even if they would add a few doctest examples). We'll do the synching to trunk where needed.
Right. The 1.0 branch is in stable maintenance mode, meaning: no new features, conservative changes, etc.
And doc patches, especially: I assume the doc sources are the .txt files in the doc directory (I've never used rest...)?
Yes, they're the .txt files; they're in ReST format but if you just follow the pattern in the files you should be fine, and we can fix up any small problems.
Note that there is an "html" target in the Makefile that regenerates the HTML pages. If you have the ReST tools installed, you can use it to check the result before sending in patches.
If you go changing the doctests, please make sure you run the testsuite (python test.py) to see whether they actually work.
Yep!
And, BTW, it's much more likely that a patch will be accepted if it comes with doctests and/or unit test cases in src/lxml/test_*.py.
If you're planning on doing *lots* of stuff we can get you a codespeak SVN account, of course, and you can work on a branch. :)
Still, you should keep talking to the list before you go for bigger stuff. It's not always easy to understand the way things work, so we may have some pointers for you.
Stefan