Re: [gentoo-dev] Official overlay support

["Stuart Herbert" <stuart.herbert@gmail.com>]

Hi Chris,

On 3/23/06, Chris Bainbridge <chris.bainbridge@gmail.com> wrote:
> I think that the
> use of overlays is more a symptom of a problem with portage. Overlay
> problems:

[snip]

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.

I'm not saying overlays are for everyone.  It's one approach that some
groups like.  You don't have to use an overlay yourself for your work
if it's an approach that doesn't work for you.  Overlays are not about
to become a mandatory way of working around here.

> 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 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.

If developers are telling users in Bugzilla that bugs are fixed in the
overlay, it's the responsibility of the developers to tell the users
where to go to get those fixes.  I'd have thought that was basic
common sense.  Establishing overlays.g.o as the usual place to go will
help with this, as will promoting very helpful tools such as layman.

> Another thing that needs fixing is the massive number of packages that
> aren't really maintained.

That's a very valid concern.  Overlays can help here, as explained by
the Haskell team, because they make it possible for more people to
contribute.  They're more than a technical solution ... they're a
social tool to build a more sustainable team around.

> What's
> worse is that in a lot of these cases there will be a user on bugs.g.o
> posting fixes and new ebuilds, and yet they never make it into the
> tree.

I'm finding that overlays address this specific scenario very
successfully.  I talk to those users and find out if they're willing
to contribute to an overlay.  More often than not, I find that the
fixes and new ebuilds are coming from a personal overlay that the user
is maintaining anyway.  Being able to commit directly to a shared
overlay means that they can get more involved ... and it gives me a
good level of interaction to help decide whether the person is worth
recruiting as a full-blown dev or not.

> A system where developer ebuilds are kept in the tree, and users have
> a way to automatically contribute ebuilds, either human reviewed, or
> in some reputation based system, would be very useful.

The overlays project doesn't prevent this system being developed or
introduced at all.  We're not looking to corner the market at all. 
We're only providing a resource which will be useful to some teams and
developers.

> Users also need feedback

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

> I'm not sure whether the answer is more openness of the existing
> system, some custom submission flow system, or a distributed SCM, but
> I do think there's a lot that could be changed to make things better.

I don't think that there is any one approach that will work for all
devs, all non-devs, all the time.  What I'm doing here is resourcing
one specific approach, and working with Infra and User Relations to
deliver something that provides one bridge between the developer and
non-dev community.  We will need other bridges to be built too.

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list