Re: [gentoo-dev] Official overlay support

[Chris Gianelloni]

On Thu, 2006-03-23 at 10:09 +0000, Chris Bainbridge wrote:
> Reduced responsibility for package QA  (I expect "we don't care about
> overlays" to become a standard response on bugs.g.o)

You will *definitely* get this from developers that won't be using the
overlays.

Let's just say you decide to use a toolchain overlay and it exposes some
problem in random app foo because you're using gcc 5.1.99 and we only
have 4.0 in the tree.  You file a bug against package foo without a
patch.  I'm the maintainer.  You've now made me spend my time supporting
something that isn't even in the tree, and could be an artifact of the
overlay itself and something that will *never* end up in the tree.  Why
should I do this?  What we have done here is actually *reduced* the
amount of productive work that I can do by forcing me to deal with these
overlays, even if I choose not to participate.

> Surely the solution is to provide that safety net within the tree?
> Rather than pushing changes into a live tree, push them into a testing
> tree, then after they pass repoman/QA checks, and a build check, apply
> the changes to the live tree, otherwise email a rejection. And allow
> developers to add their own testing ebuilds to the tree (for a start,
> they will be more widely tested).

While this would be great, there is one major obstacle that people miss.
Horsepower.

Let's say I add a new openoffice ebuild to the tree for a security bug.
We now have to wait how many hours for it to hit the tree?  What if the
KDE team is committing a new KDE version at the same time?  I'm sure you
can guess how this could bring all of our development to a complete and
grinding halt.

I wouldn't mind seeing an actual "unstable" designation added to
KEYWORDS.  The basic premise would be like package.mask packages where
things can be done *within the tree* but still has the same air of "this
might be totally busted at some point" as overlays.  Users would be very
unlikely to run unstable on their machines.  Heck, we could even make it
impossible to actually use unstable globally if we wanted to.  The whole
point is that I completely agree with you, a better solution would be to
try to work within the tree to resolve this problem, rather than moving
it outside the tree and into hundreds of individual overlays, which
could be conflicting with each other.

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

They should not have to.  It's as simple as that.  Bugs in the tree
should be fixed in the tree.  New packages should be added to the tree.
If it isn't a candidate for ~arch, then add it under package.mask
instead.  That is why we have package.mask in the first place.

> Another thing that needs fixing is the massive number of packages that
> aren't really maintained. Either the maintainer doesn't respond to
> bugs, or the package is maintained by a herd and so no one feels it's
> actually their responsibility to deal with the boring bugs, and when
> some developer outside of the herd comes across it, they feel like
> they can't fix the bug without stepping on someone's toes. 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.

This is really both a political/social problem and one of manpower.
There's a lot more users out there than there are developers.  There are
many developers out there who aren't quite so territorial.  The main
thing is us being civil with each other.  There are many times where a
developer wants to make a fix or change to a game.  If they ask us, we
let them.  It's that simple.  Heck, we usually ask them if they want to
maintain it.  Also, a herd is a group of packages, not a group of
developers.  A group of developers could share responsibility in looking
out for a herd (or many) but they are not a herd themselves.

> 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. Users also need
> feedback - how many times does a user submit an ebuild via bugzilla to
> be told that it doesn't meet QA standards? Why isn't there a system in
> place to run repoman/QA/build checks on user ebuilds/patches to make
> sure they are fixed *before* being submitted for inclusion into the
> tree? And if this could be linked to a bug reporting system where
> people report/fix individual ebuilds or packages, and I can just type
> 'gbugs -l pkgname' and get a list of problems and fixes that other
> people have proposed, even better.

Ebuilds that are human reviewed are exactly what we have now.  The
process isn't automated, but it cannot be automated if you expect human
review.  Automated review isn't possible, as it is very easy to work
around automated tests to do something completely malicious in an
ebuild.  There should *always* be the human factor before *anything*
makes it into the tree.  Our reputation and even the stake of Gentoo as
a whole depends on our reliability.

As for ebuilds meeting QA standards, most developers that I am aware of
will inform the user of how to make their ebuild better, and even point
them to relevant documentation to assist them, expecting the user to
make the changes.  This makes for better submission and informs the user
so they don't make the same mistake twice.  All in all, it is good for
all involved.  Any developer that is closing a bug without reason is in
the wrong.  It is as simple as that.  Saying something doesn't meet QA
is bunk *unless* they also point you to reasons *why* it fails QA.

As for bugs being posted, you're more than welcome to use "ALL pkgname"
as a search on bugzilla to get anything related to that package.
There's even a few command-line bugzilla query tools.

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

See, I 100% disagree that this is a technical problem.  It cannot have a
technical solution.  Want better developer/user relations?  Start
talking amongst ourselves.  Talk to other users.  Talk to other
developers.

I tend to think our biggest failure is communication.  Improve our
communication and we'll improve Gentoo.  Together.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux