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@gentoo.org mailing list
