Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Bainbridge]

On 06/01/06, Brian Harring <ferringb@g.o> wrote:

> Probably better to iron out what y'all actually need and what the dev
> community is willing to put up with.
>
> Eg, would do some research into it, read the archives from last few
> wars over it, in general find (and address) the issues that lead to
> glep19 going still born.

The problems being:

1)  Manpower. There are already 10,000 open bugs in bugzilla (and
growing) without adding more.
2)  Lack of interest. Most developers aren't interested in supporting
"old" packages.
3)  The enterprise. Both of the above problems would be fixed if
enterprises were contributing developers and/or money. However, they
aren't, so why is that? The truth is most enterprises want to go to a
big company to buy their software. They want one homogeneous binary
system, not a flexible way of building packages from source, and they
want someone else to do it and be responsible for it.

Look at the arch/~arch split - as a guideline ebuilds are supposed to
move from ~arch -> arch after some reasonable period of time with no
bugs reported (eg. 30 days). Yet as the friendly script shows us,
there are many ebuilds that that stuck in ~arch for a long long time.
Why? The main reason is developer interest - a lot of people only run
~arch, so the motivation is reduced. It's difficult for users to help
- in the end it's easier to mark stuff ~arch in
/etc/portage/package.keywords than to file a bug requesting that some
developer test and change the ebuild. Proper testing of a tree
requires developers to run both arch and ~arch. The stable proposals
would add yet another tree to test.

The only way I can see to solve these problems is more automation.
Link bugs directly to individual versions (or sets) of ebuilds. Have a
defined process for marking stuff stable - either x days with no bugs,
and/or through sampling of users installed packages to see what is
actually installed out there. Bug voting would fix the disconnect
between users and devs (sometimes people are interested in working on
a random problem to help gentoo - at the moment it's difficult to see
which bugs are really the important ones to users). Decentralise
development - allow users to share their own patches in a searchable
system, rather than force everything through bugzilla; add support to
portage to utilise other peoples trees - the current system of devs
publishing overlays on their web pages/svn and users having to
manually wget or svn up is too difficult for users and removes ebuilds
from the tree - so they are less visible and get less testing. For QA
gentoo really needs a compile farm with automated compile, install and
test (from those ebuilds that support it).  Make the system smarter,
instead of throwing more people at the problem.

-- 
gentoo-dev@g.o mailing list