|
Home > Archive > Apache Mod-Python > October 2005 > Move changes from README to CHANGES file
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Move changes from README to CHANGES file
|
|
| Jim Gallacher 2005-10-28, 5:31 pm |
| Hi Grisha,
Any objection if I split the "changes" from README to a new CHANGES file?
Jim
| |
| Gregory (Grisha) Trubetskoy 2005-10-28, 5:31 pm |
|
Why not refer people to the docs, just like it was done for 3.2? Otherwise
this is yet another file to maintain.
On Fri, 28 Oct 2005, Jim Gallacher wrote:
> Hi Grisha,
>
> Any objection if I split the "changes" from README to a new CHANGES file?
>
> Jim
>
| |
| Jim Gallacher 2005-10-28, 5:31 pm |
| Gregory (Grisha) Trubetskoy wrote:
>
> Why not refer people to the docs, just like it was done for 3.2?
> Otherwise this is yet another file to maintain.
Couple of reasons.
1. I forgot to update the changes in Doc/appendixc.tex when I created
the 3.2.3b tarball. I figure if it was right in front of my face, ie
*CHANGES*, I'd be less likely to forget. 
2. Encourage commiters to update the CHANGES file as they resolve
issues. This is more likely to happen if it's a simple and obvious text
file, rather than a section of Latex code buried in Doc/appendixc.tex.
If it's easy people are likely to keep on top of it.
3. I haven't found the release feature of JIRA to be all the helpful.
The list it generated needed a lot of editing. To do that editing I
found I needed to read the JIRA comments, and sometimes the commited
code or python-dev mailing list messages to figure out what was changed,
added or fixed. This was rather time consuming. It would be *much*
easier if the CHANGES file was edited as issues are resolved, while the
information is still fresh in the commiter's mind. I think we'll end up
with better quality documenation this way.
4. If commiters do their own updates to CHANGES as they go, it's less
work for me when I create the tarball.
If everyone adheres to the same simple format for their additions to the
CHANGES file it will be simple matter to do create a script to generate
the LateX code that can be dumped into the correct section of
appendixc.tex. Example snippet of the proposed CHANGES file:
3.2.4b - Changes from 3.2.3b
Bug Fixes
* Fixed multiple session cookies problem. MODPYTHON-86
* Fixed ./configure problem for SUSE 9 (x86-64). MODPYTHON-85
New Features
* (If we had any new features we'd stick-em here).
Documentation
* Added CHANGES file to mod_python source.
3.2.3b - Changes from 3.2.2b
Bug Fixes
* Fixed req.sendfile(filename) sends incorrect number of bytes
when filename is a symlink. Added a unittest for POSIX platforms.
MODPYTHON-84
* Fixed ./configure problem on IRIX platform. MODPYTHON-80
On a broader note, this is the first shot in a longer discussion I'd
like to kick off about mod_python development practices. I'm not talking
about anything earth shattering - no palace coups or anything - just the
things we can do to improve mod_python and maybe speed up the release
cycle a tiny bit. ;)
Best Regards,
Jim
> On Fri, 28 Oct 2005, Jim Gallacher wrote:
>
>
|
|
|
|
|