On Wed, Aug 02, 2006 at 10:27:04PM -0500, Lance Albertson wrote: > 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.
http://www.gentoo-sunrise.org/sunrise/wiki/SunriseFaq Specifically, for those who haven't done their reading, look for the "Can I commit everything I like to the overlay", specifically the rules involved for what goes in. The short and skiny is that the arguement of "they'll have some package that breaks my package" is kind of daft- sunrise won't hold version bumps for packages in the tree (one exception to this is maintainer-needed that has sat, perhaps they can clarify that corner case). For the maintainer-wanted, the developer who pulls the package in *should* be lifting from sunrise already. Why? Because whats there has actually been exposed to users, rather then them relying on a simple eyeballing of the ebuild from bugzilla instead. That leaves the "will link against a package from sunrise"... covered the potentials above, the remaining case is a package in the tree linking against a maintainer-needed ebuild. Funny thing, that's actually a bug in the developers package. Daft I know, but it's actually a *good* thing to smoke those out, there should be no unstated linkage (if it ain't in the deps, it's a bug to use/link to it). > 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? Assumption is that there will be excessive bug traffic for issues like that. Rules above imo lay it out well enough I don't think it'll occur at the level of "excessive". Basically, sky is falling predictions- no one has hard facts since this is hypothetical, so it would be *nice* if people would at least recognize that they may be barking at a minimal issue. *Plus*, with sunrise under gentoos thumb if it proves to be more trouble then it's worth, the plug can be pulled- that's the trade of it being official, they get hosting, y'all get an actual say in what they do. If they do it externally, ain't much you can do- can't demand they do something (result of that if it were me would be a mooning), stuck requesting them to do what _y'all_ want. > 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). What is sunrises reason for existance? It's meant to hold ebuilds that _rot_ in bugzilla in a place where people can work on them as needed, and folks who need the packages can use them. They may get bit in the ass since it's a fairly raw repo (despite reviewed branch), but the purpose here is different; it's not intended as a dumping ground (and if it becomes one, council has stated their intentions), it's intended as a repo for people to get at the ebuilds in an easier way, and improve those ebuilds if there is interest. > 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 Honing your ebuild skills occurs via practing said ebuild skills. You're not making much of a point here frankly- if ebuild devs won't do a damn thing about an ebuild, who will? That leaves people who are interested in the ebuild. You're basically arguing here that because a dev (who has passed bluntly some arbitary chalk on the wall ebuild test) doesn't have an interest in the package, other folks shouldn't do anything with the ebuild. Phrased that way, it sounds... a bit demanding and out of line. There is a first level, and a second level. What hits the second level is at least reviewed by others (something gentoo-x86 lacks). People _want_ the package, they wouldn't have submitted it to bugzie otherwise- if devs won't do the work, sunrise devs stepping up to help is the best you're going to get. (and prior to anyone screaming "but they may suck", again, note the reviewing- it's a _good_ attempt to deal with that issue). > Whats 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. Bit daft to assume that sunrise can serve one, and only one purpose. See above, it provides 1) area for ebuilds that are bitrotting, thus trying to get a gain out of the original submitters work via sharing it _easily_ with others such that they can use/improve it as needed 2) a testing ground for ebuilds prior to actually hitting the tree. Fair bit easier of a sell for a package if it's been exposed to users for 6 months with minimal issue, versus looking at a bug and seeing just an ebuild 3) way to enable people who want these things, to contribute. This is both the 'learning ground', and a way to sucker^Wbring more folk into the extended disfunctional family that is gentoo. Further, sunrise is an opt-in setup. People aren't forced to use it, just the same as people aren't forced to use ~arch. If they *do*, they're taking on the costs of using it. > 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. One question then. What if netmon has no interest? What then, because they don't care, for those users who have no option but to work locally, or start their own overlay if they want to share it? Personally, I think herds stepping in and helping would be a good thing. That said, it is _not_ their place to block others from volunteering their efforts (iow, herds doing territorial pissing should not fly). If netmon doesn't want to do anything with sunrise, fine- then it falls to the general maintainers to watch over things. That said, if netmon doesn't want any involvement, that shouldn't block others from trying to contribute (we see enough of that already in mainline gentoo). Now if netmon thinks sunrise is screwing up their packages left and right, well take it to the council/devrel (whichever it falls under)- same way any other project <-> project issue should be dealt with. yes, herd isn't strictly a project, but you get the point- don't like the implicit statement that sunrise is automatically second class citizen to the herd, thus the herd can boss them around. Sunrise *should* defer to the herd when they're not making loco demands, hash out an optimal solution for all parties. Having a defacto "we say it is so" doesn't enable such a setup however. ~harring
pgpSsObZ33KDI.pgp
Description: PGP signature
