Peter Milliken wrote:
[snip]
Seems we're getting a little off topic here, so I just snip what's not
relevant to Subversion and TSVN.
> 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
And until that stage is reached, the devs shouldn't even _see_ those
issues in the issuetracker (if you don't want them to work on those).
And that's the job of your issuetracker, not Subversion or TortoiseSVN.
> 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
May I propose a little different approach:
6. CR is committed to the repository
a) CCB receives the commit email and starts reviewing the change
b) the build engineer does some more tests.
7. If the review and the tests (6a and 6b) showed that something isn't
right, then revert the commit and have a talk with the developer. That
way the dev will learn to work better next time (a talk helps here a
lot, and also that his/her whole work gets reverted - that's a punch on
the ego for them and they will improve their work next time).
> 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 :-)
Hit the devs head against a wall if they don't write useful log
messages. Define a log message template/standard which they have to
follow. The ones that don't you have to talk to - if that doesn't work
then you might be better off firing them and hire better ones.
> 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
> :-)).
I know such managers just too well ;)
> 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 agree that _some_ paperwork and process is necessary. But if that part
is more than 20% of the total work, then your process and paperwork is
wrong.
> 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 :-))....
And you can really guarantee that your supervisors would find such an
unauthorised change in fix for an issue that's 50kb or bigger? From my
experience I have to say that the supervisors are usually bureaucrats,
paper-people and (sorry to say that) idiots. Sure, they can talk very
well to the management people and convince _them_ that they're good at
their jobs, but they don't know jack about programming, software or (in
my case: engineering).
So forgive me if I doubt that your whole supervising process really works.
> 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
> :-)
Not really. If you have a good team where the devs talk with each others
then you won't get into anarchy.
> 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" :-)
That looks to me as if you didn't write the goal of the project clearly
down on paper and didn't explain it to the devs. If devs don't have a
clear and defined project to work on, then you shouldn't be surprised if
it goes everywhere but where _you_ though it should.
> Somebody said it once - herding programmers is like herding cats :-)
So they're very easy to handle then - just give them some milk and a
warm place to sit ;)
> 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"
If you blame a whole team, the team will first share the blame equally
among them. But since they're the ones working together they will know
who's really responsible, but they will also know if it's someone who
just made a mistake or someone who never listens to
rules/advice/standards. The team will then "punish" the responsible ones
according to their real guilt.
My mom always said: only those who don't work at all can't make mistakes
- if you work, you make mistakes. So I really _hate_ the idea to blame
_one_ person for something that went wrong when really a whole team did
the work.
> 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 :-)
I think you had too many bad experiences. ;)
> 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...... :-)
You're misunderstanding the Subversion project rules. The votes are not
for new features, but for fixes that should go in or not. If a fix has a
too high risk of breaking other things, then it doesn't get enough votes
and won't get in. And if one dev thinks that it _will_ break something,
then a -1 vote is enough to block that issue from going in.
Ok, let's not get any futher with this discussion. I think you made
yourself clear and showed the problems which may arise, and I made my
point too (I think ;). I know you can't convince me and I can't convince
you. I guess we just had very different experiences working on projects.
You had bad experience with devs which had too much freedom, and I had
bad ones with too restrict projects where the whole team lost the
motivation and soon after that the best team members quit, one after the
other.
So to sum it up: most things you mentioned should be done/enforced by
the issuetracker, and most other things are not (at least not yet)
possible with Subversion.
hope your next projects are going better
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Aug 19 21:35:49 2004