| 1 |
On Sun, Apr 21, 2013 at 10:11 AM, Denis Dupeyron <calchan@g.o> wrote: |
| 2 |
> But nobody owns anything in Gentoo. As a developer |
| 3 |
> you're not king of the hill but servant of the users. The only way to |
| 4 |
> make yourself more relevant is by doing a better job, not by barking |
| 5 |
> at the others to protect your territory. |
| 6 |
|
| 7 |
I think that has to be qualified. |
| 8 |
|
| 9 |
If you're developing a package, and somebody else wants to add new |
| 10 |
functionality/features/etc, and is willing to put in the time to |
| 11 |
support them, then yes, it isn't your territory, and they can |
| 12 |
co-maintain. |
| 13 |
|
| 14 |
However, if somebody just commits something to your package, and it |
| 15 |
causes you headaches, and they aren't committing to long-term |
| 16 |
maintenance of the package, then yes, you can revert, etc. |
| 17 |
|
| 18 |
The bottom line is that package maintenance is a long-term commitment. |
| 19 |
You can't modify an ebuild and walk away, in general. Oh, sure, if |
| 20 |
you're just renaming a dependency or something there is room for |
| 21 |
exceptions. However, you don't change how a package works without |
| 22 |
cooperating with the maintainer, or becoming one yourself. |
| 23 |
|
| 24 |
The alternative is a Gentoo where packages that are working just fine |
| 25 |
get abandoned because somebody messes with them, and then the |
| 26 |
maintainer isn't allowed to maintain them the way they like and so |
| 27 |
they find something better to do with their time, leaving nobody |
| 28 |
maintaining the package. |
| 29 |
|
| 30 |
I don't know the specifics of this case so nobody should take this as |
| 31 |
finger-pointing unless it is your conscience doing the pointing. |
| 32 |
Maintainers don't "own" packages, but it is in everybody's interest to |
| 33 |
keep maintainers happy. Any dev can step up and co-maintain any |
| 34 |
package, but they have to be in it for the long term. If you don't |
| 35 |
like how somebody else is maintaining their package, and you're not |
| 36 |
willing to assume responsibility for it long term, then just consider |
| 37 |
yourself an end-user, and pretend you don't have commit rights. The |
| 38 |
only exceptions to this apply to projects like council, QA, etc, and |
| 39 |
those should represent even larger long-term commitments (and for the |
| 40 |
most part these bodies use more discretion anyway). |
| 41 |
|
| 42 |
Rich |
Archives