tor 2012-08-16 klockan 23:11 -0600 skrev Alex Rousskov: > I am not annoyed at the failures -- we all commit broken code once in a > while, and there is currently no good way to prevent even simple build > failures.
Yes.. > I am somewhat annoyed that some failures result in commit reversal (with > unusable or contradictory information as to the reason for the reversal) > while others are not (even after detailed reasons have been provided), Reversals are not routine. There is no automatic reversal, instead it is up to each and everyone to decide on when reversal is appropriate and when not. Ok, here is a proposal on a little policy on the topic on how to handle others bad commits: trunk: 1. If possible, fix it. 2. If not, nag the person who committed the problematic code. 3a. If no response in 24 hours and it's blocking other things (including test farm builds) then revert the commit with a notice to squid-dev. 3b. If still broken after 7 days of discussion and attempts to fix then revert the change. 4. Let it mature in a development branch, and submit for merge again when the issues have been resolved. numbered branches: 1. If possible, fix it. 2. If not, nag the person who committed the problematic code. 3. Let the release manager decide on reverting It's a real pity bzr do not have a "unmerge" operation. Currently reversals are quite intrusive and may merge to the branch where the feature was developed erasing it from there as well. > but this is _not_ the reason I am asking who is responsible for fixing > trunk -- I do really need to know whether this is something I should be > working on (to avoid two different people working on the same bug). "responsible".. is the one who takes on the bug in question. Regards Henrik
