Re: mechanisms for reviews needed

[Russ Sherk]

(Sorry for top post but it just don't fit no where)

I think that the above can be summarized thusly:

- Developers can't [be trusted to] create perfect code
- Management requires accountability for code changes
- There must be a stable version of a product at all times

CVS can _aid_ in providing controls on source code.  It can not 'do it
all' (well, it can but do you have the resources to develop all the
necessary additions?)

So, and this has been done many times by many companies, CVS should be
used as part of your process.

To make a change, there are many hoops to jump through.  The hoops
should be part of a clearly defined process which should be tracked
using various tools along the way.  As of yet there is no all
encompasing tool (could be wrong here but at least there isn't one
that is affordable to a small organization [read free]).

- Product managers: propose changes, approve changes, ensure safty
-- use: bug tracking sys, email, requirements
-- relys on: Architects

- Architects/Managers: design changes, review changes, accept changes,
ensure safty
-- use: cvs (for review and acceptance), bug tracking sys, email, requirements
-- relys on: PM, developers

- Developers/Engineers: code changes, [ensure safty]
-- use: cvs, bug tracking sys, email
-- relys on: Architects

(The above is sort of clumsy, but you get the idea.  Ideally there
should be a pretty diagram showing all the components and
interactions.  If you don't get the idea: it is supposed to show that
in the code change process, there are many tools that get used by
different people to complete the task and ensure product safty.  Most
of the tools will continue to be used regardless of changes to CVS.)

What Jacob wants is for CVS to do a not insignificant chunk of that
process 'out of the box'.  What he hasn't thought about is that that
chunk extends its tendrils into other parts of the process.  I don't
think that CVS was desgined to be the glue for a code management
process.  It might be good though to have a standalone
application/system that integrates nicely with cvs instead of a
collection of addon scripts (like cvs_acls, watches and commitinfo
scripts etc.)

</mytwocents>

Oh, and I agree with Jim about the branching.  Make unsafe changes on
a dev branch.  Have it approved.  Merge it into the mianstream.

--Russ

On 8/3/05, Jim Hyslop <address@hidden> wrote:
> Jacob wrote:
> > Mark D. Baushke wrote:
> >> This is not a problem. A developer should be judged on the quality of
> >> the work they commit.
> >
> >
> > But that's to late. The code is already in the repository
> > and you don't even necesserily know about it!
> 
> "cvs watch add" will tell you whenever a commit has been made.
> 
> > Beleve me: In two years, no VCS will come without this feature!
> > This is all part of the XP/Agile/Test-driven/Pair-programming
> > shift we are experiencing. If any of you are responsible for
> > the CVS future you better plan for this feature sooner rather
> > than later.
> 
> I fear you have drastically misunderstood XP, Agile, TDD and
> pair-programming. They are all about _trust_ - your model clearly states
> "I don't trust you to write good code."
> 
> --
> Jim
> 
> 
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/info-cvs
>