| 1 |
On Sun, Aug 30, 2015 at 3:54 AM, Kent Fredric <kentfredric@×××××.com> wrote: |
| 2 |
> We've had to accept that upstream were being unreasonable, and fork |
| 3 |
> the problem and manage it ourselves. |
| 4 |
> |
| 5 |
> And now we have eudev. |
| 6 |
> |
| 7 |
> This is a very good example of "Gentoo standing in between upstream |
| 8 |
> and our users to protect our users from upstream". |
| 9 |
> |
| 10 |
> That's our job. To keep upstream accountable, and shield users from |
| 11 |
> their mistakes. |
| 12 |
> |
| 13 |
|
| 14 |
That's a pretty extreme example though. I can't think of a single |
| 15 |
other package where this was done. |
| 16 |
|
| 17 |
More typically Gentoo tends to follow upstream. If a small patch will |
| 18 |
allow broader compatibility/configurability we tend to deal with it, |
| 19 |
but if upstream goes in a different direction we tend to support it |
| 20 |
for the most part. |
| 21 |
|
| 22 |
Maintainers aren't required to maintain separate patch sets in |
| 23 |
general, beyond any fixes needed to comply with QA standards. |
| 24 |
|
| 25 |
The thing to keep in mind that in some cases this may be a matter of |
| 26 |
whether the package gets maintained at all. If a dev doesn't have |
| 27 |
time to deal with a messy upstream and we try to force them to do so, |
| 28 |
they will probably just make it maintainer-wanted and we'll see it |
| 29 |
treecleaned. So, there has to be a balance. In the case where a dev |
| 30 |
wants to upstream an issue the concern over managing this process is a |
| 31 |
valid one. |
| 32 |
|
| 33 |
I'd say that tracking the bug locally is recommended, but I'd hesitate |
| 34 |
to make it absolutely mandatory. |
| 35 |
|
| 36 |
-- |
| 37 |
Rich |
Archives