Brian Harring wrote: > On Wed, Aug 02, 2006 at 08:05:15PM +0200, Carsten Lohrke wrote:
>> Local overlays are fine as the user exactly knows what he does in his >> private >> overlay (and hopefully follows eclass changes), development overlays are >> fine >> (assuming the group of people controls the releavant overlays as well), >> overlays like Sunrise are problematic, not to use such anal words as you do. > > Why are they problematic? Because of your assumption that they won't > maintain it? > > It's the same thing as gentoo-x86 (I will keep stating that till it's > grilled into peoples heads also), this is _not_ a new issue so why are > people leveling issues of gentoo-x86 as new issues of sunrise? > > So someone goes and breaks something in gentoo-x86 that breaks > something for sunrise. Fine, it's sunrises' mess to clean up; they've > volunteered to do this work, I don't see how you can claim it as a > negative when they've accepted it as part of _their_ work. I think the point a lot of people are concerned about are packages that contain libraries or other dependencies that reside in the sunrise tree. There's a good chance that a package in the regular tree will link against a package from sunrise, the user will have no idea or forget that they installed that app from sunrise (and the dep exists), and a bug arises. Who's fault is it? Is it the package maintainer in the regular tree, or sunrise? How do you stop excessive bug traffic for issues like this? Another issue I think people are ignoring here is the fact that sunrise isn't focused on a particular part of the tree. I think Ciaran made a point earlier (that was probably ignored) about the fact of why we have herds in the regular tree. They aren't perfect, but they still do a decent job of gathering people who have a good understand about a certain group of packages. I have a hard time believing that the same type of quality exists with the number of devs working on it. The difference between sunrise and say the php overlay is the fact that sunrise isn't focused on a set of packages (just ones that people want that aren't in the tree) compared to a focused set for a specific purpose (php). The more I think about it, I think there needs to be a separation between "a sandbox for users to hone their ebuild skills" and "these packages aren't in the tree yet, lets make the available somewhere else". Perhaps the better solution is to have the herds manage their own set of overlays must like php does. I imagine many herds won't have a need for it, while others would (and probably already using it). What's the real purpose of sunrise then? The sandbox/learning ground? Or a place for ebuilds that are stuck in bugs? The sunrise project has been fighting on the grounds of learning aspect, but most of the people are having issues with the ebuild stomping ground side. If I remember right, the primary reason the council voted to re-enact sunrise was because of the learning side of it. I don't doubt that (if done right) would be a great thing, but I have concerns on the implementation of the latter. For an example: To me, it would work better if the netmon herd brought on a user to help with the netmon overlay. They would get specific 'training' on working on netmon ebuilds. They could have done the 'bootcamp' at sunrise initially, then moved onto the herd overlay for something a bit more organized and better maintained. This would produce a part of the QA that some people are in a fuss about, and some better organization. Heck, maybe even some interaction with the sunrise group and netmon herd would be great so that the education continues, but on other watchful eyes. Basically, it boils down to organization of ebuilds and how they are being watched. A group that watches all isn't a good idea to me, my idea above makes more sense. Anyways, I've been trying to keep quiet on this issue and decided I could interject here :) Cheers- -- Lance Albertson <[EMAIL PROTECTED]> Gentoo Infrastructure | Operations Manager --- GPG Public Key: <http://www.ramereth.net/lance.asc> Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net
signature.asc
Description: OpenPGP digital signature
