1 |
More and more, I am finding developers who are afraid to touch packages |
2 |
for even minor things if they're not the maintainer. This is a sad |
3 |
state of affairs and not the reason we have maintainers. We have |
4 |
maintainers to assure that a package is being taken care of, not to |
5 |
establish some kind of "territory" over that package. Because of this |
6 |
misconception, I would like to come up with and document a listing of |
7 |
things that any ebuild developer can feel free to do to any package |
8 |
*without* maintainer consent. These are generally all minor things, but |
9 |
things that I think are important. I'm going to list off the things |
10 |
that I can think of, and encourage everyone else to speak up if I've |
11 |
missed something. |
12 |
|
13 |
- HOMEPAGE changes |
14 |
- LICENSE changes |
15 |
- arch-specific patches/dependencies - If someone is requesting KEYWORD |
16 |
changes on a package and it requires a patch or additional dependencies |
17 |
for your architecture, you are not only permitted, but really are |
18 |
required to make the necessary changes to add support for your |
19 |
architecture. |
20 |
- Typo fixes |
21 |
- SRC_URI changes - If the source has moved, feel free to fix it. We |
22 |
shouldn't have to wait on the maintainer to fix something this simple. |
23 |
- *DEPEND changes due to changes in your packages - If a package that |
24 |
you maintain moves, splits, or otherwise changes in a manner that |
25 |
requires dependency changes on any other packages in the tree, you |
26 |
should make those changes yourself. You're free to ask for assistance, |
27 |
of course, but you have the power to make the changes yourself without |
28 |
asking permission. After all, you're the one "breaking" the package, so |
29 |
you should be the one to "fix" it. |
30 |
- Manifest/digest fixes |
31 |
- metadata.xml changes |
32 |
|
33 |
There's a couple more that I wouldn't mind seeing as things developers |
34 |
can do without the maintainer, but I can see how these might be a bit |
35 |
more controversial, so I'm asking for input. |
36 |
|
37 |
- Version bumps where the only requirement is to "cp" the ebuild |
38 |
- (for arch teams) Stabilization of new revisions of an already stable |
39 |
package - An example of this would be being able to stabilize foo-1.0-r2 |
40 |
if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is |
41 |
stable. |
42 |
|
43 |
So, what do you guys think? |
44 |
|
45 |
-- |
46 |
Chris Gianelloni |
47 |
Release Engineering Strategic Lead |
48 |
Alpha/AMD64/x86 Architecture Teams |
49 |
Games Developer/Council Member/Foundation Trustee |
50 |
Gentoo Foundation |