| 1 |
On 08/14/2010 10:29 AM, Markos Chandras wrote: |
| 2 |
> So do I. Fixing your package and you don't even bother to send a *ready to go* patch |
| 3 |
> upstream seems like a bit rude to me as well. Perhaps, we do have a complete |
| 4 |
> different point of view in this one. |
| 5 |
> Recent example is Chí-Thanh Christopher Nguyễn who thanked me for fixing his |
| 6 |
> package, asked me to attach the patch so *he* can send it upstream. I thought |
| 7 |
> that was the *default* policy. Anyway. I should talk to each maintainer |
| 8 |
> separately when I fix his package. Seems to me is the best approach |
| 9 |
|
| 10 |
My two cents. In my opinion, whether a commit is good or not depends on |
| 11 |
whether it left Gentoo as a whole in better or worse shape than before |
| 12 |
it was made. |
| 13 |
|
| 14 |
Here it sounds like we had QA problems before the commit, and no QA |
| 15 |
problems after the commit. Maybe the maintainer has some work to do |
| 16 |
now, but he had it to do anyway, and the maintainers have less work to |
| 17 |
do now than they did before the patches were made. |
| 18 |
|
| 19 |
Now, if he had broken something due to a sloppy commit I'd be more |
| 20 |
concerned. |
| 21 |
|
| 22 |
Many hands make for lighter work. The best way to have many hands is to |
| 23 |
make individual tasks easier. 1+1+1+1+1 is going to happen faster than |
| 24 |
3+2, since nobody ever gets around to doing 3. |
| 25 |
|
| 26 |
If we give devs an ultimatum like "fix it all or don't fix anything" |
| 27 |
guess which one they'll pick? |
| 28 |
|
| 29 |
Rich |
Archives