Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Chris Gianelloni]

On Thu, 2006-06-08 at 12:26 -0400, Peter wrote:
> I think this answers an important shortcoming of the bugzilla approach:
> vis, some bugs will never make it to the tree -- for any number of
> reasons. Take, for example, http://bugs.gentoo.org/show_bug.cgi?id=103354,
> which has an enhancement request for what is now called beyond-sources. A
> amalgamation of the arch, ck, tiger, nitro, and suspend2 sources. While on
> the kernel, IRC, I enquired about it, since I had just updated an ebuild
> for it, and was told unequivocally that there was no interest on the
> kernel team's part for adding this source tree to sys-kernel. Not maybe,
> not let's have a look at it, not come back in a month after testing. Just
> NO.
>
> And, I'm fine with that. That's their job -- to protect the quality of
> their project, and to keep things relatively safe and manageable.
>
> Nonetheless, the bug is active, with a good number of people subscribing
> to it and contributing to it. The sunshine overlay would be an ideal place
> to store a kernel source tree or any project which would never find a home
> in portage.

See, that's the misconception.  An overlay for this set of sources, and
possibly other sources, would be what "fits" in better with the original
idea of overlays.gentoo.org, as it was presented before it was approved.

Here's the problem, as I see it.  If you're filing a bug and you have
this "sunshine" overlay in your overlay list, I have exactly 0 clue what
you might be using from this overlay, since it covers *everything*.
This means that I, as a package maintainer, have no idea if you've used
some modified kernel/glibc/gcc/whatever that could be affecting my
package inadvertently.  This means I have exactly 2 choices, spend time
researching what is and isn't in this overlay and determine if any of it
could possibly effect my package and *then* start to try to troubleshoot
the bug, or mark it as RESOLVED-INVALID (or whatever) and ask you to try
again without the overlay.

It is a *huge* amount of overhead.

On the other hand, if you had a "kernel-sources" overlay, and are having
a problem compiling a non-kernel package, it is not very likely that the
kernel is the source of the problem, so the overhead is minimal to none.
The name of the overlay matches what the "project" would be, and
everything is transparent to both the user and also to the developer.

Were there a rule that said that *nothing* from the tree could be
present in this overlay, then it wouldn't be nearly as much of a
problem.  It would still have the problem presented above, but it would
be slightly less of a problem, since I now don't have to worry about if
your version of knights is the one from the tree or from the overlay.

> As I see it, there are really two main issues with bugzilla. One, is to
> resolve open ebuild enhancement bugs. Mark them somehow so it's clear the
> bug has been reviewed and an action determined. CANTFIX/WONTFIX is harsh,
> but if that's what it is, then mark it! The second issue is the orphaning
> of packages which have merit, but no maintainer. Again, the sunshine
> overlay would provide a home for those packages. It will also allow the
> user to take ownership of a project, get some experience, and maybe decide
> to become a dev. And, should that occur, then, lo, the orphaned package
> may have a maintainer someday.

This is something that I do not get.  Why exactly does everything have
to be resolved in some specific time frame?  Is "when I get to it" not
good enough?  I mean, it works for Linus, right?  ;p

As for packages that have merit, this is quite simple.  If the package
has enough of a good following, it will get picked up.  The likely
reason why many of the maintainer-wanted packages are in the state
they're in is simply because there isn't enough interest in the package.
In this particular instance, I can see an external overlay being useful.
However, there already is one.  It is called "breakmygentoo".  Do we
really need to duplicate their functionality?

> So, hopefully, as the overlay project moves forward, it will help take
> some of the heat off bugzilla and allow for the offering of more ebuilds
> to userland.

I sincerely hope it doesn't effect bugzilla in any way.  I have no
problem with users getting access to ebuilds, but many of these ebuilds
simply are not ready for anyone to get them "automatically".  Having an
ebuild on a bug makes it easily searchable.  Having an ebuild on a bug
makes it easy to peer review.  Having an ebuild on a bug means the user
needs to explicitly add the ebuild to their overlay.

The idea behind the overlays project, as it was presented, was to assist
projects in doing development by allowing outside contributors to more
easily interact with specific projects or teams.  It was not designed to
bypass Gentoo's security or quality assurance policies, nor was it
designed to allow a mechanism to give our users substandard ebuilds.

The idea isn't so bad, but the benefits definitely do not outweigh the
negatives.

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