Commits to master in my absence
I'm a little frustrated to see what happened when I was away from a couple of days. I thought we'd agreed we'd queue up patches in a branch and then I'd take care of things when I got back.
I appreciate a serious bug was then found and a fix was committed against what I thought was agreed. This then opened the gates and more patches were merged with decreasing severity and in the end something got added which is just plain broken :(.
The problematic patch is:
and I've commented in emails elsewhere against the various attempts to further "fix" this.
I *really* need people to step up and start thinking about quality and the long term impact of changes rather than just X fixes bug Y which I'm hitting right now. This is particularly true if anyone wants to step into the position of doing final commit merging. You *have* to take the time to fully understand and review the changes you're adding and consider the big picture.
I'm really hoping that I can find people who I can share the final review/commit responsibility with but until people stop presenting me patches which I have to reject we're not going to get the point where they can work in that role :(.
This is particularly frustrating since I've seen people push patches they know to be lacking in quality just because they were running low on time and hoped they might get away with it.
Cheers,
Richard (a bit disappointed)
Quoted 28 lines · Richard Purdie
I'm a little frustrated to see what happened when I was away from a couple of days. I thought we'd agreed we'd queue up patches in a branch and then I'd take care of things when I got back.
I appreciate a serious bug was then found and a fix was committed against what I thought was agreed. This then opened the gates and more patches were merged with decreasing severity and in the end something got added which is just plain broken :(.
The problematic patch is:
and I've commented in emails elsewhere against the various attempts to further "fix" this.
I *really* need people to step up and start thinking about quality and the long term impact of changes rather than just X fixes bug Y which I'm hitting right now. This is particularly true if anyone wants to step into the position of doing final commit merging. You *have* to take the time to fully understand and review the changes you're adding and consider the big picture.
I'm really hoping that I can find people who I can share the final review/commit responsibility with but until people stop presenting me patches which I have to reject we're not going to get the point where they can work in that role :(.
Quoted 7 lines
This is particularly frustrating since I've seen people push patches they know to be lacking in quality just because they were running low on time and hoped they might get away with it.
Cheers,
Richard (a bit disappointed)
It was me.
since master was broken for arm (even qemuarm) after the tune overhaul It was a mimimum workaround since many devs were complaining about it I thought until we rework the tune overhaul this could be a survival path and at the same time tune overhaul for arm could be worked out. I was just thinking about making devs keep going.
But I apologize for this. Kindly revert it.
-Khem
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 3 lines · Richard Purdie
I'm a little frustrated to see what happened when I was away from a couple of days. I thought we'd agreed we'd queue up patches in a branch and then I'd take care of things when I got back.
So, I agree with everything you did say. But I'd also like to suggest we should have gone with "merge everything Monday" not "merge everything Wednesday before RP runs off". Yes, this would have meant either moving some testing, or having testing also pull from a different (merged) branch. And I too was "wait, what, more stuff went in? I thought we caught the big problem already".
- --
Tom Rini
Mentor Graphics Corporation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJONv2eAAoJEI4NMjfc3nJxudcIAMg7yMIdl648ZdRsFGAUTKTD HSP8lLzawtEcl1bxektShH7amCf45wHvlw36joNNt3dG78FwAfO9bozubZEypwcS N7YXBo8JVJVi1WUIni23CZor4I091Ubt0tEHFOk4iDIyU9B9q+T77xg2qn+r6RJN 7yNzs7XRffM8D2v7OxG/6kK4FvQDflVbnqEYkN+dE0rgUFOMUDdaSkB5JO0NShG2 yYLkXljRNJ24Of5crsuQ/F4Vqk86b41Ax9jYrdFUOl+qgdovbPs3ninKtbDgT9ez Adh8behhx/LvbQQNldOi0l/UakPAmEPHEjEBNxmKX/GoZjfLHN0nb4Ucy5sAtBM= =PIo2
-----END PGP SIGNATURE-----
Quoted 9 lines · Tom Rini
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 3 lines · Richard Purdie
I'm a little frustrated to see what happened when I was away from a couple of days. I thought we'd agreed we'd queue up patches in a branch and then I'd take care of things when I got back.
Quoted 6 lines
So, I agree with everything you did say. But I'd also like to suggest we should have gone with "merge everything Monday" not "merge everything Wednesday before RP runs off". Yes, this would have meant either moving some testing, or having testing also pull from a different (merged) branch. And I too was "wait, what, more stuff went in? I thought we caught the big problem already".
If I'd merged everything unexpectedly and not communicated the situation I think that would be bad. As it was, I did merge things but I also hopefully clearly communicated the issues and the expectation. Master is the development tip and some instability, particularly as new features merge is not entirely unexpected at this point in the cycle.
I'd hope we don't end up in a situation like that again, if we do, I'll see what other options there and weigh them up as the situation dictates.
Cheers,
Richard
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 23 lines · Richard Purdie
Quoted 9 lines · Tom Rini
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 3 lines · Richard Purdie
I'm a little frustrated to see what happened when I was away from a couple of days. I thought we'd agreed we'd queue up patches in a branch and then I'd take care of things when I got back.
Quoted 6 lines
So, I agree with everything you did say. But I'd also like to suggest we should have gone with "merge everything Monday" not "merge everything Wednesday before RP runs off". Yes, this would have meant either moving some testing, or having testing also pull from a different (merged) branch. And I too was "wait, what, more stuff went in? I thought we caught the big problem already".
If I'd merged everything unexpectedly and not communicated the situation I think that would be bad. As it was, I did merge things but I also hopefully clearly communicated the issues and the expectation. Master is the development tip and some instability, particularly as new features merge is not entirely unexpected at this point in the cycle.
Quoted 3 lines
I'd hope we don't end up in a situation like that again, if we do, I'll see what other options there and weigh them up as the situation dictates.
Yes, it was an intentional and communicated decision. I guess what my gut says right now is that while some folks are willing to live with some "it's broken, try again in a few days or go back to ...", a lot of the community expects things to be mostly working, and there was also some "ok, I want to expand / use this stuff, but..." that we ran into, which really is situation dependent. And yes, next time we will need to weigh the options once again.
- --
Tom Rini
Mentor Graphics Corporation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJONwn7AAoJEI4NMjfc3nJx2vQH/2u2MKHdqhsHNfoZoHlhPCJQ jk144kwp69HHVS9gKjiJCf1fkum9MTblT5V5VDIYgoD2yHDBnCe/P/9GWS8rlTcq lUweqPMDuWvoWPEGRWnNLPAnXP+bsWqoQLGEUuHkcmMag4yJsJSZYTmU6btTOSNa ON6Q4RnkTcD08AiHark/R5YHS46HaQ6tVyRpK3DgMUgfGVGnYa0EFzGG73p6q44x GKsXqNRverf4uu9KbnRTcciuxeIytGlZ3ewT9yHJBcKOjaT9a8FEkA03fHOIqRy/ VJnfjOL4NbdoSRa67INQm8nAnI20WzxCrkzZPJ/2+VXXCfrZ4TFiabUviocPpmA= =oTtt
-----END PGP SIGNATURE-----