[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Don't put new packages through updates-testing



On 6/1/07, Hans de Goede <j w r degoede hhs nl> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]