Rex Dieter wrote:
Tom Horsley wrote:
On Wed, 30 Sep 2009 15:51:52 +0200
Michael Schwendt wrote:
Skipping the updates-testing repo and pushing updates directly into the
updates repo is frowned upon.
I still can't understand why the repo update process isn't automated
at least to the extent of testing updates on a virtual machine
which has all optional packages installed to see if the updates
install correctly and the system still boots after the updates.
It's known, but implementing this is *hard*, and there are concerns how it
could impact the speed/performance of performing updates. Pushing updates
as-is already is a multi-hour operation, mind you.
I would hope that the time is proportional to the size of the changes, so
preventing sending of something broken would (or should, or might if you prefer)
avoid sending broken once and fixed later. That applies to the follow paragraph
as well.
OK, so a broken dep is found somewhere, now what? Stop the presses,
manually find what is broke, restart updates-push from the beginning? Not
fun. Hopefully, this scratches the surface to communicate how this is very
much a non-trivial thing to do.
Now, if you're interested in helping to make this a reality, I can help
facilitate getting in touch with those on the rel-eng side.
If it would help to catch the low hanging fruit by testing many of the updates,
it could be fairly easily done, although it would take a bit of machine effort
to run the test. Consider that changes in updates-testing would be subject to
some automated sanity check:
1 - create a qcow2 copy of the current sane VM (updated to yesterday)
2 - boot it
3 - have rc.local or similar download a list if packages to install or upgrade
over the network (this proves the network worked to start).
4 - run yum and install/upgrade the packages involved
5 - reboot
6 - if the system comes up send a message over the network saying it passed the
smoke test (proves the network still works).
Caveats:
- it doesn't test changes which break other network drivers or wireless
- needs to be run on each primary machine type
- doesn't test if the upgrade does what it should
- doesn't test display breakage
But it does test being able to apply the upgrades and have a sane system. And
that would have caught the latest few dependency issues, and saved a LOT of
hassle. It would allow things to be kicked out of the process without false
positives.
--
Bill Davidsen <davidsen@xxxxxxx>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
