| 1 |
Christian Faulhammer wrote: |
| 2 |
> Doug Goldstein <cardoe@g.o>: |
| 3 |
> |
| 4 |
> |
| 5 |
>> Jonathan Adamczewski wrote: |
| 6 |
>> |
| 7 |
>>> Doug Goldstein wrote: |
| 8 |
>>> |
| 9 |
>>>> That's what this commits review list feels like. |
| 10 |
>>>> |
| 11 |
>>> Nearly every suggestion (from Donnie and others) has been over some |
| 12 |
>>> issue that relates directly to either correctness or |
| 13 |
>>> maintainability. It doesn't matter if you can "rattle off |
| 14 |
>>> capabilities to a millimeter" - if they're not documented somewhere |
| 15 |
>>> (like, say, in the comments of the ebuild) then the maintainer that |
| 16 |
>>> comes after you gets to go and break it all over again. |
| 17 |
>>> |
| 18 |
>> Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild. |
| 19 |
>> Do it. I dare you. Then try to compile. |
| 20 |
>> Guess what? When it blows up... that's called INcorrect. The opposite |
| 21 |
>> of the right thing. |
| 22 |
>> |
| 23 |
> |
| 24 |
> You were kindly asked if is not possible to use, so why do you feel |
| 25 |
> attacked? Do a comment on it and everybody would be fine, even the |
| 26 |
> people that would have to maintain it some time in the future. If you |
| 27 |
> don't like the review process, just ignore it. |
| 28 |
> Reviews are not a way to show what kind of idiot the committer is, but |
| 29 |
> to improve the overall quality of the tree. Nothing more, nothing less. |
| 30 |
> |
| 31 |
No. You clearly don't understand where I'm coming from. I think the |
| 32 |
commits review is pointless and a waste of resources that could be |
| 33 |
better used doing other things. Since commits review is a cyclic process |
| 34 |
you will never achieve a perfect state that all developers commit |
| 35 |
perfect ebuilds to the tree since new devs come and go. And since we |
| 36 |
don't document any of this stuff properly in the devmanual, incoming |
| 37 |
devs have to constantly relearn the same lessons that previous incoming |
| 38 |
devs learned through the review process. Effective workers work in 4 |
| 39 |
stages, we're effectively with this approach remaining in stage 1 and |
| 40 |
never progressing and admitting we will never progress. |
| 41 |
|
| 42 |
> |
| 43 |
> |
| 44 |
>> The maintainer who comes after me would be someone with a experience |
| 45 |
>> with the package. Some bumkin isn't going to come to maintain package |
| 46 |
>> XYZ unless they know or use the package, and guess what? That means |
| 47 |
>> experience. |
| 48 |
>> |
| 49 |
> |
| 50 |
> Yes, and the same goes for GNU Emacs, I needed some time to figure out |
| 51 |
> what all those things did and I broke it several times because I tried |
| 52 |
> to be clever. Now we documented it and I think everyone coming after us |
| 53 |
> will have a less hard time to understand it. Better document it, you |
| 54 |
> never know what happens. |
| 55 |
> |
| 56 |
> V-Li |
| 57 |
> |
| 58 |
> |
| 59 |
Read the ChangeLog. It's there for a reason. It provides valuable |
| 60 |
knowledge and information about the package. I would expect any |
| 61 |
developer worth their salt to at least brush up on the ChangeLog for any |
| 62 |
package they are taking over. |
| 63 |
|
| 64 |
-- |
| 65 |
gentoo-dev@g.o mailing list |
Archives