Background for those who haven't seen the discussion on IRC. There is a ongoing debate if the F15 effort should initially target to build F15 GA (original release) or F15 with current updates. Here is my views. In the stage4 distribution bootstrap we are seeing an annoyingly high rate of FTBFS issues where the issue is already fixed by an update, or in f16/rawhide. The resolution to these is that we pull in the updated srpms as needed while making sure needed changes gets into the f15 branch in git (if not already) for future updates. The question now is if we at this stage simply should pull in all the updates from F15, instead of continuing trying to build as close to GA as possible. The procssing time for building the packages is not really an issue. The available computing power by far outweights the available resources looking into build issues. I am of the opinion that the current updates should be imported. This should reduce the number of FTBFS issues and also get rid of most chain rebuilds needed while resolving build issues by importing updates. It may also cause some new ones, but my guess is far less than it solves. Trying to get the distribution built as close to a certain date is to me a much saner startingpoint to then start rolling forward from with updates than the current mix of GA and random fully updated packages of much later date, and would more closely resemble the build environment in mainline (which is always with current updates plus perhaps some overrides, the number of current packages actually compiled to the GA set is small) Also, I see a risk in that we later down the road of F15 starts subtly breaking things because updates do not get built at all in the order intended. There is updates in F15 which need careful ordering to build correctly, but this information is ofent not recorded in BuildRequires and is therefore lost in the current process, resulting in undefined outcome when later rolling forward with the rest of the updates. And no, recording it in BuildRequires is not the right solution to this problem for several reasons. But that is a topic for a separate mail is someone are interested. Also, in a general quality point of view, I see only benefits in having as many updates as possible rolled into the release as early as possible, and that the release which will eventually happen is as up to date as possible minimizing security issues and other bugs. Please note that the stage4 distribution bootstrap is unique in the sense that it's all a scratch build without locked package release, which means that during stage4 we can easily shake out any mishaps from build order without having to bump package releases. Some of the issues I worry about have already been seen where packages have needed to be rebuilt because of other packages being updated, but can't really tell if that's due to the updates or due to the general state of things in stage3&4 which haven't always been the prettiest. But that's also one of the purposes of having the stage4 step to enable issues to get sorted out with less pain. Once we move over to koji things will become more strict and shaking out issues takes longer time. Regards Henrik _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
