On Tue, 21 Aug 2007 13:23:29 -0400 "Ray Strode" <halfline@xxxxxxxxx> wrote: > Why does it do that? Automated rebuilds are often done with low priority, so that normal priority builds aren't held up for days on end (it takes a long time to build 3K packages x 4 arches). If you were to go in after the automation came along and updated cvs and scheduled the build, and /you/ again bumped CVS and started a build, your build would complete before the automated one, then the automated one would complete and actually be the 'latest' package since the last tagged package wins. Your change would be lost. To prevent this, you need to wait until the automated build completes, or you have to get rel-eng to cancel the build. It adds a lot of confusion as to the state of the build system. > > Plus as stated other places > > there are still a very large number of packages that have improper > > License tags in specs so those really could get updated at the same > > time as the maintainer driven build, to prevent further spurious > > builds. > License tags don't have to be fixed before test 2, though, other > things like getting features in before feature freeze, and making the > release more stable should take priority. Rebuilding for licensing tags, since it is a rebuild action, does need to happen sooner than later so that we can catch any fallout from a rebuild. Doing builds later than earlier threatens stability which you're trying to achieve. Developing features isn't something that every person can do, if you had co-maintainers for your packages you could ask that they do your tedious rebuilds while you work on the feature stuff. This is a big reason why we opened the build system so that you /could/ assign resources where they're most needed and most wisely used. -- Jesse Keating Fedora -- All my bits are free, are yours?
Attachment:
signature.asc
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
