1 |
On Fri, Jun 09, 2006 at 08:16:32AM -0400, Chris Gianelloni wrote: |
2 |
> On Fri, 2006-06-09 at 02:49 +0200, Markus Ullmann wrote: |
3 |
> > > This is a bug for an ebuild that the user does not think is related to |
4 |
> > > the pam_skey. Go back and read what I wrote. |
5 |
> > > |
6 |
> > |
7 |
> > it was agreed upon that we don't keep extra bugzilla or whatever for all |
8 |
> > things on o.g.o but keep track of all issues within bugs.g.o. and btw, |
9 |
> > most work on "new" bugs is done by bug wranglers and not the common |
10 |
> > devs. So if they say the workload from it is too high, I'll take it as |
11 |
> > valid reason as they have to handle it. |
12 |
> |
13 |
> I'm sorry, but you're avoiding the question here. How will the |
14 |
> bug-wranglers even *know* that this is related to a package in the |
15 |
> overlay? They wouldn't. As I ststed *repeatedly* now. The user has |
16 |
> not mentioned that they're using pam_skey, as is a common occurrence in |
17 |
> bugs. |
18 |
|
19 |
Curious, how will the wrangler know in general? *cough* they won't. |
20 |
|
21 |
You're using a generic arguement against a specific target- iow, apply |
22 |
it to overlays.g.o in general instead of singling sunrise out via it. |
23 |
|
24 |
Meanwhile, answer to that one is better bug data for reporting- dump |
25 |
of (random out of the ass example) first level deps, and where they |
26 |
came from (overlay/portdir). |
27 |
|
28 |
Downside to that data is that slackers will automatically punt the bug |
29 |
if they see non portdir in cases where it's obvious it's an issue in |
30 |
the pkg rather then the deps, but there always is a downside... |
31 |
|
32 |
|
33 |
> > We're not the first large overlay project, there are other ones out |
34 |
> > there already and these "wrong" bugs aren't a new thing arising here... |
35 |
> |
36 |
> No. You're the first large overlay project that is on official Gentoo |
37 |
> infrastructure, even after it was agreed that there wouldn't be |
38 |
> something like this. With the non-official projects, we simply don't |
39 |
> support any bugs from anyone using them. It's that simple. With this |
40 |
> project, you're vying for official status, meaning we cannot do that. |
41 |
> This will be an *enormous* time sink for the entire ebuild developer |
42 |
> pool. |
43 |
|
44 |
Same for above re: "large overlay", realistically, like it or not the |
45 |
general case of N overlay/repo is coming down the pipe. |
46 |
|
47 |
Personally, I'd rather see this particular case be handled from the |
48 |
get go as an experiment- lay out from the start the exit conditions |
49 |
for it (if it becomes a dumping ground, out she goes). |
50 |
|
51 |
Reason? Devs/users have been after a true testing branch/repo from |
52 |
day one, if we're doing overlays and people are willing to try and |
53 |
supply that demand, lets get the question answered once and for all |
54 |
(instead of everyone and their mother shooting off about every |
55 |
potential they can think of for why it might fail). |
56 |
|
57 |
~harring |