Re: [gentoo-dev] Re: Making the developer community more open

["Michael Crute" <mcrute@gmail.com>]

On 3/22/06, Duncan <1i5t5.duncan@cox.net> wrote:
> A possible alternative that could be rolled out sooner would be some form
> of "contrib" eclass.  Make it a simple matter to inherit contrib and get
> the standard contrib warnings and handling.  One thing the eclass could
> handle would be a USE=contrib flag.  With it off, the build wouldn't
> merge.  That would take care of user choice.  No non-contrib package could
> dep on a contrib package so if such a dependency came about, either the
> non-contrib package would have to be dropped (or at least dropped to
> contrib status even if it was "contributed" by a dev), or the dep raised
> to full support (non-contrib) status.
>
> The dependency rule above would by definition mean that nobody could get
> contrib accidentally, since the only way to get a contrib package would be
> merging it or another contrib package that depended on it from the command
> line.  This would also solve the interactivity aka broken emerge session
> issue, since the portage protest and failure would be right up front,
> before merging started.
>
> Making it a use flag would allow control of specific packages thru
> package.use, just as now, so a user could decide that he trusted one
> contributor as the author of a specific package (and his opinion of the
> dep chain) without forcing it to apply to the entire contrib tree.
>
> There remains the question of naming.  A contrib-cat/package tree
> paralleling the main category structure would potentially double the
> categories right there.  Not really practical.  cat/package-contrib-ver
> would be more practical, and allow on-sight identification, but would of
> course necessitate a package rename if the contrib vs. full-supported
> status changed.  This aspect could be debated if the idea in general gains
> enough favor to consider a glep or the like.

Maybe taking a slightly different approach at this same idea is  what
needs done. Create a new mask level for contrib where anything deemed
"stable" yet unmaintained could go so that users will have access to
it without needing to search bugzilla or some third-party site.  I
would also propose an unstable mask as well where testing ebuilds can
go, things that are in bugzilla but have not yet been vetted. The
process for getting unstable ebuilds from bugzilla to portage could
even be automated to the extent that when an ebuild is put into
bugzilla it gets auto committed to the tree but masked unstable. This
way all the "latest greatest" ebuilds are always available in the tree
but it requires the user to consciously unmask them for use. You could
even add a big red warning for unstable ebuilds to let people know
that they should examine the ebuild before emerging... just so if they
DO get rooted due to a bad ebuild you can say they where warned.

You could further extend the process of emerging unstable ebuilds so
that a successful emerge would create a vote "for" the ebuild in
bugzilla (attached to the original ebuild bug) and an unsuccessful
emerge would allow the user to add a comment/vote against the ebuild
in bugzilla.

Perhaps it is a radical approach but that's just my $0.02 on how to
open the dev community.

-Mike

--
________________________________
Michael E. Crute
http://mike.crute.org

It is a mistake to think you can solve any major problems just with potatoes.
--Douglas Adams

-- 
gentoo-dev@gentoo.org mailing list