1 |
<upstream hat on> |
2 |
|
3 |
Kent Fredric wrote: |
4 |
> I've always seen it as a case where Gentoo devs stand as a layer of |
5 |
> sanitization between downstream and upstream. |
6 |
|
7 |
This is the last thing I want. Did you play the whisper game as a kid? |
8 |
|
9 |
I want direct contact with the user who can reproduce the problem in |
10 |
the upstream bug tracker, anything else is absolutely suboptimal and |
11 |
will easily cause the bug to never get fixed at all. |
12 |
|
13 |
|
14 |
> Wherein reporting things upstream is good, but having a downstream |
15 |
> tracker for it is also good, so that when the bug is resolved |
16 |
> upstream, |
17 |
> that the consequences of it are known to be propagated downstream. |
18 |
|
19 |
I think a clever downstream would make sure to integrate with the |
20 |
upstream, by e.g. subscribing to all ticket resolution changes. |
21 |
|
22 |
|
23 |
> So, even in the case users are prompted to file bugs upstream first, |
24 |
> they should also at minimum report to gentoo when the bug is resolved |
25 |
> upstream so that the fix can be replicated. |
26 |
|
27 |
I think this duplication is utterly dysfunctional, as long as |
28 |
upstream does not refuse to fix the bug. |
29 |
|
30 |
|
31 |
> Its also not always abundantly clear to end users where upstream is, |
32 |
> and there are potholes in that process. |
33 |
|
34 |
Sure. This is an area where maintainers probably already know |
35 |
everything, and where they can help users by documenting it. |
36 |
(I use HOMEPAGE a lot. Would BUGTRACKER make sense?) |
37 |
|
38 |
|
39 |
> knowing exactly where the reporting queue *currently* is something |
40 |
> that can't be reliably replicated in metadata.xml, because it can |
41 |
> change on a whim |
42 |
|
43 |
In theory it can, but my experience is that in practice it doesn't |
44 |
change very often. |
45 |
|
46 |
|
47 |
> sometimes the metadata visible on the CPAN sources is also wrong, |
48 |
> and requires an experienced developer to chase its tail to work out |
49 |
> where it currently is. |
50 |
|
51 |
Sounds like a task that the ebuild maintainer can solve? |
52 |
|
53 |
|
54 |
> ( That is, I'm a much better reporter at reporting faults found in |
55 |
> gentoo to some upstreams than any user could hope to be ) |
56 |
|
57 |
Cool! And thank you for doing that! But it's not always neccessary, |
58 |
and it shouldn't be required when it isn't. |
59 |
|
60 |
|
61 |
> There are also cases where users reporting direct to upstream just |
62 |
> irritates upstream, because its a breakage/potential breakage due to |
63 |
> something gentoo does, and you have the whole hostile "not our |
64 |
> problem, you're on gentoo, you get to keep the pieces" response. |
65 |
> |
66 |
> For these reasons, I think its best that those with the most knowledge |
67 |
> of how upstream works, ( us, the developers ) handle reports from end |
68 |
> users and ferry them upstream. |
69 |
|
70 |
Do not use this as a blanket policy. It is unhelpful for upstreams |
71 |
who understand Gentoo and appreciate that users are building from |
72 |
source. |
73 |
|
74 |
Maybe they are the exception, but don't punish the minority of good |
75 |
guys just because most are bad. |
76 |
|
77 |
|
78 |
Thanks |
79 |
|
80 |
//Peter |