| 1 |
On Fri, Nov 23, 2012 at 9:15 AM, Ian Stakenvicius <axs@g.o> wrote: |
| 2 |
> .. For certain things, I think it would be very beneficial for this |
| 3 |
> to be true (other dev's welcome to touch) across the tree. Maybe if |
| 4 |
> there is enough general support for it, we should change our default |
| 5 |
> of "never touch a maintainer's package without permission of the |
| 6 |
> maintainer/herd", to "OK to touch unless package metadata explicitly |
| 7 |
> requests not to" ...? And we can put a tag in the metadata to |
| 8 |
> indicate this (or even to indicate what other dev's can and can't |
| 9 |
> touch -- ie, can touch *DEPEND, can bump EAPI, cannot add features, |
| 10 |
> cannot bump)? |
| 11 |
|
| 12 |
Honestly, I like the maintainer/herd system - it promotes some kind of |
| 13 |
consistency and accountability. If everybody just goes poking at |
| 14 |
random ebuilds anytime they want to then that will tend to lead to |
| 15 |
chaos. |
| 16 |
|
| 17 |
Why not just do everything BUT commit the ebuild, and then just attach |
| 18 |
the fixed ebuild to the bug instead? That really isn't any more work |
| 19 |
for those doing the work, it allows users affected by the bug to |
| 20 |
download the fixed ebuild instantly if they want to, and it still |
| 21 |
allows the maintainer to be a quality gateway. |
| 22 |
|
| 23 |
Even making it voluntary for maintainers to invite help creates some |
| 24 |
risk that users will be subjected to uncoordinated updates/etc. If |
| 25 |
you want to avoid that, then the checklist for changing random |
| 26 |
packages will likely grow so large that nobody will do it anyway. |
| 27 |
|
| 28 |
If you know a lot of about a package or a group of packages, just add |
| 29 |
yourself as a maintainer... |
| 30 |
|
| 31 |
Rich |
Archives