Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

[Thilo Bangert]

Richard Freeman <rich0@g.o> said:
> AllenJB wrote:
> > All that's going to happen is Gentoo will have many many buggy and
> > out of date packages in the MAIN TREE. Exactly where they shouldn't
> > be. You claim quality won't be sacrificed, but I simply can't see
> > this without any attempt to solve the manpower issues first.
> >
> > Isn't the purpose of this project already somewhat covered by
> > Sunrise?
>
> I have to agree with your points.  We need to have quality standards
> for packages.  Currently we have a couple of tiers:
>
> 1.  Main tree - every ebuild has an official maintainer and gets prompt
> security updates/etc.  New features might get a little more stale, but
> you aren't going to be running at risk if you only use the main tree
> and routinely emerge -u world.  If a package falls behind on security
> it gets masked and booted.
>
> 2.  Overlays - you're on your own and at the general mercy of the
> overlay maintainer.
>
> 3.  Sunrise (just a special case of an overlay) - somewhere in-between.
>   Again, you have to opt-in.
>

AFAIK, we have never explicitly made this distinction clear. if we had, we 
would have to remove stuff from portage which doesnt live up to the 
standards.

it is also not true from a more real world perspective: there are many 
packages in portage that have a standard which is much lower than what is 
in some overlays. and there are many packages in overlays which live up to 
a quality standard way above portage's average.

if you want to exaggerate a bit, we have roughly 500 ebuilds in portage 
which are maintainer-needed and have only a few users and thats why you 
want to keep popular packages out of the tree?

its weird, how this whole thing started with wanting to accomodate our 
users better and then other people come around and argue against it in 
order to protect our users...
user who want protection run stable arch!

given the current state of the tree, its hypocritical to be against this 
proposal, IMHO.

however, one could try to implement the above quality standards, possibly 
by splitting up the tree.

this issue, as well as some others very similar to this one, have come up 
many times before. I suggest we do something about it... (splitting the 
tree or moving more stuff wholesale into portage and have a better rating 
system... whatever)

Fedora is a much more current distribution than Gentoo - and has been for 
a couple of years...

regards
Thilo

> I think that we still need to have defined levels of quality, so if we
> start putting unmaintained stuff in the main tree then we absolutely
> need to preserve a mechanism for users to indicate what level of
> quality they desire.  Users running a typical install shouldn't
> inadvertently have dependencies pulled in which aren't fully controlled
> for security issues.
>
> Could something like sunrise be integrated into the main tree?  Sure.
> However, there would need to be lots of rules and QA checks like
> non-sunrise packages not depending on sunrise packages and the sunrise
> packages are somehow clearly marked.  Maybe even an ACCEPT_QUALITY =
> "good-luck-with-that" setting or something like that in make.conf.  We
> might also need tiered levels of security in cvs.  I'm not convinced
> that in the end it will be any better than just having those who are
> interested add an overlay to their tree.
>
> Maybe a better option would be a way to make overlays more seamless.
> Additionally we could have rating categories for overlays like
> "security responsiveness," "currency with upstream," etc.  The gentoo
> project would ask overlays to declare their policies as a condition of
> being accessible via the seamless interface, and would drop overlays if
> they don't follow their policies.  It would still be easy for users to
> pick non-standard overlays but it would be clear that they are
> venturing off on their own if they do this (just as is the case with
> layman today).
>
> Sure, I'd love to see an extra 1000 supported packages in portage, but
> the key is "supported", not just shoveled-in.