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

[Peter]

On Thu, 08 Jun 2006 15:51:25 -0400, Chris Gianelloni wrote:

First, let me say that I'm approaching this from a user's perspective. I
have no insight or knowledge as to the history of the overlay project or
any of the people involved. I _do_ know that since late 2004 when I first
switched to Gentoo, each week there are more bugs opened than closed.
There are also many open bugs that go back years.

In my particular frame, I want ebuilds I need or have contributed to get
into the tree. Having to download new ebuilds into local, and then have no
way to emerge update them is frustrating.

My point was about two things: 1) ebuilds that will never be committed to
portage, and 2) ebuilds that have been orphaned due to lack of interest.

As for breakmygentoo, here is my thought. As a user, I would prefer to do
all my shopping in one place. Gentoo has portage and uses ebuilds as a
package distribution mechanism. I would prefer to use gentoo's facilities
to get additional off-tree ebuilds. I don't want to have to sync all over
the place to get ebuilds of unknown origin. I would prefer to have a
sanctioned alt-gentoo ebuild repository where I know some q/a is applied
and standards adhered to.

My inference of the sunshine project was that there would be oversight and
control. That if _I_, for example wished to contribute, then I would have
to meet standards. And, on the flip side, anyone who would care to
download an ebuilt from o.g.o would be confident that the ebuild at least
meets certain quality standards. o.g.o, of course would have to disclose
that these packages are testing, and possibly experimental, but it's a
terrific opportunity to find a home for many orphaned and ignored
packages.

Using the example I brought up, about the kernel-sources, o.g.o would be
a perfect home for such a project.


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

Why? Because having two year old bugs is simply inexcusable. Especially
when many have not had any activity for a long time. Having
maintainer-wanted bugs for months on end is silly. Giving a user who files
a ebuild request or submits an ebuild deserves the chance to take
ownership of it. It's a good way to get a more experienced user, and
hopefully one day, a future dev.

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

Well as for packages getting picked up, this is not completely accurate.
Some will never get picked up, either because they are inappropriate
(hot-babe, for example), or too experimental (the kernel-source example I
cited). As for bmg, which I have to admit I had never heard about before
today, as a user, I would prefer to have everything genoo-sanctioned and
controlled. 


>> 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.
>
Users would not be getting o.g.o ebuilds automatically. They would have to
actively emerge layman, and then select the ebuilds they want. I agree
with you that the o.g.o and the main portage tree should never be
comingled. But, I do argue that bugzilla is inefficient in getting ebuilds
resolved. And, just because o.g.o exists does not in any way mean a user
would have to or be advised to skip bugzilla. Some ebuilds will get picked
right up, others after some review. All I am suggesting is that o.g.o will
help find a home for ebuilds that are wasting away on bugzilla.


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

I did not read anything that implied o.g.o would bypass anything other
than a lengthy wait in bugzilla land. Other distros have their
experimental/testing branches, why can't gentoo?

-- 
Peter


-- 
gentoo-dev@g.o mailing list