On Wed, 7 Dec 2005, Phillip J. Eby wrote:
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!
+1
Then our organization is in need of improvement, because we are doing one or
more of the following:
1. failing to build a consensus,
+1, this sheriff thing is a very good example
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)
+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?
Just as with the tinderboxes, if the tools are flaky, the process is going to
be broken.
* 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.
+1
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!
+1
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.
+1
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
