Adding packages to buildroot directly from updates-testing

[Henrik Nordström]

mån 2010-12-20 klockan 18:12 -0500 skrev Matt McCutchen:

> That will work, assuming the user has permission to do the tagging; it
> is essentially a buildroot override in reverse.  So the question is just
> what we want to optimize for: more testing of packages while they are in
> testing, or less fallout when a package in testing is broken.  Or if the
> infrastructure problems are solved, we could use custom tags and get the
> best of both worlds.

Using the buildroots for testing is not the right approach for
increasing the level of testing.

Any use of testing packages while building should be requested by the
specific build, not as a general blanket. 

In special cases by the ones responsible for the package in testing may
request to have it enabled in the build root, such as when needed for a
mass rebuild of dependent packages affected by the update. This should
only be done when the package is considered completed testing and ready
to be pushed to stable but not comfortable with doing so until dependent
packages have been rebuilt (i.e. a sobump or similar).

It's not often that there is chain dependencies requiring builds using
packages in testing. In the normal case the build will be just fine
using the "older" release and there won't be any conflict. Most updates
are backward ABI compatible meaning older builds of depending packages
will run fine to newer versions, but the reverse is often not true

In several cases there will be conflict if the a build uses the newer
version, and then the built package then need to be held back until it's
dependencies have also been pushed further delaying when it can be
declared stable.

And in some cases there will be testing packages that is quite broken,
resulting not in failed builds but badly built packages. If those are
automatically used for building then there is a risk that such hidden
bugs unexpectedly passes testing checks as most often not all functions
of a package are tested when testing a simple update (i.e. simple
bugfix), only the parts the update touches and basic functionality.

And in several cases updates in testing are withdrawn or updated due to
issues discovered in testing, and this results in a high level of
uncertainness regarding the status of the builds that built to that
testing update, further increasing the workload on package maintainers,
and further extending delays in pushing updates to stable (needing
rebuild and renewed testing).

However if there is sufficient computing resources available in the
build farms then doing a shadow scratch build using testing makes sense
for the purpose of increasing testing, solely for the purpose of
increasing the level of testing of -devel packages.

Regards
Henrik