has this been discussed here?
http://drupal.org/node/87145 I seem to have missed any discussion of this issue. I feel very strongly that a bad decision is being made based on bad reasoning. In my opinion the break tag is not broken and changing it is not helpful or wise. also, I think that the hostility shown in this follow-up thread http://drupal.org/node/105278 exposes some things about the direction the drupal community is heading that I find worrisome (and that I will write more about later, when I have the time) What is the value to the community of stepping on people that try to participate?; what is lost when people are pushed away by hostility and threats to delete comments and negate their valid and rationally expressed concerns? --Eric -- ------------------------------------------- Openflows Community Technology Lab, Inc. New York | Toronto | Montreal | Vienna http://openflows.com People are intelligent. Machines are tools.
Quoting Eric Goldhagen <eric@openflows.org>:
I seem to have missed any discussion of this issue.
I feel very strongly that a bad decision is being made based on bad reasoning. In my opinion the break tag is not broken and changing it is not helpful or wise.
also, I think that the hostility shown in this follow-up thread http://drupal.org/node/105278 exposes some things about the direction the drupal community is heading that I find worrisome (and that I will write more about later, when I have the time)
What is the value to the community of stepping on people that try to participate?; what is lost when people are pushed away by hostility and threats to delete comments and negate their valid and rationally expressed concerns?
Thanks for bringing this to attention Eric; I am not up on all of the previous discussion on this issue. In my opinion, be it considered humble or not so humble, support for <!--break--> should never be removed. 1) I've gotten used to it and it is natural. 2) I would have to update my previous entered data. Promoting [break] as a new means to using <!--break--> would be OK but not necessary and <break> should never be allowed as it breaks in too many semantic areas. -1 for this change. Earnie
On 26 Dec 2006, at 15:49, Eric Goldhagen wrote:
I seem to have missed any discussion of this issue.
I feel very strongly that a bad decision is being made based on bad reasoning. In my opinion the break tag is not broken and changing it is not helpful or wise.
I strongly suggest you add your arguments to the issue. Scattering the discussion makes it hard to keep an overview. For most people, such an overview doesn't really matter, but for issue reviewers like me, it does. Keeping on top of the issue tracker is one thing, keeping on top of both the fora, the mailing lists, and the issue tracker is virtually impossible, and introduce lots of redundancy. Important comments should go in the issue or they might not get my attention/consideration. Not because I'm unwilling, but because of the sheer volume. Thanks. :) That said, I _still_ have to read up on the issue follow-ups but last time I checked (1 week ago), this particular issue seemed to be a tough one. From what I remember, quite a few people didn't care to research the problem before sharing their opinion. Their gut feeling tells them that <!--break--> is semantically better, without knowing what is going on under the hood. As a result, the issue carries quite a number of incorrect assessments and fair amount of personal taste. Of course, "gut feeling" matters too ... it is closely related to "the first impression". Gut feeling is not something we can discard, but I highly recommend people to invest some time into this before sharing their opinions. It helps us focus. Either way, I'll read up on the issue in a couple of days. I'll probably have to sit down and spent an hour with that particular issue. Hopefully, things have settled by than. If not, I'll make a decision based on the information available in the issue, the collective gut feeling, and the technical arguments that appear sound. -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
From what I remember, quite a few people didn't care to research the problem before sharing their opinion. Their gut feeling tells them that <!--break--> is semantically better, without knowing what is going on under the hood. As a result, the issue carries quite a number of incorrect assessments and fair amount of personal taste.
I read the issue, and ironically 'gut feeling' and personal taste was the only reason offered for *changing* <!--break--> to something else. I don't care enough about the issue to fight on way or another, but the thread was frustrating to read; a late-in-the-game core patch went up, received NO positive reviews, and several negative ones. It was immediately committed. --Jeff
I read the issue, and ironically 'gut feeling' and personal taste was the only reason offered for *changing* <!--break--> to something else. I don't care enough about the issue to fight on way or another, but the thread was frustrating to read; a late-in-the-game core patch went up, received NO positive reviews, and several negative ones. It was immediately committed.
Well, the new tag looks better and is easier to type. Aside from that, as I mentioned in my earlier letter, the followups on filter-released issues are usually so off the track that it's no surprise Steven simply skips them. For example, never forget that I fought so hard for input filtering which is technically absurd that I have actually *coded* it -- all that work bought me was a through explanation so now I know why it's wrong (think of truncating an HTML-escaped, entitized text -- that's a horrible mess), and to know where Drupal text filtering goes to be secure (we provide APIs of which t() is a very nice example). So I am guilty here in strengthening the 'developers do not understand filter' attitude. There are a lot of factors that went into this issue: the very long code freeze, the 'bikeshed' factor made worse by the fact that people believe they understand it but they don't, the history of similarly misunderstood filter issues (which were only misunderstood by developers but that's bad enough).
Quoting Karoly Negyesi <karoly@negyesi.net>: Since you've decided to respond even though we were asked by Dries to use the issue for comment ...
I read the issue, and ironically 'gut feeling' and personal taste was the only reason offered for *changing* <!--break--> to something else. I don't care enough about the issue to fight on way or another, but the thread was frustrating to read; a late-in-the-game core patch went up, received NO positive reviews, and several negative ones. It was immediately committed.
Well, the new tag looks better and is easier to type.
BS. How many times is someone going to think <br> instead of <break>? If you want fewer characters why not just </> for a break marker. As I stated in the issue, I am already in HTML thinking mode and <!--break--> is natural when thinking in HTML, while <break> isn't. Your statement is like a child going after a toy his parents won't let him have, it is meaningless w.r.t. causing hardship on those who have to learn a new way, convert their data and become extremely upset with such a childish change for childish reasons.
Aside from that, as I mentioned in my earlier letter, the followups on filter-released issues are usually so off the track that it's no surprise Steven simply skips them. For example, never forget that I fought so hard for input filtering which is technically absurd that I have actually *coded* it -- all that work bought me was a through explanation so now I know why it's wrong (think of truncating an HTML-escaped, entitized text -- that's a horrible mess), and to know where Drupal text filtering goes to be secure (we provide APIs of which t() is a very nice example). So I am guilty here in strengthening the 'developers do not understand filter' attitude.
I am new to Drupal so Steven forgive my ignorance. I am beginning to understand that you put a lot of work into Drupal and for that I am greatful but I am not going to become disinclined to comment just because of that. I am not new to user interface and working with and programming applications with 25+ years in the business so I have earned my rights to be heard.
There are a lot of factors that went into this issue: the very long code freeze, the 'bikeshed' factor made worse by the fact that people believe they understand it but they don't, the history of similarly misunderstood filter issues (which were only misunderstood by developers but that's bad enough).
And there are a lot of factors yet to be heard and developer to user communication may not have been heard yet. It sounds to me as if Steven thought it, Steven explained it to a few developers those developers agreed and now everyone else (in particular the user community) is upset. IMO it is time to change the color of the bikeshed back to its original color as 90% of development should be listening to what the user wants. This hasn't even hit most of the user community yet, what is going to happen on the support list when an official release happens? Earnie
also, I think that the hostility shown in this follow-up thread http://drupal.org/node/105278 exposes some things about the direction the drupal community is heading that I find worrisome (and that I will write more about later, when I have the time)
(In a very tired voice) Please do not write more. It does not reflect the community it only reflects me pissed off people chiming in without having the shortest idea how development happens. And I doubt I need to apologize for erecting a warning sign that flamewars are not tolerated. But hey, congratulations, you managed to pollute even the devel list with this. First we had an issue then the IRC channel then the forums now the development list -- and there is nothing new said... And yes, even I needed to ask Steven a few things before siding with this change but hey! now these questions are nicely answered in his long comment. But you know what? Are you concerned about people? Here is something to chew on: think of how Steven feels, attacked everywhere for this minute change. Where are the praising posts in the issue queue, in the forums and on devel praising him for the heroic effort that went into the t() patch? (Do not look at me, I congratulated in person) Oh, you do not even _understand_ the importance and the immense effort that went into it? I do not know the number of hours that actually went into t() but I have some memories porting KSES to become filter_xss and man, I do not even want to go near massive HTML processing if I can help it for the rest of my life. But Steven soldiers on and enhances this extremely hard piece of code for us. Be thankful for that. NK
Op woensdag 27 december 2006 02:52, schreef Karoly Negyesi:
Where are the praising posts in the issue queue, in the forums and on devel praising him for the heroic effort that went into the t() patch?
Sorry Karoly, Sorry Steven, but it is a known fact that you'll only hear angry voices when something goes amiss, and hardly ever anything when something goes right. Do you praise the taxidriver everytime he stops for you on a zebra crossing? Do you thank the checkout girl in the supermarket when she got the total price of your purchase right? I do't think it is a good idea to even suggest something like 'earning a right to criticise'. Its a free community, we all have that right, regardless of amount of committed patches or amout of times we praised someone. It is up to you/everyone to ignore critique if you think it is badly voiced, or lacks proper insight, but don't be suprised if too much ignoring fires back on you (or even Drupal as a whole) in the end. Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
participants (6)
-
Bèr Kessels -
Dries Buytaert -
Earnie Boyd -
Eric Goldhagen -
Jeff Eaton -
Karoly Negyesi