Do we want extras/testing/{4, 5} repos (was Re: Packaging review guidelines clarification)

[Dan Williams]

On Sat, 2006-02-18 at 14:28 -0500, Jeff Spaleta wrote:
> On 2/18/06, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> > I know, it doesn't work to well with update-testing in core -- but it's
> > IMHO better then no testing at all.
> 
> If this policy goes in I'd want an established  loophole that allows
> hot fix updates to fix brokenness that made it through the "testing"
> timeout without comment and not just security updates.

So this is appearing to get more and more complicated.  I'm not sure
adding more process onto this is the best thing; more process is (a)
confusing and (b) a damper on participation.  Though we don't want crap
packages getting through, is the situation all that bad now?

> And yo have to watch out for how this mandatory tree complicates the
> building of other packages which depend on packages sitting in the
> testing tree awaiting the timeout to expire.  If the buildsystem
> automatically uses packages in this tree, then you'll have to have a
> way to expidite packages out of this tree before the timeout if a
> security hotfix for a depedant package needs to get released to keep
> depchains clean.

Exactly; we get into a situation where somebody gets to decide whether
the package is important enough to be expedited, and then either an
admin of Extras or the person themselves gets to move the package to the
main repo.  That's more process.

> If this tree is not automatically included in the buildsystem you'll
> have to have some mechanism by which maintainers can request it be
> included when they are doing a set of packages in a dependacy chain,
> to avoid the mandatory timeout from getting in the way.

Whee, more layers of complexity.

> I'd like to see this implemented on a probational basis and then
> re-evaluated to see if the timeout based testing tree is a net benefit
> or a net hinderance.

What Red Hat has, in many circumstances, found with the -testing repos
of Fedora Core is that packages there don't really get the testing they
deserve.  Not enough people actually test them or use them to make it
all that worthwhile.  There just isn't that much response to -testing.

> The non-published scratch tree idea I think is good regardless of what
> happens with a pre-release testing tree.

Yeah, this is still a good idea I think.

Again though, I don't think adding more complexity and forking multiple
repos and package sets here is the answer.  I guess I view the
scratchpad/testing stuff as more of a ground for making sure your
package compiles on PPC before you do the final build.

Dan