On Mon, Apr 20, 2009 at 12:12:04PM +0200, Luc Verhaegen wrote:
Flashrom: board_enables: reconstruct table.
This patch restores the pciid based board matching table. It makes this table readable and hackable again, and the only disadvantage is that the right margin is way beyond the rather dogmatic 80. All 0x0000 pci ids have been string replaced by 0 to more easily spot missing ids, and extra comments have been added to explain how the various entries are used.
Signed-Off-By: Luc Verhaegen libv@skynet.be
This is a recreation of a patch sent in earlier (back in january) to undo commit r3861.
It was created by string replacements only, no data was manually moved around, entries were just padded with spaces to adjust alignment. The name of "Intel Desktop Board D201GLY" was shortened to "Intel D201GLY" to keep the lines from becoming even longer. All 0x0000 pci-ids were string replaced to 0. All entries are nicely aligned now, with a comment at the top of the table to further ease understanding of this table. Comments were added to further explain the use of the entries of this table.
A lot of very recent motherboards seem to lack doubled up ids, or card ids. Maybe the authors of these lines should be contacted and asked to provide a bit more information to enable autodetection. It might also be a good idea to require dual pciids for every board to further force people to put some tought into the ids.
Luc Verhaegen.
On 20.04.2009 12:12, Luc Verhaegen wrote:
Flashrom: board_enables: reconstruct table.
This patch restores the pciid based board matching table. It makes this table readable and hackable again, and the only disadvantage is that the right margin is way beyond the rather dogmatic 80. All 0x0000 pci ids have been string replaced by 0 to more easily spot missing ids, and extra comments have been added to explain how the various entries are used.
Signed-Off-By: Luc Verhaegen libv@skynet.be
The extra comments are good, but "coreboot bios" in such a text really hurts. Please change the word BIOS to all-caps and don't refer to coreboot as a BIOS. Thanks. The documentation part can be committed after one more iteration.
The rest of the patch makes board entries unreadable. In the past few weeks, we had quite a few people in #coreboot who wanted to add support for their boards. The presence of struct member names helped immensely to explain how to add board enables. Some even figured it out from similar entries. Lowering the barrier for possible future developers is very important.
Since IIRC you said some time ago that the multiline layout hinders your workflow, feel free to submit any new board enables in the single-line layout. I'll fix them up.
Regards, Carl-Daniel
Index: board_enable.c
--- board_enable.c (revision 4132) +++ board_enable.c (working copy) @@ -618,9 +618,18 @@
- the basis of subsystem/card IDs. As not every vendor handles
- subsystem/card IDs in a sane manner.
- Keep the second set NULLed if it should be ignored.
- Keep the second set NULLed if it should be ignored. Keep the subsystem IDs
- NULLed if they don't identify the board fully. But please take care to
- provide an as complete set of pci id as possible; autodetection is preferred
- behaviour and we would like to make sure that matches are unique.
- Keep the subsystem IDs NULLed if they don't identify the board fully.
- The coreboot ids are used two fold. When a coreboot bios is installed, it
- uniquely matches the coreboot board identification string. When a legacy
- bios is installed and when autodetection is not possible, these ids can be
- used to identify the board through a command line argument.
- When a board is identified through its coreboot ids (in both cases), the
*/
- main pci ids will still be matched as a safe-guard.
struct board_pciid_enable { /* Any device, but make it sensible, like the ISA bridge. */ @@ -629,7 +638,7 @@ uint16_t first_card_vendor; uint16_t first_card_device;
- /* Any device, but make it sensible, like
- /* Any device, but make it sensible, like
*/ uint16_t second_vendor;
- the host bridge. May be NULL.
@@ -646,425 +655,38 @@ };
struct board_pciid_enable board_pciid_enables[] = {
- {
.first_vendor = 0x1106,.first_device = 0x0571,.first_card_vendor = 0x1462,.first_card_device = 0x7120,.second_vendor = 0x0000,.second_device = 0x0000,.second_card_vendor = 0x0000,.second_card_device = 0x0000,.lb_vendor = "msi",.lb_part = "kt4v",.name = "MSI KT4V",.enable = board_msi_kt4v,- },
On Mon, Apr 20, 2009 at 01:17:43PM +0200, Carl-Daniel Hailfinger wrote:
On 20.04.2009 12:12, Luc Verhaegen wrote:
Flashrom: board_enables: reconstruct table.
This patch restores the pciid based board matching table. It makes this table readable and hackable again, and the only disadvantage is that the right margin is way beyond the rather dogmatic 80. All 0x0000 pci ids have been string replaced by 0 to more easily spot missing ids, and extra comments have been added to explain how the various entries are used.
Signed-Off-By: Luc Verhaegen libv@skynet.be
The extra comments are good, but "coreboot bios" in such a text really hurts. Please change the word BIOS to all-caps and don't refer to coreboot as a BIOS. Thanks.
These are the lines in question:
* The coreboot ids are used two fold. When a coreboot bios is installed, it * uniquely matches the coreboot board identification string. When a legacy * bios is installed and when autodetection is not possible, these ids can be * used to identify the board through a command line argument.
It is clear and concise.
Let's take the other option: "when coreboot is installed" What does that mean? Did the user check out the tree, did he install some of the utils, or did he install a coreboot bios image into his rom?
Your statement is more about politics than anything else.
The documentation part can be committed after one more iteration.
I would never have altered these comments if it wasn't for the previous flamewar. For those just tuning in, this is the thread in the mailarchives: http://www.coreboot.org/pipermail/coreboot/2009-January/044086.html
The rest of the patch makes board entries unreadable.
We had this one before. It makes it unreadable for you. But not for everyone. Today, with widescreen panels, it is easier to widen your editor and see the whole line under the condensed table (and currently, see the whole table!), than it is to see more than 2 entries under the unraveled one. All you have to do is get over the 80chars per line dogma. This is one of the few situations where imho it should be allowed, it is actually the only one that i can name where i would defend it.
In the past few weeks, we had quite a few people in #coreboot who wanted to add support for their boards. The presence of struct member names helped immensely to explain how to add board enables. Some even figured it out from similar entries. Lowering the barrier for possible future developers is very important.
What makes you so certain that it is this change that made people add 4 entries in 3 months? Couldn't that be because flashrom just is getting used more? And besides, this growth is not significantly faster than before.
Since IIRC you said some time ago that the multiline layout hinders your workflow, feel free to submit any new board enables in the single-line layout. I'll fix them up.
Why is my workflow relevant? Do you really think that i have all my editors open at 160 chars all the time? My you are referring to my statements about being able to oversee everything more quickly with a condensed table. This is just common sense, everybody will have to acknowledge that one.
What about your workflow? How often have you added entries to this table?
Actually, since i have dealt with such tables in my graphics drivers before (and have done so for 5 years no, hence me creating this table in the first place); How often have you dealt with pci id based matching tables?
What will you do when it reaches a hundred or so entries? Will you be happy with a 1400line mess? Do you think that this table will stop growing at some point?
How many actual board enable functions will there be with multiple entries in the table? How much space will the actual enables take compared to the table?
How will people tell whether something similar has already been added?
Will you impose some entry ordering scheme (which, in light of likely future table growth, is actually a useful change)?
It rapidly becomes non-obvious when you don't have a tight table. And i know what you are going to say here: just make sure that they are added in whatever order already. And my answer to that is: you can't. Left or right, entries will be added that aren't ordered, and afterwards no-one will spot them being unordered anymore. In a tight table, you spot them right away and can fix it easily on the next iteration.
It really is creating a situation where you are unable to see the forest through the trees.
Also, you originally suggested to remove lines like = 0x0000; or = NULL; This is a very dangerous path. People will only see the last 2-3 entries, and never look beyond. Remove a line, and it will not be thought of for the next entry. This is simply human behaviour.
What you then end up with is a whole range of boards where just a single pair of main ids, the coreboot ids, the string and the enable will be created. No autodetection will be provided any more, as the trivial addition of yet another argument-specified-only board is of course obvious for the person who added the board enable to begin with.
The end result then is that all users will just randomly go through the board names for ages, all the time, some of which will work, as the amount of pci devices really isn't that great. This is quite a dangerous situation and a really bad user experience.
With a condensed table, people are forced to pad, and will put more thought into their entries and will feel obliged to add subsystem ids. This in turn leads to more autodetection and less people blindly forcing boardnames, and in general a better user experience.
So maybe making it "easier" for people to "understand" what the different entries are for (which actually boils down to being able to ignore how the entries are used), is not a goal that should be pursued above other goals. For existing developers, at least those willing to not religiously stick to dogmas when it makes sense, the condensed table is the better option.
Luc Verhaegen.
On 20.04.2009 14:28, Luc Verhaegen wrote:
On Mon, Apr 20, 2009 at 01:17:43PM +0200, Carl-Daniel Hailfinger wrote:
On 20.04.2009 12:12, Luc Verhaegen wrote:
Flashrom: board_enables: reconstruct table.
This patch restores the pciid based board matching table. It makes this table readable and hackable again, and the only disadvantage is that the right margin is way beyond the rather dogmatic 80. All 0x0000 pci ids have been string replaced by 0 to more easily spot missing ids, and extra comments have been added to explain how the various entries are used.
Signed-Off-By: Luc Verhaegen libv@skynet.be
The extra comments are good, but "coreboot bios" in such a text really hurts. Please change the word BIOS to all-caps and don't refer to coreboot as a BIOS. Thanks.
These are the lines in question:
- The coreboot ids are used two fold. When a coreboot bios is installed, it
- uniquely matches the coreboot board identification string. When a legacy
- bios is installed and when autodetection is not possible, these ids can be
- used to identify the board through a command line argument.
It is clear and concise.
Let's take the other option: "when coreboot is installed" What does that mean? Did the user check out the tree, did he install some of the utils, or did he install a coreboot bios image into his rom?
Coreboot is NOT a BIOS. If you really insist calling coreboot a BIOS, why not call it LinuxBIOS?
Your statement is more about politics than anything else.
There was almost universal agreement about the name change from LinuxBIOS to coreboot (well, I was unhappy initially, but I soon found out that the absence of BIOS in the new name is really beneficial). One of the reasons for the name change was that coreboot is NOT a BIOS nor should it ever be called one.
Feel free to propose calling coreboot a BIOS in a separate RFC on this list.
The documentation part can be committed after one more iteration.
I would never have altered these comments if it wasn't for the previous flamewar. For those just tuning in, this is the thread in the mailarchives: http://www.coreboot.org/pipermail/coreboot/2009-January/044086.html
Ah yes, I forgot. In http://www.coreboot.org/pipermail/coreboot/2009-January/044129.html you promised to "create all board enable functions and table entries for the foreseeable future for everyone who asks once we switch back to the old layout [...] next to keeping X from degrading even further." Was that irony or a real promise?
The rest of the patch makes board entries unreadable.
We had this one before. It makes it unreadable for you. But not for everyone.
Well, more flashrom developers on this list favour the multiline solution than those opposed to it. That means I'm part of the majority. And I do help people on IRC add board enables.
In the past few weeks, we had quite a few people in #coreboot who wanted to add support for their boards. The presence of struct member names helped immensely to explain how to add board enables. Some even figured it out from similar entries. Lowering the barrier for possible future developers is very important.
What makes you so certain that it is this change that made people add 4 entries in 3 months? Couldn't that be because flashrom just is getting used more? And besides, this growth is not significantly faster than before.
That's a straw man. I didn't claim any of the points you try to question above.
Since IIRC you said some time ago that the multiline layout hinders your workflow, feel free to submit any new board enables in the single-line layout. I'll fix them up.
Why is my workflow relevant?
If your workflow is irrelevant, why would we want to accommodate it?
Do you really think that i have all my editors open at 160 chars all the time? My you are referring to my statements about being able to oversee everything more quickly with a condensed table. This is just common sense, everybody will have to acknowledge that one.
Unless you get to define everbody's common sense (which is inherently subjective), it is unlikely that everybody (in the strict sense) will have to acknowledge your view. After all, I'm a person (and thus part of the "everybody" group of people) and I disagree with you. You could claim that I don't have common sense, but I hope you won't do that.
[...] What will you do when it reaches a hundred or so entries? Will you be happy with a 1400line mess?
Is any table with 1400 lines a mess?
Do you think that this table will stop growing at some point?
Why should it? Hardware will probably have quirks for the foreseeable future.
How many actual board enable functions will there be with multiple entries in the table? How much space will the actual enables take compared to the table?
I expect at least half a dozen entries with flash translation chips because these boards exist out there.
How will people tell whether something similar has already been added?
Like they do now.
Will you impose some entry ordering scheme (which, in light of likely future table growth, is actually a useful change)?
Your patch doesn't touch that issue, so the point is orthogonal to our discussion.
It rapidly becomes non-obvious when you don't have a tight table. And i know what you are going to say here: just make sure that they are added in whatever order already. And my answer to that is: you can't. Left or right, entries will be added that aren't ordered, and afterwards no-one will spot them being unordered anymore. In a tight table, you spot them right away and can fix it easily on the next iteration.
See above. There are lots of possible ordering schemes, but deciding which makes sense is a different matter.
It really is creating a situation where you are unable to see the forest through the trees.
Grep works nicely.
Also, you originally suggested to remove lines like = 0x0000; or = NULL; This is a very dangerous path. People will only see the last 2-3 entries, and never look beyond. Remove a line, and it will not be thought of for the next entry. This is simply human behaviour.
So you suggest to keep these lines. Fine.
What you then end up with is a whole range of boards where just a single pair of main ids, the coreboot ids, the string and the enable will be created. No autodetection will be provided any more, as the trivial addition of yet another argument-specified-only board is of course obvious for the person who added the board enable to begin with.
The end result then is that all users will just randomly go through the board names for ages, all the time, some of which will work, as the amount of pci devices really isn't that great. This is quite a dangerous situation and a really bad user experience.
Adding unique subsystem IDs to that struct is hard. First, I know for a fact that my laptop and a related model have identical subsystem IDs. That alone is proof that subsystem IDs are not always unique. Unless you know all subsystem IDs of all boards from a given manufacturer, you can't say for sure whether the board enable you're adding subsystem IDs for is actually _not_ going to trigger on another board. To make this even more fun, which subsystem ID will you use
With a condensed table, people are forced to pad, and will put more thought into their entries and will feel obliged to add subsystem ids.
You must be joking. If you can _prove_ that, you'll probably get a PhD in psychology right away. If pressing tab once really forces people to think for minutes about something that is neither easy nor obvious, I want a tab key in every conversation.
This in turn leads to more autodetection and less people blindly forcing boardnames, and in general a better user experience.
So maybe making it "easier" for people to "understand" what the different entries are for (which actually boils down to being able to ignore how the entries are used), is not a goal that should be pursued above other goals. For existing developers, at least those willing to not religiously stick to dogmas when it makes sense, the condensed table is the better option.
Let me modify one word of your statement to express my opinion:
For existing developers, at least those willing to not religiously stick to dogmas when it makes sense, the multiline table is the better option.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
We had this one before. It makes it unreadable for you. But not for everyone.
Well, more flashrom developers on this list favour the multiline solution than those opposed to it. That means I'm part of the majority.
I'm not sure you are. I think you and I have been most active in that file lately. Luc created it so if he still has interest I think his opinion matters too.
What will you do when it reaches a hundred or so entries? Will you be happy with a 1400line mess?
Is any table with 1400 lines a mess?
Not if it is 1400 lines of structured signal.
The long table format has a S/N ratio of 7% compared to the wide one, which is really REALLY low.
How will people tell whether something similar has already been added?
Like they do now.
I think the point is that with so much redundant information it is tiring to work with. Not so bad for just adding new entries, but very difficult to get an overview of, even when stretching out a terminal over a full screen.
Adding unique subsystem IDs to that struct is hard.
I agree. Interpreting the PCI and subsystem ids list for a system (ie. finding which ids to use, or when there are no good ids) is more difficult than actually adding the entry to the source code.
//Peter
Luc Verhaegen wrote:
This patch restores the pciid based board matching table. It makes this table readable and hackable again, and the only disadvantage is that the right margin is way beyond the rather dogmatic 80. All 0x0000 pci ids have been string replaced by 0 to more easily spot missing ids, and extra comments have been added to explain how the various entries are used.
Signed-Off-By: Luc Verhaegen libv@skynet.be
Thanks! r4142.
Carl-Daniel Hailfinger wrote:
The documentation part can be committed after one more iteration.
I took the liberty of improving the wording a little.
The rest of the patch makes board entries unreadable.
I disagree very much, and I welcome this patch because I naked the original change.
In the past few weeks, we had quite a few people in #coreboot who wanted to add support for their boards. The presence of struct member names helped immensely to explain how to add board enables.
Yes, and I added most of them after quickly looking over lspci -vnn output to find the most suitable PCI ids.
Lowering the barrier for possible future developers is very important.
A table is a table. Those who understand the concept still understand it whether the table is really long or really wide.
However, a high degree of noise, such as many redundant member names, really makes it more difficult to process the signal, such as different hex PCI ids.
feel free to submit any new board enables in the single-line layout. I'll fix them up.
While a very noble offer, it's not so practical for each change to have to pass you.
Thanks Luc.
//Peter
On 20.04.2009 14:45, Peter Stuge wrote:
Luc Verhaegen wrote:
This patch restores the pciid based board matching table. It makes this table readable and hackable again, and the only disadvantage is that the right margin is way beyond the rather dogmatic 80. All 0x0000 pci ids have been string replaced by 0 to more easily spot missing ids, and extra comments have been added to explain how the various entries are used.
Signed-Off-By: Luc Verhaegen libv@skynet.be
Thanks! r4142.
Carl-Daniel Hailfinger wrote:
The documentation part can be committed after one more iteration.
I took the liberty of improving the wording a little.
Thanks.
The rest of the patch makes board entries unreadable.
I disagree very much, and I welcome this patch because I naked the original change.
Should I now revert the table part of the patch because I nak it and the original conversion to multiline had more acks than the conversion back to single-line? Sorry, but this is just silly.
The table part of the patch was certainly not 1.0 material. Is there any reason to hold off committing my own non-1.0 patches?
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
Should I now revert the table part of the patch because I nak it and the original conversion to multiline had more acks than the conversion back to single-line? Sorry, but this is just silly.
I hope you agree with Luc's and my points about how the wider format is preferable.
Is there any reason to hold off committing my own non-1.0 patches?
I don't know. Which do you mean? Is it those things in that other thread, where some are in trac but you also had some good new tickets?
There is too much to keep trac(k) of and the list isn't a great tracker for me. Sorry. :\
//Peter
On 20.04.2009 15:25, Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
Should I now revert the table part of the patch because I nak it and the original conversion to multiline had more acks than the conversion back to single-line? Sorry, but this is just silly.
I hope you agree with Luc's and my points about how the wider format is preferable.
Not really. AFAICS the wide vs. multiline issue is what the disagreement is about. After all , I acked the original conversion to multiline because I didn't like the 2-line format.
Is there any reason to hold off committing my own non-1.0 patches?
I don't know. Which do you mean? Is it those things in that other thread, where some are in trac but you also had some good new tickets?
The majority of these patches have no trac entry.
There is too much to keep trac(k) of and the list isn't a great tracker for me. Sorry. :\
I prefer tracking issues on a list because it works even when I'm offline. That's probably why the patches each of us has in mind differs a lot. Sorry. I didn't mean to have you look for stuff which isn't where you look.
(Did trac get the mail-patches-to-list feature in the meantime?)
Regards, Carl-Daniel
Am Montag, den 20.04.2009, 15:36 +0200 schrieb Carl-Daniel Hailfinger:
(Did trac get the mail-patches-to-list feature in the meantime?)
Even more spam on the list? No thanks.
We already have a bad S/N ratio here (for example, it's usually 4 mails per commit: patch, acked-by mail, commit mail, "committed in r1234" acknowledgement by the committer.)
Regards, Patrick
On 20.04.2009 17:27, Patrick Georgi wrote:
Am Montag, den 20.04.2009, 15:36 +0200 schrieb Carl-Daniel Hailfinger:
(Did trac get the mail-patches-to-list feature in the meantime?)
Even more spam on the list? No thanks.
We already have a bad S/N ratio here (for example, it's usually 4 mails per commit: patch, acked-by mail, commit mail, "committed in r1234" acknowledgement by the committer.)
Mail is a push-based interface. Trac is a poll-based interface. As long as patches attached in trac don't get forwarded to the list, it makes IMHO not much sense to attach patches in trac because they'd have to be sent to the list as well which sort of defeats the purpose of trac.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
(Did trac get the mail-patches-to-list feature in the meantime?)
Even more spam on the list? No thanks.
We already have a bad S/N ratio here (for example, it's usually 4 mails per commit: patch, acked-by mail, commit mail, "committed in r1234" acknowledgement by the committer.)
Mail is a push-based interface. Trac is a poll-based interface. As long as patches attached in trac don't get forwarded to the list, it makes IMHO not much sense to attach patches in trac because they'd have to be sent to the list as well which sort of defeats the purpose of trac.
Both of you make good points!
Commit mails could be moved to a separate list. This might be a really good idea.
The ack could be only in trac (but should be possible to send via email to trac) and maybe not generate any email at all.
I agree trac should be able to attach patches. But! I'm not so sure trac should always send emails to the list.
Maybe tickets should not generate any emails at all to the list, but rather people add addresses and or other users to particular tickets.
To still keep the list updated, the ticket summary interval could be shortened a little, instead of having every ticket change generate an email.
I think an application is better for tracking state. The mailing list is more of a continuous medium, at least for me.
//Peter
On Mon, Apr 20, 2009 at 03:16:13PM +0200, Carl-Daniel Hailfinger wrote:
On 20.04.2009 14:45, Peter Stuge wrote:
Luc Verhaegen wrote:
This patch restores the pciid based board matching table. It makes this table readable and hackable again, and the only disadvantage is that the right margin is way beyond the rather dogmatic 80. All 0x0000 pci ids have been string replaced by 0 to more easily spot missing ids, and extra comments have been added to explain how the various entries are used.
Signed-Off-By: Luc Verhaegen libv@skynet.be
Thanks! r4142.
Carl-Daniel Hailfinger wrote:
The documentation part can be committed after one more iteration.
I took the liberty of improving the wording a little.
Thanks.
The rest of the patch makes board entries unreadable.
I disagree very much, and I welcome this patch because I naked the original change.
Should I now revert the table part of the patch because I nak it and the original conversion to multiline had more acks than the conversion back to single-line? Sorry, but this is just silly.
Last time round, you committed despite of a lot of complaints. For all intents and purpose those complaints were nacks.
Yet you overruled them rather badly with this statement: http://www.coreboot.org/pipermail/coreboot/2009-January/044125.html
Now, from a million miles away, this situation is just as bad as last time, it is just that roles are reversed for you this time. I'm sure you've heard this saying before, don't do onto others what you do not want to have done to you.
What should have been the case here all along is that this should've been based on solid arguments instead of on egos.
Some arguments came from Ron, as to why he acked this, but they were clearly outnumbered by arguments for not taking in the patch. Also, Ron his arguments were rather general and not specific for this rather special case of a really nasty table that will become huge over time.
What you also have to take into account is that this time the signed off and the ack come from two people who have been heavily involved with the board enables, and who have worked with this table extensively. Last time those people came with Nacks, yet you still overruled them hardhandedly.
Please, read the arguments and try to understand them. There are valid reasons for this table to be like this, and they outweigh and outnumber the few that the other layout had in favour. And don't let this degrade as much as last time.
Luc Verhaegen.
On 20.04.2009 15:43, Luc Verhaegen wrote:
On Mon, Apr 20, 2009 at 03:16:13PM +0200, Carl-Daniel Hailfinger wrote:
Should I now revert the table part of the patch because I nak it and the original conversion to multiline had more acks than the conversion back to single-line? Sorry, but this is just silly.
Last time round, you committed despite of a lot of complaints. For all intents and purpose those complaints were nacks.
Lots of complaints from you and Peter.
Yet you overruled them rather badly with this statement: http://www.coreboot.org/pipermail/coreboot/2009-January/044125.html
My bad. I should have listed the 3 other flashrom developers who agree with me. So you're outnumbered.
Now, from a million miles away, this situation is just as bad as last time, it is just that roles are reversed for you this time. I'm sure you've heard this saying before, don't do onto others what you do not want to have done to you.
What should have been the case here all along is that this should've been based on solid arguments instead of on egos.
Each of us claims to have solid arguments. I think that's abvious by now.
Some arguments came from Ron, as to why he acked this, but they were clearly outnumbered by arguments for not taking in the patch.
If the number of arguments in favour of anything counts, I'll split each of my arguments into dozens of micro-arguments and I win. You can't be serious.
Also, Ron his arguments were rather general and not specific for this rather special case of a really nasty table that will become huge over time.
So you're saying his argument does not apply although it was made in response to the discussion about this exact table? I'd like to understand that reasoning.
What you also have to take into account is that this time the signed off and the ack come from two people who have been heavily involved with the board enables, and who have worked with this table extensively. Last time those people came with Nacks, yet you still overruled them hardhandedly.
I understood the previous discussion to be a vote and you lost. It seems our voting eligibility criteria differ.
Please, read the arguments and try to understand them. There are valid reasons for this table to be like this, and they outweigh and outnumber the few that the other layout had in favour. And don't let this degrade as much as last time.
To recap: 1. If number of flashrom developers counts, I win. (I can dig up the relevant mailing list posts if you insist.) 2. If the number of arguments counts, I can split my arguments into dozens of micro-arguments. You can probably do the same. After some time, one of us will grow tired of this. 3. If the number of developers touching the table counts, you claim you win (I haven't verified that).
It all burns down on deciding which arguments are valid and who is eligible to vote/decide if there are valid opposing arguments.
Regards, Carl-Daniel
On Mon, Apr 20, 2009 at 04:18:52PM +0200, Carl-Daniel Hailfinger wrote:
To recap:
- If number of flashrom developers counts, I win. (I can dig up the
relevant mailing list posts if you insist.) 2. If the number of arguments counts, I can split my arguments into dozens of micro-arguments. You can probably do the same. After some time, one of us will grow tired of this. 3. If the number of developers touching the table counts, you claim you win (I haven't verified that).
What if the number of board enable functions and the number of board enable entries by voter counts...
Luc Verhaegen.
On Mon, Apr 20, 2009 at 10:18 AM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 20.04.2009 15:43, Luc Verhaegen wrote:
On Mon, Apr 20, 2009 at 03:16:13PM +0200, Carl-Daniel Hailfinger wrote:
Should I now revert the table part of the patch because I nak it and the original conversion to multiline had more acks than the conversion back to single-line? Sorry, but this is just silly.
Last time round, you committed despite of a lot of complaints. For all intents and purpose those complaints were nacks.
Lots of complaints from you and Peter.
Yet you overruled them rather badly with this statement: http://www.coreboot.org/pipermail/coreboot/2009-January/044125.html
My bad. I should have listed the 3 other flashrom developers who agree with me. So you're outnumbered.
Now, from a million miles away, this situation is just as bad as last time, it is just that roles are reversed for you this time. I'm sure you've heard this saying before, don't do onto others what you do not want to have done to you.
What should have been the case here all along is that this should've been based on solid arguments instead of on egos.
Each of us claims to have solid arguments. I think that's abvious by now.
Some arguments came from Ron, as to why he acked this, but they were clearly outnumbered by arguments for not taking in the patch.
If the number of arguments in favour of anything counts, I'll split each of my arguments into dozens of micro-arguments and I win. You can't be serious.
Also, Ron his arguments were rather general and not specific for this rather special case of a really nasty table that will become huge over time.
So you're saying his argument does not apply although it was made in response to the discussion about this exact table? I'd like to understand that reasoning.
What you also have to take into account is that this time the signed off and the ack come from two people who have been heavily involved with the board enables, and who have worked with this table extensively. Last time those people came with Nacks, yet you still overruled them hardhandedly.
I understood the previous discussion to be a vote and you lost. It seems our voting eligibility criteria differ.
Please, read the arguments and try to understand them. There are valid reasons for this table to be like this, and they outweigh and outnumber the few that the other layout had in favour. And don't let this degrade as much as last time.
To recap:
- If number of flashrom developers counts, I win. (I can dig up the
relevant mailing list posts if you insist.) 2. If the number of arguments counts, I can split my arguments into dozens of micro-arguments. You can probably do the same. After some time, one of us will grow tired of this. 3. If the number of developers touching the table counts, you claim you win (I haven't verified that).
It all burns down on deciding which arguments are valid and who is eligible to vote/decide if there are valid opposing arguments.
If the formatting of the file is so damn important, why not duplicate the file, having one version with the multiline format and a second with the dual-line one? Then a post-commit script keeps the two in sync with each other. Normally, I'm against duplicated code, but this argument got old months ago, I'll ack any patch that ends it.
-Corey
-
Carl-Daniel Hailfinger -
Corey Osgood -
Luc Verhaegen -
Patrick Georgi -
Peter Stuge