| 1 |
On Tue, Jul 2, 2013 at 10:59 AM, Donnie Berkholz <dberkholz@g.o> wrote: |
| 2 |
> |
| 3 |
> It seems to me that there's a couple of issues that really bother people |
| 4 |
> here: |
| 5 |
> |
| 6 |
> - The maintenance burden of any additional code; and |
| 7 |
> - Overriding a maintainer's decisions on existing code. |
| 8 |
> |
| 9 |
> My suggestion helps to deal with the former, while I believe Rich has |
| 10 |
> made a good point for the latter as part of larger changes that are |
| 11 |
> either council-supported or have general consensus. When we voted GLEP |
| 12 |
> 39 in ourselves (or joined while it existed), we agreed to respect the |
| 13 |
> decisions of the leadership and structure we chose. |
| 14 |
|
| 15 |
I don't think most of the recent controversy has been over existing |
| 16 |
code, but rather the addition of new code (though a two-line |
| 17 |
insinto/doins is stretching the meaning of "code"). However, if a |
| 18 |
controversy broke out over existing code I'd feel the same about it - |
| 19 |
as long as the changes were sensible and well-supported by a |
| 20 |
project/etc I would not want maintainers to block them. |
| 21 |
|
| 22 |
The original question was, "Do you think package forks or |
| 23 |
split-packages FOR SINGLE FILES would improve user experience?" |
| 24 |
(emphasis mine) |
| 25 |
|
| 26 |
Rich |
Archives