2016-01-30 15:26 GMT+01:00 Paul Menzel paulepanter@users.sourceforge.net:
But then, I wondered why I was not aware of that section in the development guidelines [2], and wanted to read up on it. While at it, I also looked through the history, and there I see, that it was only added [3] on the same day.
We had mentions of intel assembler syntax on the list over the decades (all 1.5 of them, proposed starting point for web based searches: site:www.coreboot.org/pipermail/coreboot/ -gerrit intel syntax), and it was always clear that coreboot uses AT&T syntax for x86. The collective consciousness (with apologies to Durkheim) was pretty consistent here.
The reason why this was added now is that people insisted that as long as there's no written down hard rule about it, everything is fair game. Personally, I'm not a huge fan of this model, but after the power games surrounding this topic already took forever (may include traces of hyperbole), it was the most economic decision to just nail it down.
- If there is objection, and no agreement can be reached, the proposal(s) should go up for a vote. The vote period should be at least one week.
There exists no electorate (or to state it more constructively: who gets to vote?)
No idea, but I’d think it’d be only fair to revert the changes made this months, and discuss them first.
With all the time already wasted on the assembly syntax issue (and no chance for a different outcome), and everything else looking like context-preserving clarifications (eg. GPL -> GPLv2) or harmless updates (bug tracker) I don't see a need for that. This also assumes both that your proposal takes effect, and is effective retroactively.
The main problem here (if any) was the lack of notification after changing the document. Given the limited impact (there were no other instances of .intel_syntax out there, and folks generally knew to use AT&T syntax), it probably wasn't considered a big deal.
Patrick