1 |
On Fri, 2006-06-09 at 02:49 +0200, Markus Ullmann wrote: |
2 |
> > Excellent. So we're moving the history from being in a single location |
3 |
> > (the bug) to being in multiple locations. That will definitely improve |
4 |
> > the development process. Another thing that people tend to miss is that |
5 |
> > not all improved versions of ebuilds submitted to bugzilla are done byt |
6 |
> > he original authors. There are many cases where an initial ebuild is |
7 |
> > done, a developer makes comments on what needs to be changed, and |
8 |
> > *another* contributor gives a fixed ebuild. How exactly will this |
9 |
> > streamline that process? No offense, but everything I have seen looks |
10 |
> > as if it will add even *more* overhead to actually getting packages into |
11 |
> > the tree. The only thing this seems to provide is a half-baked |
12 |
> > repository for the users to get marginally-tested ebuilds for software |
13 |
> > that wasn't interesting enough for inclusion in the tree. |
14 |
> |
15 |
> we want to encourage users to contribute and if they do good |
16 |
> contributions in bugzilla they get commit access to the overlay. and |
17 |
> then the workload is drastically reduced... |
18 |
|
19 |
You didn't answer anything I asked here. |
20 |
|
21 |
> > This is a bug for an ebuild that the user does not think is related to |
22 |
> > the pam_skey. Go back and read what I wrote. |
23 |
> > |
24 |
> |
25 |
> it was agreed upon that we don't keep extra bugzilla or whatever for all |
26 |
> things on o.g.o but keep track of all issues within bugs.g.o. and btw, |
27 |
> most work on "new" bugs is done by bug wranglers and not the common |
28 |
> devs. So if they say the workload from it is too high, I'll take it as |
29 |
> valid reason as they have to handle it. |
30 |
|
31 |
I'm sorry, but you're avoiding the question here. How will the |
32 |
bug-wranglers even *know* that this is related to a package in the |
33 |
overlay? They wouldn't. As I ststed *repeatedly* now. The user has |
34 |
not mentioned that they're using pam_skey, as is a common occurrence in |
35 |
bugs. |
36 |
|
37 |
> > Again, read what I wrote. I said that the developer would see "sunrise" |
38 |
> > in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated |
39 |
> > without considering. This is a login bug. At no point did they make |
40 |
> > mention of having installed pam_skey from this overlay. This means that |
41 |
> > I, as the developer getting this bug, am now responsible for looking at |
42 |
> > *every package* in the sunrise overlay to determine if *any* of them |
43 |
> > could *possibly* be affecting this package or causing this bug, then |
44 |
> > asking the user if they have any of them installed. |
45 |
> |
46 |
> why would a pam dev get this bug? as far as I know bug wranglers work, a |
47 |
> check whether the ebuild is in tree is one of the first ones... So the |
48 |
> chance that it really hits the pam dev is damn small... |
49 |
|
50 |
Because the user has "pam" in USE and there's nothing else indiciating |
51 |
that they're using some pam packages from an overlay that has absolutely |
52 |
no hint as to its contents. Also, as I have said, while the bug |
53 |
wranlgers are wonderful and really do reduce our workload, they're |
54 |
*nowhere* near perfect. There are *tons* of bugs that go to the wrong |
55 |
people, or are simply invalid once the actual maintainers see it. The |
56 |
bug wranglers cannot be expected to be experts on every package. Your |
57 |
comments make it sound like they will be. |
58 |
|
59 |
> We're not the first large overlay project, there are other ones out |
60 |
> there already and these "wrong" bugs aren't a new thing arising here... |
61 |
|
62 |
No. You're the first large overlay project that is on official Gentoo |
63 |
infrastructure, even after it was agreed that there wouldn't be |
64 |
something like this. With the non-official projects, we simply don't |
65 |
support any bugs from anyone using them. It's that simple. With this |
66 |
project, you're vying for official status, meaning we cannot do that. |
67 |
This will be an *enormous* time sink for the entire ebuild developer |
68 |
pool. |
69 |
|
70 |
> > Wouldn't this process be *infinitely* easier if instead of "sunrise" |
71 |
> > there was a "pam" overlay with *only* the pam stuff? |
72 |
> |
73 |
> Then the pam devs are responsible for all the things with it. As it |
74 |
> would surely be hosted on o.g.o then, we'll notice it and either shift |
75 |
> all ebuilds we have in the sunrise tree over or do whatever is fine with |
76 |
> pam devs. If they really dislike the m-w bugs out of their control, then |
77 |
> a friendly note on irc, a friendly mail or whatever is enough and we |
78 |
> won't touch things of them then... |
79 |
|
80 |
Excellent job of avoiding the issue. |
81 |
|
82 |
I asked how the pam developers would even *know* that there is pam crap |
83 |
in your aptly-named "sunrise" overlay, and you respond with a comment |
84 |
about how when the pam devs tell you to move the packages you will. |
85 |
|
86 |
I am honestly seeing that this is starting to go nowhere as the answers |
87 |
to my questions aren't being given, and instead the issues are being |
88 |
avoided. |
89 |
|
90 |
> > That is *exactly* what we get with the other overlays like php and |
91 |
> > vmware. I *know* that if I'm looking at a glibc bug and the user has |
92 |
> > "php" as an overlay, that it isn't going to be a concern. |
93 |
> |
94 |
> Well we don't keep ebuilds in there which have a maintainer in contrast |
95 |
> to the php overlay. they may even keep newer versions of in-tree |
96 |
> packages in their overlays. |
97 |
|
98 |
That doesn't have anything to do with what I stated. Again, avoiding |
99 |
the issue. |
100 |
|
101 |
> > They do this in a very quick and cursory manner. They do a pretty good |
102 |
> > job of it, but there are countless bugs which they do not catch that are |
103 |
> > not assigned properly or end up being invalid due to user negligence. |
104 |
> > The bug wranglers cannot be *expected* to perform this level of service, |
105 |
> > lest they burn out and run away within a couple weeks. ;] |
106 |
> |
107 |
> Well a simple grep for "sunrise" in there will show the needed thing... |
108 |
|
109 |
So I can mark any bug that has sunrise in it as INVALID, then, because |
110 |
the overlay is going to be known to be in an unmaintained state? |
111 |
|
112 |
Perfect. |
113 |
|
114 |
> And, sorry, if one or another bug slips through. Wranglers are humans as |
115 |
> well and humans make mistakes. Also you can't expect them to know about |
116 |
> all issues. But that is a bit off-topic here. |
117 |
|
118 |
No. It is *exactly* the topic that I am speaking of, which you're |
119 |
avoiding. |
120 |
|
121 |
> Just a last note on it: the main bug wrangler is helping us as well as |
122 |
> commiting so I guess he notices the problems with sunrise... |
123 |
|
124 |
So having one extra man on the team is going to alleviate all of the |
125 |
problems? Excellent. My fears are quelled. |
126 |
|
127 |
> > This is a prime example of totally glossing over any discussion to make |
128 |
> > it sound promising for you. How exactly is a proxy maintainer going to |
129 |
> > know that a new version of an ebuild has been committed? Either by |
130 |
> > watching the overlay like a hawk, or when the maintainer |
131 |
> > emails/pings/whatever and lets him know that there's a new version. How |
132 |
> > exactly is this easier to track? Even better, if I am the proxy |
133 |
> > maintainer for a particular set of ebuilds for one or more |
134 |
> > user/maintainers, why do I need it in your big, bloated, and completely |
135 |
> > inappropriately-named "sunshine" overlay versus a developer overlay of |
136 |
> > my own? After all, I am the *only* proxy maintainer. Why should there |
137 |
> > be the added *insecurity* of allowing any number of people that *I* |
138 |
> > might not trust complete access to the small number of packages where I |
139 |
> > am the proxy? |
140 |
> |
141 |
> Tracking: |
142 |
> First we want people to get used to it. Adding some random features like |
143 |
> automated email upon a special commit can be added easily with just two |
144 |
> lines in the post-commit hook... |
145 |
> |
146 |
> Dev-Overlay: |
147 |
> Well you're free to use the dev overlay for it. But if you keep it on |
148 |
> the sunrise overlay, it (hopefully) gets more tested. |
149 |
|
150 |
No offense, but this email was pretty much useless as you avoided my |
151 |
questions with lots of vague references to how it will make things |
152 |
"better" and didn't bother to actually thoughtfully answer any of my |
153 |
points. |
154 |
|
155 |
I'm through wasting my time with this. If I see a bug with sunrise, |
156 |
it's going INVALID, as it is now apparent to me that the issues with the |
157 |
project won't be resolved. |
158 |
|
159 |
So long, and thanks for all the fish. |
160 |
|
161 |
-- |
162 |
Chris Gianelloni |
163 |
Release Engineering - Strategic Lead |
164 |
x86 Architecture Team |
165 |
Games - Developer |
166 |
Gentoo Linux |