Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Chris Gianelloni]

On Fri, 2006-06-09 at 05:42 -0700, Brian Harring wrote:
> 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.

I already covered this.  If you're going to be a part of the
conversation, try to keep up, will you?  *grin*

> 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.

Except the other overlays are not designed as end-user overlays.  They
are designed to aid developers.  Also, they are targeted at a specific
task/goal, as opposed to being a dumping ground for the unwanted and
unmaintained.

> 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).

I definitely agree that better bug data would help the situation.
However, it does not change the fact that this is still a dumping
ground.  Again, this was something that was *explicitly* stated that
overlays.gentoo.org would *not* become, yet here we are.

> 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...

Most people tend to not punt the bug so much as ask for proof that it
isn't caused by the overlay.  I know that we have done this in games and
it has almost always ended up as something the user has done thanks to
an overlay.  In the cases where it truly is a bug, we fix it.

> > > 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.

Sure.  Doesn't mean I have to support anything but the one and only
official Gentoo package repository.  Complain all you want, but I became
a Gentoo developer, not a $random_repository developer for a reason.

> 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).

I'd rather the things that were agreed upon when the overlays project
was started were actually adhered to, instead.  I guess it is just too
much to ask from some people to keep their word.

...and people wonder why Gentoo developers don't trust each other
anymore.

> 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).

Fine.  Make a proposal to actually add it to the tree and do it
properly.  There's no need to have this sort of thing limited to a very
small subset of developers who couldn't *possibly* keep up with the
workload.  Yes, there will only be a few developers and they'll be
really busy, especially since they're going to be checking every commit
to ensure that there's no malicious code......

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux