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

[Luis Francisco Araujo]

Peter wrote:
> 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.
You are always free to fix them. Or even better, free to become a dev 
and maintain them.
> 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.
>
>
I agree. It depends at the end upon the user interest to submit/maintain 
an ebuild.
Though that is our current situation with bugzilla too, so i don't see
what is the advantage of the overlay here.
>> 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?
>
>
masked packages are our "officially" supported experimental/testing 
branches.
-- 
gentoo-dev@g.o mailing list