[gentoo-dev] Re: Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Peter]

On Fri, 09 Jun 2006 13:08:01 +0200, Henrik Brix Andersen wrote:

> On Thu, Jun 08, 2006 at 06:31:43PM -0400, Peter wrote:
>> And, for me again as a user, using a gentoo-hosted overlay is
>> preferable to a third party repository. This is a personal bias on my
>> part -- and maybe unwarranted.
>
> This is actually my main concern with the Sunrice project. You say you
> would prefer a gentoo-hosted overlay to a third party repository. Why is
> that? I can only assume it's because you think "hey, it's officially
> endorsed by Gentoo, the same people who maintain the other official
> ebuilds - so it must be ok".
>
> I suspect most users will think similar and will come yelling at us, or
> even worse - at upstream, when something in this overlay breaks and
> leaves their computer as expensive paper weight (at least until they've
> formattet and started over).
>
> Regards,
> Brix

I don't think so. I look forward to the sunrise (sorry I called it
sunshine earlier, it was late) project because of two reasons.

Firstly, I think it is very clear that anything in sunrise is experimental
or not supported in the main gentoo tree. That's fine! I don't think any
user who goes through the trouble to set up an overlay would miss that
point. You can't go to o.g.o and not see the disclaimers. And, anyone who
goes through the trouble to svn the overlay, edit make.conf, etc., would
not be an ignorant newbie (no disrespect to newbies intended). Anyone who
fetches the sunrise overlay would know exactly what he/she intends to do
and why. Much different than emerge --sync with keyword x86.

Secondly, my bias against a third party repository is perhaps unwarranted.
I am sure the bmg site is excellent and the people running it are
well-intentioned and experienced. However, that said, as a user, I have a
higher comfort level staying in the gentoo.realm.

Thirdly, the opportunity to be able to publish ebuilds that would
otherwise languish in bugzilla is very exciting. I think it also gives the
bugday people an opportunity to close out bugs. Despite what others have
written, having multi-year old bugs is very counter productive. If
something has not been fixed in so long, it probably either can't be
fixed, or may not even apply anymore. I know this is a generalization, but
if a bug was filed against gentoo 2004.3, who knows if it still applies
with gentoo 2006.0. Especially if there has been little or no activity.

Personally, I don't see the conflict, or the risk, or the additional work
for devs. In fact, I see the opposite. Removing maintainer-wanted bugs is
a net positive. If that means the proposed ebuild lives in o.g.o that's
fine. Just point users who see the bug over to it. And, if an ebuild
proves to be useful, or popular, it's conceivable that it could ultimately
find its way over to the main tree.

As for the more sinister aspects of a rogue ebuild finding its way onto
o.g.o, sure that's a possibility. However, any dev could do the same in
portage because they have commit access (and the problem may not be
caught right away). Moreover, it's possible that an ebuild may be fine,
but a particular version of a package tarball could have outright
malicious code or an undetected security hole in it that has not been
caught yet. That could find its way onto portage too. IMHO, I don't see
any more risk to security in o.g.o.

Again, I think you need to consider your audience for o.g.o. The newbie
won't be there or be syncing to o.g.o. The server admin probably would not
be there either for updating a production machine. I think the main
audience for o.g.o. would be the power user, or the wannabe power user or
certain project teams, or people with a particular interest or need in a
project not hosted on the main tree -- that is people who actively need
sunrise's services.

And, looking at this from a broader perspective, I see this as a real
enhancement to gentoo. Offering an experimental tree for packages not
intended or not wanted in the main tree. This is an added benefit, it
demonstrates a policy of inclusion, not exclusion. It shows a willingness
to push the envelope and give certain packages a home where they would not
normally get one.

-- 
Peter


-- 
gentoo-dev@g.o mailing list