Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
On 02/01/2016 11:36 AM, Martin Roth wrote: > What I don't read in that blog post is anything about the > coreboot project being a democracy. I'd normally find such a statement very disappointing, but I'm pretty certain you're off on that one. I'm not sure how involved you've been in coreboot public before leaving SAGE -- I've mostly known your name from patches Marc submitted. What I can tell you with great confidence is that the picture you try to portray of coreboot has historically not been true. I've been around for a long time, maybe too long, and I remember many an issue having been publicly discussed. I remember cases where things were brought up for discussion, and the so-called leadership team decided the exact opposite of what it had intended. I remember the switch to git and gerrit, and I remember seeing quite some back and forth on the issue. I'm not sure why you have such a dark picture of coreboot in your mind. I've haven't heard anyone from the so-called "coreboot leadership" team make the claims you do. I'm sorry you feel that way, but that shouldn't be a reason to shut down Paul's proposal > Please note that these are just my own personal thoughts on these > subjects Exactly! Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
I meant to send this to the mailing list on Saturday, but ended up just sending it to Paul by accident. Paul, This thread quickly followed one point that you commented on, but has so far not touched much on one of your other issues. This is the issue of leadership of the coreboot community. You might want to look at Stefan's blog post "on coreboot leadership" from May of last year - http://blogs.coreboot.org/blog/2015/05/11/on-coreboot-leadership/ The way that I read it is that anyone is welcome to contribute ideas and opinions. Stefan may poll people for their opinions at times as well. What I don't read in that blog post is anything about the coreboot project being a democracy. I think that Stefan makes it pretty clear that the coreboot project has a leader, even though he believes in a hands-off approach. If people think that there are things that need to be discussed, I've found that Stefan, Ron and the rest are very welcoming of reasonable and constructive discussion. Regarding announcements of changes to policy, maybe something could be set up so that changes to certain wiki pages would automatically be posted to the mailing list. Please note that these are just my own personal thoughts on these subjects, and are in no way trying to state any official coreboot policy. Martin On Mon, Feb 1, 2016 at 11:30 AM, Alex Gagniuc wrote: > On Sun, Jan 31, 2016 at 2:24 PM, Stefan Reinauer > wrote: >> >> That is a really surprising statement coming from you, Alex, as you and I >> have discussed this very topic in person several times > > And as I have said in those very same discussions, decisions about > coreboot shold be done publicly. You're also portraying a distorted > picture of what was actually discussed, but it was still a private > conversation and has no bearing towards what Paul pointed out. > > Going back to Paul's proposal, he noted that an official project > guideline had been modified with neither public mail discussion, nor > community oversight. This was not a "minor typo fix" or > "clarification". I count three different changes which were made this > way. And I think Paul nailed it with his proposal. > > I fully support Paul's proposal. > > On Sat, Jan 30, 2016 at 6:54 PM, Martin Roth wrote: >> There was significant discussion in several >> meetings about the reasons for and against standardizing on AT&T >> syntax. > > As I've explained above, private conversations are not the proper > forum to make decisions related to coreboot. I realize you and others > involved are wearing two hats, and sometimes it's hard to tell which > hat you're wearing, either for you, or observers. Please consider the > image portrayed on your employer, when a group of its employees > unilaterally discusses, changes, then enforces rules in a public > project. I think Paul's proposal fixes this issue. > >> If you have a reason for using Intel syntax that is really more >> persuasive than keeping the asm code in the project consistent, feel >> free to state it. > > While I have a lot to say of the matter, this is not the appropriate > place. This discussion is about a change to a policy, not a > development guideline. Let's focus on what Paul is saying here. > > Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
On Sun, Jan 31, 2016 at 2:24 PM, Stefan Reinauer wrote: > > That is a really surprising statement coming from you, Alex, as you and I > have discussed this very topic in person several times And as I have said in those very same discussions, decisions about coreboot shold be done publicly. You're also portraying a distorted picture of what was actually discussed, but it was still a private conversation and has no bearing towards what Paul pointed out. Going back to Paul's proposal, he noted that an official project guideline had been modified with neither public mail discussion, nor community oversight. This was not a "minor typo fix" or "clarification". I count three different changes which were made this way. And I think Paul nailed it with his proposal. I fully support Paul's proposal. On Sat, Jan 30, 2016 at 6:54 PM, Martin Roth wrote: > There was significant discussion in several > meetings about the reasons for and against standardizing on AT&T > syntax. As I've explained above, private conversations are not the proper forum to make decisions related to coreboot. I realize you and others involved are wearing two hats, and sometimes it's hard to tell which hat you're wearing, either for you, or observers. Please consider the image portrayed on your employer, when a group of its employees unilaterally discusses, changes, then enforces rules in a public project. I think Paul's proposal fixes this issue. > If you have a reason for using Intel syntax that is really more > persuasive than keeping the asm code in the project consistent, feel > free to state it. While I have a lot to say of the matter, this is not the appropriate place. This discussion is about a change to a policy, not a development guideline. Let's focus on what Paul is saying here. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
* Alex G. [160131 00:05]: > I conclude from these, that your assertion that this has been an > unspoken rule, is not true. Furthermore, I believe that this arbitrary > change was done as an act of spite towards a set of engineers. Also, > since you, and the rest of the coreboot leadership have shown a pattern > of first discussing changes to the project publicly, on the mailing > list, I conclude that a discussion about this issue was deliberately > avoided in order to prevent those engineers, as well as other coreboot > community members, from presenting their arguments. That is a really surprising statement coming from you, Alex, as you and I have discussed this very topic in person several times, and I have explained to you why I initially checked in Scott's patches with mixed syntax and we both had agreed that in the long run the code has to be rewritted in AT&T syntax. So now you are using the fact that there is no log on the mailing list about this discussion to hurt the project and create some sort of artificial divide in the community once again. I am really disappointed in you. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
Alex, Please stop already. We know you don't agree with the decision. Stefan has agreed privately that he shouldn't have submitted those, and that it set a bad precedent. As you say in your email, *YOU* even questioned it when he did it, and he agreed that he would change them from Intel syntax to AT&T syntax. The "change" WAS to formalize an unwritten rule that had been broken a few times in the past. There was significant discussion in several meetings about the reasons for and against standardizing on AT&T syntax. Many of us, including myself, learned x86 assembly using Intel syntax, and find it easier to read. Mixing Intel syntax with AT&T syntax is just confusing and seems like bad practice. Because of this, the decision was made to go with AT&T syntax only. It was NOT done to spite you, whatever you might believe. If you have a reason for using Intel syntax that is really more persuasive than keeping the asm code in the project consistent, feel free to state it. Otherwise, PLEASE let's move on. Martin On Sat, Jan 30, 2016 at 5:44 PM, ron minnich wrote: > > > On Sat, Jan 30, 2016 at 3:06 PM Alex G. wrote: >> >> Furthermore, I believe that this arbitrary >> change was done as an act of spite towards a set of engineers. > > > Well, wow. This just got weird. I think I'm done with this discussion. > > ron > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
On Sat, Jan 30, 2016 at 3:06 PM Alex G. wrote: > Furthermore, I believe that this arbitrary > change was done as an act of spite towards a set of engineers. Well, wow. This just got weird. I think I'm done with this discussion. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
On 01/30/2016 11:30 AM, ron minnich wrote: > The change to the guidelines is hence a codification of a practice that > goes back to the project's beginnings. I find that statement inaccurate. This practice had not been an issue in the past, on patches that you yourself approved. Mixed syntaxes have been present in the codebase for a while. See EXHIBIT A. EXHIBIT B shows a patch, mid last year, when a new intel_syntax code was introduced. There was only one comment (following) about the syntax. The patch was approved by you, Ron, without mentioning what you claim has been a practice. > Patrick Georgi, Jul 13, 2015 > follow up patch: we don't really want two _syntaxes in one file_, right? (emphasis added) The comment clearly addresses the issue of mixing two syntaxes within a file. It does not mention "a practice that goes back to the project's beginnings", nor does it mention that either "AT&T syntax is to be used through-out the project", or "No new Intel syntax code is allowed into the project." EXHIBIT C, shows another such patch that, you, have also approved, Ron. The comment got no replies. > Ronald G. Minnich, Oct 30 10:43 AM > why intel syntax _in a file that is att syntax_? it's a real oportunity for a buggy time.+2'ing because you promised me you're rewrite it. (emphasis added) Notice how the issue here is strictly the mixing of syntaxes within the same file. EXHIBIT D shows another such patch, this time approved by me. I have made a comment about the issue of mixed syntax. > Alexandru Gagniuc, Jul 17, 2015 > Really? Mixed syntax in the same file? This also addresses strictly the issue of mixing of syntaxes within the same file. EXHIBIT E shows another patch, that you yourself approved. This time, there was not even a mention of mixed syntaxes. I conclude from these, that your assertion that this has been an unspoken rule, is not true. Furthermore, I believe that this arbitrary change was done as an act of spite towards a set of engineers. Also, since you, and the rest of the coreboot leadership have shown a pattern of first discussing changes to the project publicly, on the mailing list, I conclude that a discussion about this issue was deliberately avoided in order to prevent those engineers, as well as other coreboot community members, from presenting their arguments. Alex ### EXHIBIT A: Presence of .intel_syntax ### * 4a30ab9 cpu/amd: remove .intel_syntax * 0302b06 arch/x86: remove .intel_syntax * c7b2b7c cbfstool: Fix potential error when using hash attribute $ git reset --hard c7b2b7c67dc8afb52c3dc8e9297e5ed81fa22674 $ git grep intel_syntax src/arch/x86/boot.c:".intel_syntax noprefix\n\t" src/arch/x86/c_start.S:.intel_syntax noprefix src/arch/x86/wakeup.S: .intel_syntax noprefix src/cpu/amd/agesa/cache_as_ram.inc: .intel_syntax noprefix src/cpu/amd/pi/cache_as_ram.inc: .intel_syntax noprefix ### EXHIBIT B: src/arch/x86/[boot.c, c_start.S] ### $ git blame src/arch/x86/boot.c |grep intel_syntax 9693885a src/arch/x86/boot/boot.c (Stefan Reinauer 2015-06-18 01:23:48 -0700 63) ".intel_syntax noprefix\n\t" $ git blame src/arch/x86/c_start.S |grep intel_syntax 9693885a src/arch/x86/lib/c_start.S (Stefan Reinauer 2015-06-18 01:23:48 -0700 403) .intel_syntax noprefix $ git show 9693885a commit 9693885ad88d21ead7bd9ebc32f3e4901841b18b Author: Stefan Reinauer Date: Thu Jun 18 01:23:48 2015 -0700 x86: Port x86 over to compile cleanly with x86-64 Change-Id: I26f1bbf027435be593f11bce4780111dcaf7cb86 Signed-off-by: Stefan Reinauer Signed-off-by: Scott Duplichan Reviewed-on: http://review.coreboot.org/10586 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand Reviewed-by: Ronald G. Minnich ### EXHIBIT C: src/arch/x86/wakeup.S ### $ git blame src/arch/x86/wakeup.S |grep intel_syntax ac901e6b src/arch/x86/wakeup.S (Stefan Reinauer 2015-07-31 16:46:28 -0700 32).intel_syntax noprefix $ git show ac901e6b commit ac901e6bedc98d115ebb8089afd8f67aef39c000 Author: Stefan Reinauer Date: Fri Jul 31 16:46:28 2015 -0700 wakeup: Switch back to 32bit mode first On x86_64 we need to leave long mode before we can switch to 16bit mode. Oh joy! When's my 64bit resume pointer coming? Why didn't this get caught earlier? Seems the Asrock E350M2 didn't do Suspend/Resume? Yes, I know it's Intel syntax. Will be converted to AT&T syntax as soon as the whole thing actually works.. 8) Change-Id: Ic51869cf67d842041f8842cd9964d72a024c335f Signed-off-by: Stefan Reinauer Reviewed-on: http://review.coreboot.org/11106 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich ### EXHIBIT D: src/cpu/amd/agesa/cache_as_ram.inc ### $ git blame src/cpu/amd/agesa/cache_as_ram.inc |grep intel_syntax 67b9430b src/cpu/amd/agesa/cache_as_ram.inc (Stefan Reinauer 2015-06-18 01:14:01 -0700 66) .intel_syntax noprefix $ git show 67b9430b co
Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
2016-01-30 15:26 GMT+01:00 Paul Menzel : > 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. >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. 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 -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [RFC] Proposal for policy for changing the development guidelines
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=revision&diff=17850&oldid=17709 signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot