Doing away with changelogs
lxs at MIT.EDU
Tue Apr 18 11:49:56 EDT 2006
On Apr 18, 2006, at 10:53 AM, Nicolas Williams wrote:
> On Tue, Apr 18, 2006 at 10:30:54AM -0400, Alexandra Ellwood wrote:
>> It sounds like the problem people use the Changelogs to solve is
>> "what change introduced this new behavior I don't like."
>> I suspect this need would be fulfilled by just improving our release
>> notes so that they list all the bugs fixed and the svn commit lines
>> to show what files were impacted by each change. Associating each
>> change with a bug number would in fact be an improvement over the
>> Changelogs since you'd know what bug needs to be reopened/referenced
>> once you discover which change broken things.
> I agree, list bug/RFE IDs and synopsis in the release notes.
>> Given the size of our project such a list would have to be
>> autogenerated and provided separately from the overview list in the
>> release announcement email -- at least in major releases.
> Also, this requires discipline, namely ensuring that every commit is
> associated with a bug/RFE with a useful synopsis, description and
We've had this for a while now: every commit which changes files in
the krb5 repository must have an associated bug number. In order to
make this feasible, we have hooks between svn and RT such that commit
messages of a certain form automatically generate or modify RT bugs.
>> If one of the people asking for this functionality wanted to
>> contribute a more sophisticated release notes generation process for
>> our release which provides the content they need, I suspect we would
>> be happy to consider it for inclusion in our release process. Our
>> entire developer community has access to the systems necessary to
>> write these scripts (svn repository, RT bug tracking database). Even
>> if we don't end up taking such a system you can still provide your
>> own release notes for our releases.
> You still need a human to write up a summary that lists salient
> features/bugs added/fixed by the release.
We already include such a list with our release notes. I don't think
there are any plans to stop generating that list. Note that the
release notes list is usually derived from the feature/bug fix
requirements for the release. The requirements list is generated
during our planning meetings.
What I was talking about above is something autogenerated which isn't
checked by humans (and thus can't replace the release notes). It's
just a snapshot of the release's RT/svn data for the developers who
don't want to mirror or interact with our bug database and subversion
repository. Such a script is technically feasible, we don't have the
resources to do it. And since we do use our bug database and
repository we would prefer to spend our resources fixing bugs and
adding features. Hence my suggestion that someone else write it for
Alexandra Ellwood <lxs at mit.edu>
MIT Kerberos Development Team
More information about the krbdev