I was trying to test as much as I could before the release, but it’s really hard when you run into three or four bugs at a time. I’ve run into at least a dozen Anaconda bugs since the beta (maybe 2 dozen), many of which exist in the final Fedora 11 release. I even noticed three or four new ones this weekend.

The developers were doing a great job fixing the bugs, but they really needed a few more months to get everything done. Rewriting the storage system is a huge task, and it’s not the sort of thing that you push out before it’s done. When you do, you have to expect to see negative reviews and comments. I actually think that people have been remarkably positive, all things considered.

At this point, I think a Fedora 11.1 release, or at least a new updates.img, would be extremely helpful. Naturally, it would be good for the users because they would have a more installable release. However, it would be good for the developers because they would get a new round of testing and fewer duplicate reports.

Adam, thanks for making a point of patrolling some sites and offering information and assistance for people who’ve had a nonstandard experience with Anaconda. It sucks when we disenfranchise people with the installer, but people do need to know that the devs really are awesome and work spectacularly hard.

The updates.img is more complicated than just anaconda as it is also a releng issue. Its complicated and tense issue and it definitely puts manpower resource constraints front and center.

Its sort of a chicken and egg problem. There are priorities established by existing available manpower, so we build processes and policies which reinforce those prioritized choices that support the existing contributors. Once those policies are established it then becomes more difficult to incorporate a new team of people to work on something that was deemed a low priority for existing manpower if that low priority work intersects with the work the existing team is doing. I don’t have a suggestion to solve that without disruption of existing work and even then you risk short term negative impact until a new manpower is able to be recruited.

-jef

Of course, this could well be a ‘patches welcome’ situation. I’ll try and remember to ask the Anaconda devs if there’s a decent documentation for the process of creating updates.img. If so, I’m sure it would be possible for someone to volunteer to build updates.img with collected Anaconda fixes, publish and document these somewhere…it would be a useful project for sure.

I have a fairly heavily formatted main PC. I immediately hit a show-stopper when trying to install Fedora 11 during partitioning. I haven’t filed a bug.

Back in the days of Fedora 4 or 6, I put in an Anaconda bug report, with as much information as I could get, and I followed up on it if the developers asked questions.

The result: In a month, someone generated an updates.img to fix the bug … but *only* for the RHEL version that was based on the same code. But, for the Fedora that was having trouble installing, they basically answered with a politically correct “Screw you on getting an updates.img that works with Fedora. Just wait until Fedora N+1.”

Since then, I’ve followed along with installer bugs and their resolutions as a morbid hobby. The “you’re screwed for six months” seems to be standard Fedora policy for any bug like this, and it massively soured my personal desire to put in bug reports for Fedora. I even started trying to figure out how to “fix it myself”, but Ananconda was unusually inadequately-documented back then. Even the updates.img format itself was apparently be three different things, depending on what version of Fedora was being used. I haven’t ventured back into those waters since. Is it better documented now?

I understand the need for re-writes, etc, on this code, but Fedora needs to do better about things like updates.img files. They often exist for various installation issues, but they’re *never* official, instead put out by some-random-developer at some random URL, and even their existence is poorly publicized.

I’ve often wondered why there isn’t some nearly single-click mechanism in Fedora to combine a standard Fedora release ISO with a latest/official updates.img and write it out to a DVD, so that the burden of installer bugs is minimized with a 1.44MB download that can work with whatever ISO you’ve got already, instead of “wait until Fedora N+1″. I started looking at using mkisofs to do a multi-session dvd with an iso and an updates.img, but I haven’t gotten too much further. I’d like to see some form of post updates “Fedora 11.i2″ installer nomenclature/capability be added, but I’m not actually sure to whom to suggest that. Any pointers would be appreciated.

Just my thoughts,
GrangerX

1) Can we expose the testing matrix used as part of the marketing materials as a nudge for reviewers to do a review based on an install inside that matrix?

2) What more can we do to encourage people interested in more exotic situations outside the existing testing matrix to extend it prior to release?

3) And this is the toughest question of the bunch….
If you know there are going to be a significant number of regressions associated with extensive installer development going into a release cycle that are only going to be picked up at release… would it make sense to plan for and roll up installer updates post-release and plan for rel-releasing isos with the fixed installer?

-jef