This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author skrah
Recipients eric.smith, mark.dickinson, python-dev, r.david.murray, skrah, yaubi
Date 2014-08-27.15:27:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20140827152739.GA19022@sleipnir.bytereef.org>
In-reply-to <1409148054.3.0.172008237155.issue22090@psf.upfronthosting.co.za>
Content
> I'm not going to argue this any further, but "recent" is exactly the point...if all of the bots had turned red you'd understand that it needed to be fixed *immediately* or the triggering change (regardless of what the actual bug was) backed out.  Since it isn't all the bots it isn't that critical, but eventually we want to make it critical (ie: someday it will be a requirement that *all* stable bots pass before a change gets *committed*...but that day is still a longer way off than I'd like, since I at least don't have much time for working on the workflow stuff).

How is this supposed to work though?  In this case 6c468df214dc and 227ce85bdbe0
need to be backed out, since they apparently also broke the OpenIndiana bot long
ago (why wasn't that discovered?).

However, I don't feel that it is my place to back them out, since I did not
commit them and might step on other people's toes.

I don't think that the burden of having green buildbots should be on the
person who commits something that *exposes* existing issues (unless, as
you say, *all* buildbots turn red).
History
Date User Action Args
2014-08-27 15:27:40skrahsetrecipients: + skrah, mark.dickinson, eric.smith, r.david.murray, yaubi, python-dev
2014-08-27 15:27:40skrahlinkissue22090 messages
2014-08-27 15:27:40skrahcreate