Peter Milliken wrote:
> Just some food for thought - I have been through the entire Change Control
> issue/cycle on more than one large project ("large" in my case was a 40+
> programmer project), so I'll throw this into the arena as well since we are
> talking integration with bug tracking tools :-)
>
> WRT the entire CM question - Change Control is normally a big issue and
> major headache area for project management. On large projects it is
> incredible how many bug requests end up being processed by a developer
> before "approval" has been given for the bug to be even worked on!
You need an approval first before an obvious bug gets fixed?
> Some of them the project authority might not even want processed - ever!
And why not?
And if not, why don't they just close the issue as "wontfix" with a
comment why the issue won't be fixed? I think that's what they should do.
> i.e. these generally fall into the area of a thinly described feature
> request by a user/customer masquerading as a bug report. The appropriate
> project authority would most likely reject/place on hold the issue
> (depending upon the customer/user relationship).
That's the job of the issue tracker, not a Subversion client. If you
don't want developers working on not approved issues, you should
configure the issuetracker so that devs only can see approved issues.
> So if we are looking a integration with bug tracking tools, I would consider
> a good integration to include some form of approval mechanism *before* any
> code is changed i.e.
>
> 1. You can't work on any files until you have a bug issue "approved" for
> processing
Without a locking feature (which Subversion still lacks, but planned for
in 1.2) this isn't possible. And even then: Subversion is designed to
work without locking. So even the locking mechanism which will be
implemented soon, there are ways around a lock.
> 2. *any* file that is changed must be linked to an (approved) bug issue -
> this can be easily reviewed by a team leader to make sure *only* the
> authorised change is being worked!
That's in the proposal.
But you should know that there's no way to prevent a dev from using a
wrong (but approved) issue number.
> 3. any commits (prior to entering the repository) must be verified by
> appropriate project authority to make sure the agreed implementation has
> been followed i.e. good change control mandates that problems be analysed
> and possible solutions proposed to a CCB (Change Control Board) - the CCB
> approves a solution (which might be - implement it in the next release and
> not now!) I have seen enough cases of an individual doing things completely
> differently than what was desired - better to stop the code even before it
> gets into the repository.
That's not possible with Subversion. Either a dev has write access, then
(s)he can commit. Or they don't have write access and would have to
create a patch and send that to the authority.
But if I may ask: are there really people willing to work for you?
Because I definitely wouldn't! If I'm hired as a developer, but I'm not
trusted at all then I'm working for the wrong people. I can't work for
people who don't trust me.
> 4. The approval authority i.e. person who authorises a change to be commited
> to the repository, should be able to get a list of files modified against a
> particular bug and also a complete difference listing - all with one simple
> command.
>
> On these last two points, I know it seems unduely onerous and "big brother"
> - but wait until you have been called in on a long weekend because a team
> member decided to make some "other" changes while they were poking around in
> the source - and subsequently screwed things up in a major way - integration
> testing didn't catch it because the problem being solved was in "this" area
> but the (unauthorised) code that was changed was way over in *that* area -
> the portion that was not tested before the code went to the site for formal
> acceptance by the customer :-)
That's what commit emails are for. That way _all_ devs get them and can
review changes in the source. If then something still gets screwed up,
you have to blame the whole team.
Seems to me that you just want _one_ person (the "authority") you can
then blame when something goes wrong...
> This doesn't really follow the full work flow that I would like to see (
> :-)) but it does delineate some small portion of it :-)
>
> Also, procedures and practices depend very, very much on the life cycle that
> the software is in i.e. what strictures you would place on programmers in a
> development phase (the one we all like to be in! :-)) are very, very
> different to the strictures that you desire when you are in the maintenance
> phase!!!!!
Check out how Subversion handles this: a stabilizing branch is created
with a "STATUS" file where issues are listed which devs think should go
into the stabilizing branch. Each dev can vote on each issue. And then
before a release, only those issues with enough votes get merged back
into the branch from trunk.
Really, you should start to trust your devs a little more - I can assure
you that they will be much more motivated to work for you.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Aug 18 19:02:23 2004