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

[Lance Albertson]

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 <ramereth@g.o>
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