| 1 |
On Fri, 03 Aug 2007 15:49:58 -0700 |
| 2 |
Chris Gianelloni <wolf31o2@g.o> wrote: |
| 3 |
|
| 4 |
> Why should someone have to go through all of that just to make these |
| 5 |
> minor fixes? Is it really necessary for someone to be required to try |
| 6 |
> to track down and contact the maintainer to tell them that they put |
| 7 |
> "ebiuld" instead of "ebuild" into an ebuild? This is my entire point. |
| 8 |
> Why are we forcing a process that only fosters inefficiency? It is |
| 9 |
> much simpler to say "if you see one of these, fix it" than to force |
| 10 |
> every single action to go through the maintainer. |
| 11 |
|
| 12 |
Well, for simple typos it's ok. But some of the things you listed might |
| 13 |
have a bigger impact: SRC_URI changes are ok when the actual files are |
| 14 |
the same, but if they are somehow different one should really check wih |
| 15 |
the maintainer to make sure it's still the correct file (same for |
| 16 |
verifying checksums, unless it's obvious). In the end it comes down |
| 17 |
that you have to know the consequences of a change, and assuming that |
| 18 |
the maintainer knows more about a package than you do he should be |
| 19 |
contacted for non-trivial changes (I'm not saying you have to wait for |
| 20 |
him at all costs). Of course if a package is plain and |
| 21 |
unconditionally broken it's ok to act first and talk later IMO, but |
| 22 |
communication is a requirement, not something you should try to avoid. |
| 23 |
|
| 24 |
One thing I completely disagree with however are the metadata.xml |
| 25 |
changes. Basically you're saying there it's ok to change the maintainer |
| 26 |
of a package without talking to the existing maintainer first (though |
| 27 |
I'm sure that wasn't your intention). |
| 28 |
|
| 29 |
Marius |
| 30 |
-- |
| 31 |
gentoo-dev@g.o mailing list |
Archives