Okay folks, here's the deal: I'll volunteer to periodically (4-6 times a year should developments dictate) put together a Pike Update. As I see it, things that would be worthwhile in such a production might include:

Pike development updates (what's happening, what the plan is) Pike Tips Usage Articles Conference Information Pike-based application updates and information etc.

In order to do this, I need some help. I know that there is at least a little resistance to the idea, but having a changelog updated as changes get made would really help me (and other potentially interested parties) figure out what is going on.

The reasons I think that a changelog is necessary and beneficial include:

1. A new "feature" or change may involve 5 - 10 or more cvs checkins, the log entries of which may not hint at the actual change being made. 2. Sometimes, even those of us who might follow the changes religously might have trouble figuring out what's going on, or the significance of that change 3. Waiting until a release is made to find out what's happening, while dramatic, is really a bit of a problem from a planning perspective: people _using_ the software should really know what's changing as it happens. 4. Having an awareness of a change lets people plan for it when it's released 5. Allows interested parties to test and (heaven forbid) document the change, possibly helping you, the developer out.

I know that there are some people who feel that this is just extra work. To those, I say that someone is making the entry at the end, why not take a few seconds and describe the change (and take credit for it) when it's added. Not every checkin will prompt an entry, only those that complete a change or addition. If there's any doubt about whether a change merits inclusion, err on the side of over documenting and include it. An example of a few changelog entries I have made that represent a few hours of work on my part:

- SSL3 client can now present certificates to a server; server can request and validate a client certificate chain presented. (Bill Welliver) - SSL3 module now checks presented certificate chains for validity by examining effectivity, issuers, and completeness of certification chain. (Bill Welliver) - Added method Tools.X509.verify_certificate_chain() that can verify the validity of a chain of X509 certificates. (Bill Welliver)

This took me a total of 2 minutes to do, and might have taken less if the work were fresh in my mind. The third entry was one I included that would probably be cut from a release change log, but is certainly not wasted space.

I'd like to see a policy added for 7.7 that says if you check in a completed new or changed feature (module, major work, language behavior, etc), you add a brief entry describing what you've done. Any thoughts? Who can make this happen?

If anyone has any comments or would like examples of what I envision, please feel free to contact me.

Thanks,

Bill