At 12:19 PM 12/7/2005 -0800, Heikki Toivonen wrote:
- when restarting from scratch there is no information to determine what
changed in this cycle (actually, everything changed). maybe we don't
care about automating this edge case
I would simply use the last successful test run's revision number as a
basis for determining "what changed" since the last success.
- there's nobody to make sure that people actually act on the email, or
that they even are there to read the email in the first place (I would
expect the sheriff to call if there is no response to IRC or email ping)
We could manage that through escalation - first failure email is to
developers, second failure is to sheriff, third to Dev list. Or something
based on time the failure has been outstanding without a response.
Again, what bothers me about this is what it says about the
organization. Are we *so* down on each other that our assumption is that
people don't want to do the right thing? If so, that's a *much* bigger
issue than our build mechanisms or policies!
We already have a guideline, but some people are not following
it - sometimes by accident, sometimes systematically because they
disagree with the guideline.
Then our organization is in need of improvement, because we are doing one
or more of the following:
1. failing to build a consensus,
2. failing to enforce an established consensus, or
3. making a big deal out of something that's not actually important to the
organization (which is really just a variant of #1)
Even though I am generally process-oriented, I am not so sure I would
want some script prevent me from committing because of some format issue
in the commit log - what if the script is simply wrong for this
particular instance?
Then you edit your message and try again; no harm done unless your SVN
client doesn't let you do that.
* Although maybe theoretically possible, it seems like a far stretch to
say the script can check if the checkin type was allowed (for example,
only blocking bugs + comments + docstrings on 0.6 branch where blocking
bugs need a bug number an a reviewer).
When you say "comments + docstrings", what do you mean? The other facets,
like having a reviewer for the exact patch and having a blocking bug
certainly seem like objective criteria to me, that can be checked using
available data.
* I don't see any 100% reliable way to check that the bug number was
actually correct.
If a review is required, then there should be a patch attached to the bug
whose contents match the commit.
* Did the checkin comment actually explain anything, or was it more or
less just some filler to get past the format checker?
One difference is that it's harder to rationalize omitting information if
the fields are all right there. But again, see my comments about
organizational issues, which will not be resolved by automation any more
than they will by rotating sheriff duty.
Btw, note that we already get a failure message on IRC. In my experience
people ignore them. Maybe they wouldn't if the message specifically
mentioned their nick.
Exactly. 90+% of tinderbox failures have absolutely nothing to do with me,
so even if I set up audible notification for those IRC messages, I would
quickly learn to tune them out.
Also, Tinderbox very prominently states when the tree is closed. You are
supposed to check Tbox before checking in. And bear also sends out
email. Yet we still get a few checkins when the tree is closed every now
and then.
Which is an indication that the *process* is broken, not that the
developers need to be whacked harder!
Frankly, if the process you're describing were a program whose design I
were reviewing, it would get a failing grade for inherent concurrency
bugs. It only seems not to be broken if you're on the build/release
management side, because you always know what the status is or is going to
be. On the developer side, it can sometimes take me a minute or two to
write a good commit message, during which time the tinderbox status could
change. This fact alone guarantees that there will sometimes be checkins
when there shouldn't be.
The only sane way to manage checkin traffic control is for Subversion to
reject checkins. Anything else *will* produce "race condition" failures,
which we then get to beat up the developers for, even if it's not their fault.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
