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
signature.asc
Description: This is a digitally signed message part
