On 06/01/06, Brian Harring <[EMAIL PROTECTED]> 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. -- [email protected] mailing list
