Re: [gentoo-dev] Project Sunrise resumed again (was Resignation)

[Brian Harring <ferringb@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 9652 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]