On Mon, Jun 22, 2009 at 01:14:55PM +0530, Rahul Sundaram wrote: >On 06/22/2009 01:01 PM, Jesse Keating wrote: > >> >> If you have any ideas I'd like to hear them. A super epoch has already >> been suggested but that just masks the problem and may cause unwanted >> downgrades. Any solution either involves severly limiting what kind of >> updates can be done or requiring network access during upgrades. > >I can't think of any fool proof solutions but there are a couple of >things that might help: > >* Run checks on upgrade paths and inform the maintainers when are about >to break an upgrade path (ie) before signing it. I noticed a few >maintainers I talked to just weren't aware they were doing so and >neither were they aware of the %dist.1 trick to workaround the problem >atleast in some cases. They might choose to delay an update where it is >feasible to do so. Not sure what we can do about security updates or >critical bug fixes breaking the upgrade path for the next release. >Ideally, the maintainer should have pushed it in sync for the two >releases. I think you mean "before pushing" rather than signing, but this idea has been suggested before. The good thing is, we could possibly tie this into bodhi during update submission. It's fairly easy to do NEVR comparisons and we don't need full repos for the upgrade path checks to happen since we can use the update information and koji tags. The bad thing is, this suffers from the same problems every other auto-QA suggestion has. Namely, no code, nobody with time to write the code, and it potentially slows things down even more. josh -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
