From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1FoX78-00070r-LF for garchives@archives.gentoo.org; Fri, 09 Jun 2006 02:52:47 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k592pXYT015264; Fri, 9 Jun 2006 02:51:33 GMT Received: from rs25s12.datacenter.cha.cantv.net (rs25s12.datacenter.cha.cantv.net [200.44.33.106]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k592nFLF024818 for ; Fri, 9 Jun 2006 02:49:16 GMT Received: from localhost (dC9D13795.dslam-01-3-15-01-1-01.smg.dsl.cantv.net [201.209.55.149]) by rs25s12.datacenter.cha.cantv.net (8.13.4/8.13.0/3.0) with ESMTP id k592nEBN004158 for ; Thu, 8 Jun 2006 22:49:14 -0400 X-Matched-Lists: [] Received: from localhost ([127.0.0.1]) by localhost with esmtp (Exim 4.61) (envelope-from ) id 1FoX4z-0002DA-0w for gentoo-dev@lists.gentoo.org; Thu, 08 Jun 2006 22:50:33 -0400 Message-ID: <4488E1F8.5090204@gentoo.org> Date: Thu, 08 Jun 2006 22:50:32 -0400 From: Luis Francisco Araujo User-Agent: Thunderbird 1.5.0.2 (X11/20060530) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay References: <1149796286.19443.76.camel@cgianelloni.nuvox.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on rs25s12.datacenter.cha.cantv.net X-Virus-Status: Clean X-Archives-Salt: cda8e1e2-efb3-46fb-b3a2-5e1f4c27d688 X-Archives-Hash: e9a37e43134922b5d55fc2aeb91ee6c3 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@gentoo.org mailing list