Doing away with changelogs

Alexandra Ellwood 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
> evaluation.

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  
us.  :-)


Alexandra Ellwood <lxs at>
MIT Kerberos Development Team

More information about the krbdev mailing list