Re: [gentoo-dev] Official overlay support

[Chris Bainbridge]

On 23/03/06, Stuart Herbert <stuart.herbert@×××××.com> wrote:
> Developers are already using overlays, and some teams (including ones
> I've been involved in) are actively and successfully using them to
> help with recruitment and to provide a way to access ebuilds that
> would otherwise still be rotting in Bugzilla.

Developers are using overlays, however, the majority of users aren't.
If the usage of overlays is to increase, then remote overlay support
should be added to emerge. Additionally, in order for users to be able
to contribute to the overlays, it would help if they had anonymous
read access.

> > Surely the solution is to provide that safety net within the tree?
>
> I cannot imagine a day when non-devs are given commit access to the
> Portage tree.  As long as that limitation remains in place, if we're
> going to reach out beyond our developer community, we have to reach
> out beyond the Portage tree too.

The safety net was intended for developers. Packages often get broken
in unexpected ways - something depends on it, a patch is conditional
on some USE flag or arch etc. It would be useful to get an email 5
minutes after a commit saying "you broke something", rather than a bug
report being filed a week later.

> > The current system of overlay usage is very annoying for users,
> > particularly when bugs are hanging around with packages in the tree,
> > and after filing bug reports the user is told that the bug is already
> > fixed in the overlay. Or when new packages are added to overlays
> > instead of the tree. How are users expected to find them?
>
> Users have pre-conceived ideas about the contents of the Portage tree.
>  I've seen first-hand how badly users react when a hard-masked package
> in the tree is withdrawn because it was an experimental approach that
> ultimately failed.  Users have unrealistic expectations about the
> tree.

I don't think it is unrealistic to expect that if a user puts a lot of
work into an ebuild, and it works, then it should somehow end up in
the tree. Unfortunately the options at the moment are to either reject
the ebuild, leave it to rot in bugzilla, or recruit the user as a
developer. Rejecting isn't very nice, the amount of effort and
barriers to become a dev are too great, so we end up with good ebuilds
not being added. Adding the ebuilds to overlays is one option, but
then other users will be expected to find an overlay with their
package in, and then add it to make.conf. As the number of overlays
increases, the amount of effort in synchronising dependencies and
dealing with other problems between them will increase.

Maybe in the real world managing the relationships between overlays
won't be as big a problem as it appears it could be.

> [snip]  You have good ideas.  What are you doing to make them happen?

Not much - time is a great constraint, and writing emails takes much
less time than writing code...

-- 
gentoo-dev@g.o mailing list