On Fri, Jun 09, 2006 at 08:16:32AM -0400, Chris Gianelloni wrote:
> On Fri, 2006-06-09 at 02:49 +0200, Markus Ullmann wrote:
> > > This is a bug for an ebuild that the user does not think is related to
> > > the pam_skey.  Go back and read what I wrote.
> > > 
> > 
> > it was agreed upon that we don't keep extra bugzilla or whatever for all
> > things on o.g.o but keep track of all issues within bugs.g.o. and btw,
> > most work on "new" bugs is done by bug wranglers and not the common
> > devs. So if they say the workload from it is too high, I'll take it as
> > valid reason as they have to handle it.
> 
> I'm sorry, but you're avoiding the question here.  How will the
> bug-wranglers even *know* that this is related to a package in the
> overlay?  They wouldn't.  As I ststed *repeatedly* now.  The user has
> not mentioned that they're using pam_skey, as is a common occurrence in
> bugs.

Curious, how will the wrangler know in general?  *cough* they won't.

You're using a generic arguement against a specific target- iow, apply 
it to overlays.g.o in general instead of singling sunrise out via it.

Meanwhile, answer to that one is better bug data for reporting- dump 
of (random out of the ass example) first level deps, and where they 
came from (overlay/portdir).

Downside to that data is that slackers will automatically punt the bug 
if they see non portdir in cases where it's obvious it's an issue in 
the pkg rather then the deps, but there always is a downside...


> > We're not the first large overlay project, there are other ones out
> > there already and these "wrong" bugs aren't a new thing arising here...
> 
> No.  You're the first large overlay project that is on official Gentoo
> infrastructure, even after it was agreed that there wouldn't be
> something like this.  With the non-official projects, we simply don't
> support any bugs from anyone using them.  It's that simple.  With this
> project, you're vying for official status, meaning we cannot do that.
> This will be an *enormous* time sink for the entire ebuild developer
> pool.

Same for above re: "large overlay", realistically, like it or not the 
general case of N overlay/repo is coming down the pipe.

Personally, I'd rather see this particular case be handled from the 
get go as an experiment- lay out from the start the exit conditions 
for it (if it becomes a dumping ground, out she goes).

Reason?  Devs/users have been after a true testing branch/repo from 
day one, if we're doing overlays and people are willing to try and 
supply that demand, lets get the question answered once and for all 
(instead of everyone and their mother shooting off about every 
potential they can think of for why it might fail).

~harring

Attachment: pgpcq5ihyOyf2.pgp
Description: PGP signature

Reply via email to