1 |
On 27/02/2013 18:10, hasufell wrote: |
2 |
> a) if you break a provider on purpose, then you should feel |
3 |
> somehow responsible for the consumers and not just dump testing and |
4 |
> fixing on your fellow devs |
5 |
|
6 |
I'd say the only real mistake has been not keeping it masked to begin with. |
7 |
|
8 |
Just so we're clear with everybody, I would suggest, the next time |
9 |
somebody wants to introduce a disruptive change: |
10 |
|
11 |
1. commit it masked — this way even if it's going to mess up the whole |
12 |
tree you won't be blamed; |
13 |
2. ask me for testing — this happened in this case, but (1) was missed; |
14 |
3. make sure you're around to keep the pieces. |
15 |
|
16 |
I opened the bugs — I wasn't going to look into them any time soon, |
17 |
mostly because I got another huge bunch of bugs already — I started |
18 |
today, and after a while it became obvious (to hasufell) that many of |
19 |
them came down to the same issue; now I know and I'm not opening bugs |
20 |
for the same issue all over. |
21 |
|
22 |
Another common one I found myself simply because I noticed it while |
23 |
looking at the build log. |
24 |
|
25 |
I don't see a big problem with 3. as Michał might not have reacted yet, |
26 |
but it was not even 24 hours since he asked me to run the tinderbox. He |
27 |
might have caught the cmake issue himself, I don't know. |
28 |
|
29 |
So my final word is that yes, this was a screw up, no, not as big as it |
30 |
transpire from here. |
31 |
|
32 |
-- |
33 |
Diego Elio Pettenò — Flameeyes |
34 |
flameeyes@×××××××××.eu — http://blog.flameeyes.eu/ |