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
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
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
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.
Show replies by date
My philosophy, is fix it as early as possible so you don't have to
deal with the issue again. In otherwords, target the updates, get the
fixes into mainline via the proper channel of updates/testing and
possibly even back to the project source code. It isn't necessarily a
fast process and it can be extremely frustrating to some people. The
closer you are to current the easier/faster it makes the process.
There are ~3k packages. Fixing ARM specific issues is more important
then trying to find and isolate already resolved general build issues
or bugs especially given no one has built it entirely for ARM once and
there are probably still lots of ARM related issues. Once this gets
done once and everything is in mainline or the project source, it
should become a lot easier.
If you do find more general build issue, chances are you are also more
likely to get help being current or it is easier to get your patch in
upstream. Or the package maintainer or the software project itself is
more likely to help.
If you look at it the other way from the end user perspective, you
install, you get it on the network, the next thing you do is update it
so if you are starting from GA or from a point later in time, after
the update you are at the same spot anyway.
(IIRC after 2 weeks of the x86 F15 GA release, there were like 400
megs of updates available.)
This isn't everyone philosophy as this isn't an overnight process. It
can be -extremely- frustrating. If you get say the first 800 packages
in mainstream for ARM. By that time, the next release is out, and you
almost have to start over and go through the stage 1,2,3 again. The
hope is that of the 800 packages, you only have to fix a handful and
you can more quickly move to the packages, you didn't get to in the
last release (and I would probably deal with these by installgroups).
You can use the build environment for a while, but you are falling
further behind mainstream.
In otherwords, I would also suggest, once F16 gets to GA, which is
projected around late November. Someone needs to start with stage
1,2,3 again. This doesn't mean work can't continue on F15 branch,
fixing packages, and testing the import process into koji.
It is a lot like trying to push your car out of the mud. You go
forward, then have to backup and take another run at it as fast as you
can and get a little further until finally you get unstuck.