On Sun, 2006-02-19 at 07:57 +0100, Thorsten Leemhuis wrote: > Am Sonntag, den 19.02.2006, 05:47 +0100 schrieb Ralf Corsepius: > > On Sat, 2006-02-18 at 18:54 -0500, Dan Williams wrote: > > > On Sat, 2006-02-18 at 14:28 -0500, Jeff Spaleta wrote: > > > > On 2/18/06, Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> 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. > > I agree with your concerns and do not see much benefits. > > > > Why can't we have a maintainer must give explicit clearance to release a > > successfully built package policy instead of automatically releasing a > > package? > > > > That would mean, a successfully built package would end up in a > > publically accessible repo (or directory), but maintainers would have to > > explicitly give clearance for a package to be pushed to the official FE > > repos. > > We did this in fedora.us -- it worked, but didn't worked too well IMHO. You seem to forget about fedora.us's underdeveloped infrastructure. > Some packages stayed in the "pending" repo for weeks or even months > because nobody checked them. This is probably even more process then a > testing-repo and adds more bureaucracy for the maintainer; so it > probably (a) confusing and (b) a damper on participation. > > A defined testing repo with a automatic move to the public trees could > have the benefit that (a) multiple people can check the package easily > (just enable extras-testing, they get the packages with the next yum > update), (b) a package might be checked on multiple archs this way and > (c) it will be pushed even if the maintainer does nothing. If don't see much sense in this and don't see any need for it. What I sense as missing is: * Maintainers currently have no means to withdraw a miss-built package, even in obvious cases (E.g. package completed building successfully, but a configure check for an optional feature had failed, because another package had changed). * Maintainers have no means to provide "packages for testing" to individuals who reported a bug on their particular situation. Maintainers have to resort to shipping such testing packages from their private sites, and ... thereby don't have any means to provide binaries for archs they don't have access too. * Maintainers have no means to test building packages on archs they don't have access to. * In most cases, "testing" packages will not be connected to other packages, but will be try-n-error packages addressing issues against packages in FE(released). Setting up a testing _repo_ therefore is highly useless, because it would contain functionally broken packages. If we had a "pending" directory (no repodata), maintainers could initiate builds, check the built packages [1], direct individuals to manually downloading this package and to try a particular change they have applied for this built. Ralf [1] A problem I am frequently facing is: Buildsystem reported a successful built, but I didn't have any chance to look into the ppc-rpm before it has been released. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
