[...]
> > 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?
Define "obvious" :-)
You might want to try working on a fixed price contract one day - a
wonderful experience :-) The bug might well be "obvious" - but if the client
didn't "pay for it" then it shouldn't be fixed! (at least until an agreed
price, schedule impact etc etc is agreed upon) :-) I have seen projects
cancelled because of "obvious" bugs and developers (not management!) that
decided they needed to be "fixed" :-)
Fixing "obvious" bugs is how many projects end up never being complete -
feature creep etc etc until either the supplier goes out of business (due to
having really "helpful" employees) or the customer cancels the contract -
because they can't get what they *really* want - as opposed to what they
originally *asked* for :-)
> > 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.
>
Sometimes the developers process the "bug" before the appropriate individual
in project authority has a chance to close it as "wontfix" :-) This is
heavily dependent on the features of the bug tracking system i.e. the
typical phases you want a change request (CR) to go through are:
1. raise CR
2. CR is assigned to somebody for analysis (by the Configuration Control
Board - CCB)
3. analysist proposes "solution(s)" - which might include "wontfix" because
the CR is outside the scope of the current contractual arrangement
4. "proposed solutions" are reviewed by CCB and then decision as to whether
it proceeds further is made - and which of the possible solutions are
implemented if "proceeding" is the outcome
5. CR is (finally) assigned to a developer for processing
6. CR is submitted as complete -
a) CCB nominated individual verifies that actual work is in line with
what was approved.
b) changed files are sent to a " build area" where a build engineer
(independent individual from developer) verifies correctness i.e. code
compiles and builds executables, (nominated) regression testing passes,
original problem is fixed
7. changes on CR are then placed into the repository and made available for
use by the rest of the project - ideally for tracking purposes this is an
atomic commit with the tracking ID in the log message
I realise that most version control systems do not allow/foster this model
at (7) - developers have direct access to the repository and thus they quite
often put source code that doesn't actually compile into the repository,
they put code in with "mandated" comments (mandated by a hook script :-)) of
"fixed" or "changed" - so you end up with revisions of garbage in the
repository, revisions with no useful "tracking" value etc etc :-)
You could easily argue that "good" people don't do this - and I agree, but
when you are forced to staff a large project the ratio of good to bad is
often surprisingly low :-) I have seen project managers hire complete
incompetents because their job (in the short term at least) was to have
people occupying seats - the fact that they actually put the project
backwards doesn't seem to occur to many project managers (in my experience
:-)).
So as you can see from these steps, version control tools such as svn, cvs
and PVCS don't really help a lot at all. That is not to denigrate them in
any way - they are very good at what they do, but the focus of developers of
such tools are really rather limited - probably because they are done by
software engineers and what software engineer worth his salt wants to get
involved in a process like I have described above? :-) After all, all we
want to do is produce a working product, don't we? :-) So why let process
and paperwork get in the way? :-)
> > 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.
>
Oh? and what stops a developer from changing a source file without
"authorisation"? :-) If I had a nickle for every time somebody made an
(unauthorised) change because they were poking around fixing a problem and
noticed a bit of (working) code that could be "done better" - and then
didn't regresion test that change as well! (because we don't like writing
tests and test documentation do we? - but all very necessary with true CM
practices :-))....
But I agree, this is a job for the tracking tool - but you still need very
tight controls when you have large numbers of people working on the same
project. Projects seem to reach a certain point where the numbers of
developers, combined with total freedom to do as they will equate to anarchy
:-)
[...]
> >
> > 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.
>
Agreed, file locks don't help this situation at all - they are aimed purely
at making sure two developers don't work on the same file at once. They have
no benefit to any higher level workflow/process.
This will seem dragonian, but one a project I worked on, we removed write
access to the repository (PVCS) completely from the developers - they could
change source files to their hearts content, but without an ID from the
tracking system and approval from their team leader (simple scripts that
allowed tracking source files against IDs and generating difference listings
automatically), the changed files had no way of progressing through the
system and into the repository. This measure was instituted in desparation -
too much freedom of access to the repository resulted in a project that was
quite literary "one step forward, two sideways and three backwards" :-)
> > 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.
>
Agreed - this gate must be guarded manually by a reviewer, no other way to
keep the horse from bolting through this one :-)
[...]
>
> 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.
>
Sorry mate, no personal aspersions intended here :-) I worked in large
projects (defence contractors) for 20 years in various capacities - often
looking after (team leader) a group of programmers. In any given group,
there were (on average) between 20 - 40% that I *couldn't* trust at this
very level! In the end I gave up that kind of position - the ulcers were
killing me, I returned to my first love and just write software - I am
responsible for myself only and have a hearty laugh when I follow a fellow
programmer in the repository and see 9 commits - each with either a blank
comment, or something like "changed" - and they still didn't fix the
problem! :-)
Please don't misunderstand me - the majority of projects are "small", they
have good people who are completely trustworthy and they don't need these
types of measure - but the people who are asking for features in svn for
tracking against ID's probably aren't in this situation - they are probably
(I could be wrong :-)) asking for this feature because they have found their
developers don't always follow "agreed practice" i.e. they can't be
"trusted" to do the right thing without at least a prompt! (so they forgot?
forgetting is just as bad as deliberately not doing something - in the end
the information is not where you want it!) I venture to suggest that even
with the prompt, some of the developers will see the requirement as just
unnecessary overhead and they will type in rubbish just to get the hook to
accept the entry :-)
Somebody said it once - herding programmers is like herding cats :-)
[...]
>
> 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...
>
When you have a situation of "blame the whole team" then you effectively
have no place to assign "blame" - and nobody "responsible" at all - because
all individuals will be equally guilty and who would penalise themselves?
:-) In the end *nobody* will accept responsibility. Sounds like my kids -
"well, Dad, it wasn't me, she did it"
Nice, cooperative projects with time up their sleeves might run this way,
but projects that are under severe time pressures never would i.e. "I have
my own work to complete, why do I have to OK anybody else's?" - "I'm sure
somebody else on the team will 'do the right thing' and review these
changes" :-)
But who knows? Perhaps I am being overly cynical here :-)
[...]
>
> 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.
>
Democracy is a wonderful thing - this approach clearly works for "freeware"
projects. And next time I'm on a fixed price contract (that was probably
underbid :-)) I'll make sure I recommend it. Based on your theory
programmers will flock to it and the project management will be able to take
their pick - instead of taking what they can get and having the good
programmers leave because the "bad" ones can't be trusted and end up making
the entire environment that much more difficult to work in :-)
I wonder how many customers would be prepared to accept a democracy of this
style? Not sure I would like programmers voting on what features I would or
would not receive in my next release of software that my business depended
upon...... Of course in a democracy they would have 1 vote also...... :-)
Clearly I have hit a nerve - you plainly think what I have suggested is
unnecessarily draconian - well, all I can suggest is that you try not to
take umbrage until you have actually experienced this kind of situation -
some of my best friends hated my guts at the outset of instituting these
kinds of measures on projects - but they came around in the end to agreeing
that they were very workable solutions and couldn't understand how the
project managed before they were in place :-) But I don't bang my head
against that particular brick wall anymore - these days I just check files
into PVCS and occassionally forget to put the tracker issue number in the
log comment :-)
Have a good day,
Peter
Warning: Copyright ResMed. Where the contents of this email and/or attachment includes materials prepared by ResMed, the use of those
materials is subject exclusively to the conditions of engagement between ResMed and the intended recipient.
This communication is confidential and may contain legally privileged information.
By the use of email over the Internet or other communication systems, ResMed is not waiving either confidentiality of, or legal
privilege in,the content of the email and of any attachments.
If the recipient of this message is not the intended addressee, please call ResMed immediately on +61 2 9886 5000 Sydney, Australia.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Aug 19 08:55:42 2004