Phillip J. Eby wrote: > 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 is no information about last successful run when you start from scratch. > 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! I think bear and I are pessimistic because we have experienced problems with something you and many others assume will just work. I guess that was one of our hidden agendas in proposing the sheriff duty, to make others see there are problems. I don't think there is a single systematic reason for all failures, although some problems are more common than others. Some of these can be mitigated by better automation. But even when everyone truly tries to do the right thing all the time, mistakes eventually happen and things break, sometimes spectacularly. > 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) There are degrees of importance. For example, I think checkin comments are very important and should contain lots of information. Some others disagree about the importance, and think various parts I think are important can be omitted. Discussions haven't lead to consensus. So we are at the status quo where everyone does pretty much what they want, because nobody considers it so important as to take really drastic measures to force a resolution. >> * 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. Changes in comments and docstrings only. Those could be checked by parsing the diff, but that's quite a bit of work. And criteria tend to change. >> * 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. That adds quite a bit of overhead even I would be reluctant to accept. I have no trouble with requiring a patch and review in a bug, but often I find that I have small change suggestions that don't require another review IMO (like, change all variable names x to y). And that actually does nothing for the cases where a review is not required. Currently we also have a lot of flexibility in being able to patch several bugs in one checkin. Although this can also cause problems... > 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. I am not actually complaining about those cases, they are perfectly understandable. But when the tree has been closed from 30 minutes to two hours and there are still checkins... Or the tree has been on fire for hours or days... -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
