Dear coreboot folks,
I’d like to request for a policy on how the coreboot development guidelines are changed.
### Background ###
The discussion in patch set #11784 [1] confused me quite a bit.
Especially, seeing Aaron’s quote of the development guidelines I thought, why is this even discussed.
https://www.coreboot.org/Development_Guidelines#Assembly_Language states: "To keep the code consistent across the different supported platforms, AT&T syntax is to be used through-out the project. We are working actively on replacing the existing Intel syntax code with AT&T syntax. No new Intel syntax code is allowed into the project."
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.
I thought that editing rights for that page were blocked, because changes without discussion shouldn’t be made.
Further on, I’d like changes to the development guidelines be announced in the official forum, which is this mailing list, so that developers, normally not reading the guidelines every day, are made aware of that.
### Proposal ###
Changes to the development guidelines can only be made, when the following criteria are met.
1. A proposal of the change was sent to the list tagged with [RFC]. 2. The proposal was up for discussion for at least two weeks. 3. If there is no objection, the change can be made. 4. 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. 5. Changes have to be announced to the list.
### Past changes ###
No idea, but I’d think it’d be only fair to revert the changes made this months, and discuss them first.
Thanks,
Paul
[1] https://review.coreboot.org/11784 [2] https://www.coreboot.org/Development_Guidelines#Assembly_Language [3] https://www.coreboot.org/index.php?title=Development_Guidelines&type=rev...
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
The requirement for ATT syntax was set informally in 2001, when I had some partners from U. Md. who were advocating for Intel syntax. We discovered that having two syntaxes is unworkable.
From that time we assumed that everyone would use a common syntax. It
certainly never occurred to us that we had to say it explicitly, since it seems obvious that uniform assembly syntax is a good idea, and that the syntax we currently use, and that our tools use, should determine the assembly syntax for new code.
The change to the guidelines is hence a codification of a practice that goes back to the project's beginnings.
thanks
ron
-
Patrick Georgi -
Paul Menzel -
ron minnich