peter at stuge.se
Mon Apr 28 02:16:02 CEST 2008
I would like to release flashrom-1.0 before the weekend.
There was a bit of discussion on IRC tonight and I found there are
others who are also looking forward to a release.
Not so much because we think flashrom is currently in a particularly
awesome state, but rather because we would like to get it packaged,
distributed, used and marketed more - and that is really all version
numbers are good for anyway.
There are many pending patches in people's working copies that are on
their way into the repo, and that is great. I would like nothing more
than to make a 1.1 release shortly after 1.0, and I hope noone feels
that flashrom should freeze somehow just because it now has a version
I think flashrom will always be work in progress to a high degree,
especially since the probing can never be fool proof because of our
dearest PC architecture, but I still would like to make releases.
While some parts of trunk flashrom may not be production quality,
there are some parts that are indeed production quality and that have
been heavily used. I think 1.0 is a nice round number and a great
starting point for future improvements. It also communicates the fact
that at least parts of flashrom are very good and quite usable, as
has been the case for several years already. :)
I've made a preliminary roadmap or action plan for 1.0:
1 handle the possibility of NULL flash chip function pointer derefs
2 add a tested flag to the flash chip table, most will be untested now
3 Carl-Daniel has a patch with fake flash chips of different sizes
that is good to let people at least read the flash chip even if
there is no support. Either this goes in as is and we add a -C
--force-chip option (or similar) or we could make a special
--force-read command to avoid cluttering the flash chip list with
dirty fake chips.
4 go over text output to find and do possible UI improvements
5 change -s and -e into -S and -E, and change -E into -e with the
rationale that erase is much more common than "exclude end position"
6 make probes advisory rather than controlling? always have the user
confirm the probed chipset before continuing?
I can do 1, 2 and 4. If there is agreement I'd love to do 5 too.
In 4 I include adding a message for the user about the mainboards
that need to be specified manually when board probing fails.
Please share your thoughts - and in particular anything on 3 or 6.
The plan is to create a repos/tags/flashrom-1.0 tag of the rev that
goes into release, and publish the release with a tarball on the
Flashrom wiki page.
For a bit of fun (gotta have some fun! :) we can have codenames for
releases when we feel like it, the 1.0 favorite is "apt apology."
More must-have stuff before 1.0?
I don't want to add too much stuff, just trim away the worst rough
edges and make a release very soon.
More information about the coreboot