| 1 |
On Tue, May 31, 2011 at 12:05:03AM +0200, Andreas K. Huettel wrote: |
| 2 |
> Am Montag 30 Mai 2011, 23:55:52 schrieb Brian Harring: |
| 3 |
> > If someone has a definition that is commonsense, then propose it- the |
| 4 |
> > current "you must log everything" is very, very heavy handed and |
| 5 |
> > basically was a forced situation since QA cannot make folks behave |
| 6 |
> > when the rules are reliant on common sense. |
| 7 |
> |
| 8 |
> Well how about "any change that can influence the behaviour of (portage|your |
| 9 |
> favourite package manager) in any way or present the user with different |
| 10 |
> output"? |
| 11 |
|
| 12 |
Mostly correct, although the problem there is 'influence'; consider: |
| 13 |
|
| 14 |
src_unpack() { |
| 15 |
bunch of code |
| 16 |
} |
| 17 |
|
| 18 |
being changed into |
| 19 |
|
| 20 |
new_func() { |
| 21 |
bunch of code |
| 22 |
} |
| 23 |
src_unpack() { |
| 24 |
invoke new_func |
| 25 |
} |
| 26 |
|
| 27 |
That should have no influence, thus not being ChangeLog'd. The |
| 28 |
problem is when the dev screws up, and it *has* an influence but no |
| 29 |
ChangeLog. |
| 30 |
|
| 31 |
A more real world example is people abusing eval and other things |
| 32 |
(python eclass for example)- folks can/do argue that it has no |
| 33 |
influence, but the complexity means it may have unexpected affect. |
| 34 |
|
| 35 |
That's the crux of the issue, and it comes down to common sense. |
| 36 |
Come up w/ a sane policy for things like that and I'll owe you some |
| 37 |
beer. |
| 38 |
|
| 39 |
Either way, for the rest of it, as Diego said, LGTM. I'm just |
| 40 |
nitpicking here to make it absolutely clear to people where we start |
| 41 |
running into policy issues. |
| 42 |
|
| 43 |
~brian |
Archives