(I am replying to various messages of the thread within this single email. Hence the quotes below are of different people.)
For those who missed it on IRC, Stefan (Reinauer) has proposed retiring SVN and patch work in favor of Git and (likely) Gerrit + Jenkins. Maintaining SVN and Patchwork represents a surprisingly large maintenance burden on top of Git and Gerrit that coreboot uses. Additionally, many in the community work around SVN's limitations by mirroring the project at places like Github anyway.
My counterproposal is to use gitub instead of Gerrit. - I really can't stand gerrit's interface. - We (relatively) often get patches from one-time contributors which is way easier on github because "everybody" has an account there and knows how to work with it (and if not it is straight forward compared to gerrit). - We don't really need jenkins. I am not a big fan of CI although I am a fan of build testing (hence flashrom is build tested for over 30 architecture/OS combinations manually). Depending on how it would be to interface my build bot with jenkins it would however be an improvement (not sure if it is worth it though). - The only reason to avoid github for me would be due to its proprietary nature and related problems (lock-in etc). Please give me other reasons if you prefer coreboot.org-hosted gerrit over github.
Though I know stefanct often makes small corrections/modifications to patches before submitting them (because our code review process makes even small amounts of back-and-forth comments so cumbersome). At least this way such changes can be tracked trivially on-line by diffing the N and N-1 patch revisions in gerrit.
The reason is not because the back-and-forth is cumbersome but because I am a perfectionist who does not want to bother others with my annoying views of details and I don't expect anybody to care about these changes like me (this does not always hold). The same goes for commit messages. With Carl-Daniel I do exchange my views about these kind of things *if* there is any exchange that is ;)
If there really is a large demand for a non-svn hosting, I would be open to using mercurial (as master) because it at least has some sort of usability and can provide (conceptually limited) version numbers. I have worked for a few years with mercurial and the version numbers are extremely helpful even if they are per-branch and only semi-stable.
Just to make things clear here: I won't even discuss this option - it is none. If you want to use another VCS management tool/interface then you are free to do so, but you are the only person known to prefer something else than git so you have to take on the burden and not force everybody else to as it has been up to now - this has to and will end.
The auto-tag of every commit sounds like an option I could agree with. It would preserve the convenience of the global strong svn commit ID even for git. However, I don't know if this would be acceptable for Stefan (especially from a merging perspective).
We have the infrastructure for using this kind of version strings since about 2,5 years and there is a patch that would make flashrom use them in prints which is lingering uncommented in the mailing list since August 2013. It might not be exactly what we want eventually, but if there are no comments I'll have to decide on something...
My current plan is to do a 0.9.9 release in January 2016 and switch to git afterwards. I'd like to keep patchwork at least for a while and figure out a way to keep the patches.