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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
