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

[Chris Gianelloni]

On Fri, 2006-01-06 at 09:00 +0000, Chris Bainbridge wrote:
> 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.

This is probably the primary reason it died.  This, of course, ties in
greatly to #2.

> 2)  Lack of interest. Most developers aren't interested in supporting
> "old" packages.

Again, another of the issues.  Another problem was the insistence on
using some form of subset of the tree.  Using a subset of the tree
actually *increases* the workload rather than reduces it.  The only real
"subset" that can easily work without dramatically increasing workload
is to limit to only arch rather than both arch and ~arch.  This is
simply because it can be scripted.

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

While I don't think enterprise support is necessary to accomplish a
stable portage tree, it certainly wouldn't hurt.

Truthfully, for any "large" enterprise, the company will be maintaining
a fair number of their own packages, with custom patches and whatnot.
Where I work, we use Red Hat Enterprise Linux.  Why?  Because we can pay
for support.  That isn't the point I am going to make here, however.  We
also have to maintain several hundred RPM packages that either are not
included in RHEL or modified by us in some way.  What this means is we
are now in the business of maintaining a package set, using arguably
inferior tools versus ebuilds and portage.  The binary support in
portage does make it very possible to "build once, deploy everywhere"
quite easily.

> 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 current stable proposals do, yes.

I'll post up my proposal (in another email), which I believe I had given
a couple years ago, somewhere around when GLEP19 was introduced.  Given
it has been a while, I can't say for certain exactly what order anything
came about in, so I won't even try.

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

All of these solutions I think are good period, not just to be for some
"enterprise" usage, especially multiple repositories (it's coming, yay!)
and automated build systems.

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