automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Is a ChangeLog file realistic if /lots/ of developers adding /lots/


From: cs
Subject: RE: Is a ChangeLog file realistic if /lots/ of developers adding /lots/ of changes?
Date: Wed, 25 Jun 2003 13:57:26 -0700

This overhead will take work and commitment from people.  How much improvement
can this deliver?? 10%? 50%? 500%?

Is this advice meant only for large (>10? >100?) development groups???

The reason I am asking is that I usually work on projects with <10
developers.  Things usually get done somehow regardless.

(I got a bad deal when I went crazy about OOP and decided
to do everything object oriented only to discover that small
projects don't necessarily benefit from OOP.  Sometimes
OOP can even *slow down* a little project.  I hope this
ChangeLog business is not another "OOP")

Chris




> -------- Original Message --------
> Subject: Re: Is a ChangeLog file realistic if /lots/ of developers
> adding  /lots/ of changes?
> From: "Thien-Thi Nguyen" <address@hidden>
> Date: Thu, June 19, 2003 9:04 am
> To: address@hidden
> Cc: address@hidden, address@hidden
> 
> address@hidden:
> 
>    If you have any advice or ways to streamline the process I would
> very
>    much like to hear it.
> 
> spend one hour a week as a group reading change logs (and only change
> logs -- no code!) for the week preceding.  discuss applicability of
> changes, especially whether or not the change introduces new problems.
> note change/changeback pairs.  characterize and categorize changes to
> determine if a larger-scope redesign is indicated (or rather, soon to
> be
> indicated :-).
> 
> over time, this will streamline things because your group will be able
> to recognize useless (or less than optimal) changes that should never
> have been made in the first place, and thus reduce that kind of noise.
> you might also develop ability to pre-emptively figure out more direct
> and more robust changes to make.
> 
> basically, to understand the code is one thing, to understand how you
> change your code is the next best thing, and to understand how you
> understand how you change your code is the best thing.  change logs
> can
> help you do this.
> 
> thi




reply via email to

[Prev in Thread] Current Thread [Next in Thread]