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