On 6/1/07, Hans de Goede <j.w.r.degoede@xxxxxx> wrote:
If things will actually work with that, iow if packages in updates-testing will get QA approved in 1-2 workdays in general and then move to updates, then I think updates-testing will be a good idea, and the additional QA will be worth the delay.
Especially if we use the time that an initial package is in updates-testing to create package specific QA testing scripts to be used for later version of the package. I know there is a plan to hook something like beaker up into the update process. For new packages, that first time through updates-testing is the ideal time for QA people to focus on helping the maintainer create scripted tests that can be run automatically for later updates. We just don't have all the pieces in place yet, because we have to start somewhere.
What I'm against is the old updates-testing ways where a package would just linger for a week (esp if its a new package!) and the get moved to updates without having seen much testing if any at all. That way just adds a week delay without much benefits.
Here's the way I look at it... there is a larger plan to harness a testing framework into the update process exposed by bodhi. It's not all there yet granted, but I think its going to be easier to hook something like beaker up and make real headway with it if we make the decision right now to nominally send new packages into updates-testing and establish the process for beaker to tap into. We leave in place the flexibility for maintainers to argue with release-eng on a case by case basis to avoid updates-testing for new packages or updates, but we establish the expected process now, so that when something akin to beaker gets hooked in, its a smooth enhancement to an existing process. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
