Re: Could we start accepting rich-text postings on the gcc lists?
Hi, On Fri, Nov 23, 2012 at 12:12:17PM -0800, Andrew Pinski wrote: > On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote: > > In this day and age of rich-text capable mailers, restricting postings > > to be text-only seems quaint and antiquated. Are there any hard > > requirements that force us to only accept plain text messages? > > I think it is a bad idea to accept non plain text messages (except for > attachments). > Just for the record, I'm also against rich text reaching gcc mailing lists. I use mutt for work email and consider such messages irritating in one or (usually) more ways whenever I get them. Martin
Re: Could we start accepting rich-text postings on the gcc lists?
On Sun, Nov 25, 2012 at 7:28 AM, Ruben Safir wrote: > On Sun, Nov 25, 2012 at 10:28:39AM -0500, Diego Novillo wrote: >> My main concern is losing valid content because of this limitation. >> > > Your only concern is to send email with your android gmail. > > You also need to learn to trim the CC line At what point does obvious trolling get someone banned on the gcc lists? This user has been nothing but purely abusive: http://gcc.gnu.org/ml/gcc/2012-11/msg00432.html http://gcc.gnu.org/ml/gcc/2012-11/msg00411.html http://gcc.gnu.org/ml/gcc/2012-11/msg00406.html http://gcc.gnu.org/ml/gcc/2012-11/msg00405.html http://gcc.gnu.org/ml/gcc/2012-11/msg00383.html etc. throughout this thread.
Re: Could we start accepting rich-text postings on the gcc lists?
On Sat, Nov 24, 2012 at 11:13 AM, Ian Lance Taylor wrote: > 2) The fact that Android refuses to provide a non-HTML e-mail capability > is ridiculous but does not seem to me to be a reason for us to change > our policy. Amen. Rich texts in technical conversations where people people use various mail agents and mail readers/senders is a fracking mess. That the designers at infinite loop and amphitheatre parkway won't let their devices and software send plain text emails is is the problem, not the solution. It is not a software progress in the 21st century; it is a regression. -- Gaby
Re: Could we start accepting rich-text postings on the gcc lists?
On Sun, Nov 25, 2012 at 10:28:39AM -0500, Diego Novillo wrote: > My main concern is losing valid content because of this limitation. > Your only concern is to send email with your android gmail. You also need to learn to trim the CC line
Re: Sumbitting 'patches' that add lots of files (Was: Re: Could we start accepting rich-text postings on the gcc lists?)
On Sun, Nov 25, 2012 at 5:03 PM, Joern Rennecke wrote: > Quoting Richard Biener : > >> (though doesn't save much space). One file per mail is then convenient >> for >> review anyway. > > > That would be 84 mails then just for the added files. > And if the testsuite was bigger, that figure would only get larger. > Is that really the preferred way to do this? Apply common sense - the above applies to large files only of course. Richard.
Re: Sumbitting 'patches' that add lots of files (Was: Re: Could we start accepting rich-text postings on the gcc lists?)
Quoting Richard Biener : (though doesn't save much space). One file per mail is then convenient for review anyway. That would be 84 mails then just for the added files. And if the testsuite was bigger, that figure would only get larger. Is that really the preferred way to do this?
Re: Sumbitting 'patches' that add lots of files (Was: Re: Could we start accepting rich-text postings on the gcc lists?)
On Sun, Nov 25, 2012 at 4:47 PM, Joern Rennecke wrote: > Quoting Richard Biener : > >> That said, filtering any non text/plain mail into spam keeps me off most >> spam. Thus be warned when you try to get patches in non text/plain >> sent to me ;) > > > Should I uuencode new port submissions? > Expressing addition of several score files as a 'patch' is not always an > option. Uncompressed, the Synopsys Designware ARC port weighs in at more > than a megabyte. I don't know - I usually don't review new port submissions. I think for new files attaching the new file itself instead of a patch producing it is common practice (though doesn't save much space). One file per mail is then convenient for review anyway. Richard.
Sumbitting 'patches' that add lots of files (Was: Re: Could we start accepting rich-text postings on the gcc lists?)
Quoting Richard Biener : That said, filtering any non text/plain mail into spam keeps me off most spam. Thus be warned when you try to get patches in non text/plain sent to me ;) Should I uuencode new port submissions? Expressing addition of several score files as a 'patch' is not always an option. Uncompressed, the Synopsys Designware ARC port weighs in at more than a megabyte.
Re: Could we start accepting rich-text postings on the gcc lists?
On Sun, Nov 25, 2012 at 8:54 AM, Richard Biener wrote: > That said, filtering any non text/plain mail into spam keeps me off most > spam. Thus be warned when you try to get patches in non text/plain > sent to me ;) It would be OK for me if the mailing list software we use stripped the text/html part of messages. That would solve the majority of the issues I see, and I understand that this is doable. My main concern is losing valid content because of this limitation. Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
On Sat, Nov 24, 2012 at 7:08 PM, Robert Dewar wrote: > On 11/24/2012 12:59 PM, Daniel Berlin wrote: >> >> On Sat, Nov 24, 2012 at 12:47 PM, Robert Dewar wrote: >>> >>> 2) The fact that Android refuses to provide a non-HTML e-mail capability is ridiculous but does not seem to me to be a reason for us to change our policy. >>> >>> >>> >>> Surely there are altenrative email client for Android that have plain >>> text capability??? >>> >> >> Yes, we should expect users to change, instead of keeping up with users. > > > Well my experience with HTML-burdened mail is awful. From people who set > ludicrous font choices, to bad color choices, to inappropriate use of > multiple fonts, to inappropriate use of colors, it's a mess. > > I think it is perfectly reasonable to expect serious developers to > send text messages in text form. BTW, our experience at AdaCore, where > we get lots of email from lots of customers, users, hobbyists, and > students, sending email from all sorts > of programs, is that yes, occasionally they send us HTML burdened > email, but almost always when we ask them to adjust their mailers to > send text, they can do so without problems. Hey - customers even send mails with only a pdf attachment that contains a scanned sheet of paper with hand-writing ... Richard.
Re: Could we start accepting rich-text postings on the gcc lists?
On Sat, Nov 24, 2012 at 6:47 PM, Robert Dewar wrote: > >> 2) The fact that Android refuses to provide a non-HTML e-mail capability >> is ridiculous but does not seem to me to be a reason for us to change >> our policy. > > > Surely there are altenrative email client for Android that have plain > text capability??? Of course, I use one. Richard.
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 11:03 PM, Diego Novillo wrote: > On Fri, Nov 23, 2012 at 5:00 PM, Richard Kenner > wrote: >>> It's just that an increasing number of mail agents are configured by >>> default to send rich-text. >> >> And people who know enough about computing to work on compilers don't know >> how to change the default on their MUA? That seems like a poor reason to >> make such a change. > > I already addressed this upthread. We are starting to talk in > circles. The point is not to add unnecessary irritation. We don't add irritation - it's already there. Btw, maybe time to bug your friends at google that an option to turn off html postings for the GMail android app would be nice ;) That said, filtering any non text/plain mail into spam keeps me off most spam. Thus be warned when you try to get patches in non text/plain sent to me ;) I strongly prefer to keep the restriction in place. Richard. > > Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
Sorry - I wasn't really interested in debating this any more than one should debate the effects of having your head squashed if you hang your head over the rail when the IRT is coming. It just gets squashed. BTW, as well as learning to use text for email, also please learn to trim the CC list Ruben
Re: Could we start accepting rich-text postings on the gcc lists?
Sorry dude, I don't engage in substantive conversation with abusive trolls. On Sat, Nov 24, 2012 at 2:43 PM, Ruben Safir wrote: > On Sat, Nov 24, 2012 at 12:58:33PM -0500, Daniel Berlin wrote: >> On Sat, Nov 24, 2012 at 12:13 PM, Ian Lance Taylor wrote: >> > Diego Novillo writes: >> > >> >> Sure. First I wanted to find out whether this requirement is just a >> >> technical limitation with our mailing list software. >> > >> > It is not a technical limitation. We explicitly reject HTML e-mail. We >> > could accept it. >> > >> > As Jonathan pointed out, accepting HTML e-mail and then displaying it in >> > the web archives will make us even more of a spam target than we already >> > are, and will mean that we will need some mechanisms for identifying and >> > removing spam and virus links in the web pages. >> >> I'd love to see data on this. > > Go generate it with you own mailing list and let us know. > >> As others have pointed out, almost >> every other open source project accepts html email. > > > Wrong > > And it is silly to burden everyone else with the bulk and storage of > that nonsense, let alone the multiple fonts and standards and CSS style > sheets and missappropriate images and links. > > Its time for users to get with it and not use every stupid thing shoved > down their through. And PLEASE tell me you write you C programming in > adroind using your thumb prints. > > Ruben > > -- > http://www.mrbrklyn.com - Interesting Stuff > http://www.nylxs.com - Leadership Development in Free Software > > So many immigrant groups have swept through our town that Brooklyn, like > Atlantis, reaches mythological proportions in the mind of the world - RI > Safir 1998 > > http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir > 2002 > > "Yeah - I write Free Software...so SUE ME" > > "The tremendous problem we face is that we are becoming sharecroppers to our > own cultural heritage -- we need the ability to participate in our own > society." > > "> I'm an engineer. I choose the best tool for the job, politics be damned.< > You must be a stupid engineer then, because politcs and technology have been > attached at the hip since the 1st dynasty in Ancient Egypt. I guess you > missed that one." > > © Copyright for the Digital Millennium
Re: Could we start accepting rich-text postings on the gcc lists?
> > Yes, we should expect users to change, instead of keeping up with users. No - we shouldn't punish developers by making them use stupid mime translational servces that breaks the replying mechanism in EMACS and mutt because they are stupidly try to post to a tech mailing list on their android as if it is facebook. Blah. Ruben -- http://www.mrbrklyn.com - Interesting Stuff http://www.nylxs.com - Leadership Development in Free Software
Re: Could we start accepting rich-text postings on the gcc lists?
On Sat, Nov 24, 2012 at 12:58:33PM -0500, Daniel Berlin wrote: > On Sat, Nov 24, 2012 at 12:13 PM, Ian Lance Taylor wrote: > > Diego Novillo writes: > > > >> Sure. First I wanted to find out whether this requirement is just a > >> technical limitation with our mailing list software. > > > > It is not a technical limitation. We explicitly reject HTML e-mail. We > > could accept it. > > > > As Jonathan pointed out, accepting HTML e-mail and then displaying it in > > the web archives will make us even more of a spam target than we already > > are, and will mean that we will need some mechanisms for identifying and > > removing spam and virus links in the web pages. > > I'd love to see data on this. Go generate it with you own mailing list and let us know. > As others have pointed out, almost > every other open source project accepts html email. Wrong And it is silly to burden everyone else with the bulk and storage of that nonsense, let alone the multiple fonts and standards and CSS style sheets and missappropriate images and links. Its time for users to get with it and not use every stupid thing shoved down their through. And PLEASE tell me you write you C programming in adroind using your thumb prints. Ruben -- http://www.mrbrklyn.com - Interesting Stuff http://www.nylxs.com - Leadership Development in Free Software So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 "Yeah - I write Free Software...so SUE ME" "The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society." "> I'm an engineer. I choose the best tool for the job, politics be damned.< You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one." © Copyright for the Digital Millennium
Re: Could we start accepting rich-text postings on the gcc lists?
On 11/24/2012 1:13 PM, Jonathan Wakely wrote: The official gmail app, which obviously integrates well with gmail and is good in most other ways, won't send non-html mails. There seem to be a variety of alternatives http://www.tested.com/tech/android/3110-the-best-alternative-android-apps-to-manage-all-your-email/ K-9 is a free software client that looks interesting I find that very annoying, but I get annoyed with the app and am not suggesting the GCC lists should change to deal with it.
Re: Could we start accepting rich-text postings on the gcc lists?
On 24 November 2012 17:47, Robert Dewar wrote: > >> 2) The fact that Android refuses to provide a non-HTML e-mail capability >> is ridiculous but does not seem to me to be a reason for us to change >> our policy. > > > Surely there are altenrative email client for Android that have plain > text capability??? The official gmail app, which obviously integrates well with gmail and is good in most other ways, won't send non-html mails. I find that very annoying, but I get annoyed with the app and am not suggesting the GCC lists should change to deal with it.
Re: Could we start accepting rich-text postings on the gcc lists?
Hi - On Sat, Nov 24, 2012 at 12:58:33PM -0500, Daniel Berlin wrote: > [...] > I'd love to see data on this. As others have pointed out, almost > every other open source project accepts html email. [...] > Do you have reason to believe our existing spam detection solution > will start to fail massively when presented with html email? [...] Yes. I run a similar spamassassin setup at home as sourceware's, and it routinely lets through spam that is disguised in HTML. That is after all trivial to do - font size=1 color=white or somesuch gunk. Annoyingly, the spam's hidden bayes-countering filler goo shows up in its full html-to-text glory in a text-based MUA. > After all, if most of the HTML email is spam, something being HTML > email is a great signal for it. Dunno about "most", but "an uncomfortable amount" is right. > [...] > Note that *we* are currently rejecting multipart/alternative if it > contains text/html, even if it contains text/plain. > This is fairly obnoxious. See above. Spam filtering on HTML bodies is not very effective, unless one's a gmail. There is no mechanical way to ensure that the multipart alternative text/plain is equivalent -- and if it were, then it could just have been sent as is in the first place (were it not for MUA intransigence). - FChE
Re: Could we start accepting rich-text postings on the gcc lists?
On 11/24/2012 12:59 PM, Daniel Berlin wrote: On Sat, Nov 24, 2012 at 12:47 PM, Robert Dewar wrote: 2) The fact that Android refuses to provide a non-HTML e-mail capability is ridiculous but does not seem to me to be a reason for us to change our policy. Surely there are altenrative email client for Android that have plain text capability??? Yes, we should expect users to change, instead of keeping up with users. Well my experience with HTML-burdened mail is awful. From people who set ludicrous font choices, to bad color choices, to inappropriate use of multiple fonts, to inappropriate use of colors, it's a mess. I think it is perfectly reasonable to expect serious developers to send text messages in text form. BTW, our experience at AdaCore, where we get lots of email from lots of customers, users, hobbyists, and students, sending email from all sorts of programs, is that yes, occasionally they send us HTML burdened email, but almost always when we ask them to adjust their mailers to send text, they can do so without problems.
Re: Could we start accepting rich-text postings on the gcc lists?
On Sat, Nov 24, 2012 at 12:47 PM, Robert Dewar wrote: > >> 2) The fact that Android refuses to provide a non-HTML e-mail capability >> is ridiculous but does not seem to me to be a reason for us to change >> our policy. > > > Surely there are altenrative email client for Android that have plain > text capability??? > Yes, we should expect users to change, instead of keeping up with users.
Re: Could we start accepting rich-text postings on the gcc lists?
On Sat, Nov 24, 2012 at 12:13 PM, Ian Lance Taylor wrote: > Diego Novillo writes: > >> Sure. First I wanted to find out whether this requirement is just a >> technical limitation with our mailing list software. > > It is not a technical limitation. We explicitly reject HTML e-mail. We > could accept it. > > As Jonathan pointed out, accepting HTML e-mail and then displaying it in > the web archives will make us even more of a spam target than we already > are, and will mean that we will need some mechanisms for identifying and > removing spam and virus links in the web pages. I'd love to see data on this. As others have pointed out, almost every other open source project accepts html email. I went through, for example, the LLVM email archives, and i don't see a massive amount of spam. Do you have reason to believe our existing spam detection solution will start to fail massively when presented with html email? After all, if most of the HTML email is spam, something being HTML email is a great signal for it. > > A possible compromise would be to accept HTML e-mail that has a text > alternative, and only display the text alternative in the archives. > That would also work for people who have text-only e-mail readers. In > general that would help for people who use e-mail programs that send > HTML with text alternatives by default. But it would fail for people > who actually use HTML formatting in a meaningful way. I have not seen html formatting used in the other open source projects, just text/html emails. > And, of course, > this would require some administrative work to be done. > > I don't really care one way or the other on this issue. That said: > > 1) People who send HTML e-mail ought to get a bounce message, so I would > think they would be able to reform. At that point they probably don't care. Honestly, any community that actively makes it hard for me to send mail from a common email program, is a huge turn-off. Folks can retort that we may not want users who don't want to take the time to send non-html email. I doubt this is actually true, since the majority of folks i've seen are just using clients that default to html email, and aren't doing anything obnoxious. Note that *we* are currently rejecting multipart/alternative if it contains text/html, even if it contains text/plain. This is fairly obnoxious. > 2) The fact that Android refuses to provide a non-HTML e-mail capability > is ridiculous but does not seem to me to be a reason for us to change > our policy. Expect it to get worse. Folks can say what they like, but other communities i'm a part of, and are much larger than GCC, deal with HTML email with zero problem. All bouncing HTML email is really doing is turning away some people. In the "olden days", when html email was some shitty gobbledygook produced by an old version of exchange, this may have made sense. In the days now of relatively sane multipart/alternative emails, it just seems like folks being annoyed that the rest of the world changed. > > Ian
Re: Could we start accepting rich-text postings on the gcc lists?
2) The fact that Android refuses to provide a non-HTML e-mail capability is ridiculous but does not seem to me to be a reason for us to change our policy. Surely there are altenrative email client for Android that have plain text capability???
Re: Could we start accepting rich-text postings on the gcc lists?
Diego Novillo writes: > Sure. First I wanted to find out whether this requirement is just a > technical limitation with our mailing list software. It is not a technical limitation. We explicitly reject HTML e-mail. We could accept it. As Jonathan pointed out, accepting HTML e-mail and then displaying it in the web archives will make us even more of a spam target than we already are, and will mean that we will need some mechanisms for identifying and removing spam and virus links in the web pages. A possible compromise would be to accept HTML e-mail that has a text alternative, and only display the text alternative in the archives. That would also work for people who have text-only e-mail readers. In general that would help for people who use e-mail programs that send HTML with text alternatives by default. But it would fail for people who actually use HTML formatting in a meaningful way. And, of course, this would require some administrative work to be done. I don't really care one way or the other on this issue. That said: 1) People who send HTML e-mail ought to get a bounce message, so I would think they would be able to reform. 2) The fact that Android refuses to provide a non-HTML e-mail capability is ridiculous but does not seem to me to be a reason for us to change our policy. Ian
Re: Could we start accepting rich-text postings on the gcc lists?
On 24 November 2012 00:40, Nathan Ridge wrote: > > I am regular reader of several mailing lists, some of which (such as this > one) require plain text, and some (like cdt-dev) which allow rich text. > > My experience has been that the formatting of messages on plain-text > lists is consistent across the board, while on rich-text lists you get a > mess by mixing together different formatting conventions. A prominent > example is the formatting convention used for quoting the message you're > replying to. Plain-text lists always use one convention: greater-than > signs (>) before each line of the quote, one for each level of quoting. > On rich-text lists, some messages use greater-than signs, some use a > vertical line to the left of the text, some use a different color, etc. > The result is a mess that's difficult to follow. It also seems to be more common with rich text mails for people to start their reply inside the markup of quoted text, so the reply then appears in the same font/color/indentation as the quoted text, which puts quite a burden on the readers to disentangle the reply from the quoted text. > I think rich-text works well when everyone uses the same mail client. > For example, at a company I used to work, for everyone used Microsoft > Outlook as their mail client, and emails were sent in rich text. There > was no readability problem there because everyone used the same > formatting conventions. But everyone top-posts ... eurgh. In my experience of a few technical lists the small benefits of being able to show code snippets in a different font from text, or make conservative use of bold/italics for emphasis are not enough to warrant using rich text.
RE: Could we start accepting rich-text postings on the gcc lists?
> > Similarly for text-only vs. "rich text". You may argue that there's no > > compatibility issue, but I disagree. As was pointed out upthread, when > > people use "rich text", they often start to use colors or other mechanisms > > to express themselves, which can now be dependent on the rendering agent > > used to read the email. Requiring people to express themselves using only > > words seems to me to encourage the sorts of discipline that we require in > > contributors. > > We disagree on this point, then. While rich-text can be abused, it is > not my experience that people do abuse it to the point of making their > postings illegible. The markings you see commonly used are monospace > font alterations, bolding and lists. I have noticed no correlation > between the ability to use a markup language and quality of > contributions. I am regular reader of several mailing lists, some of which (such as this one) require plain text, and some (like cdt-dev) which allow rich text. My experience has been that the formatting of messages on plain-text lists is consistent across the board, while on rich-text lists you get a mess by mixing together different formatting conventions. A prominent example is the formatting convention used for quoting the message you're replying to. Plain-text lists always use one convention: greater-than signs (>) before each line of the quote, one for each level of quoting. On rich-text lists, some messages use greater-than signs, some use a vertical line to the left of the text, some use a different color, etc. The result is a mess that's difficult to follow. I think rich-text works well when everyone uses the same mail client. For example, at a company I used to work, for everyone used Microsoft Outlook as their mail client, and emails were sent in rich text. There was no readability problem there because everyone used the same formatting conventions. However, requiring that everyone that posts to a public mailing list use the same mail client is even more restrictive than requiring that they use plain text. The only other way to ensure consistency of formatting conventions is to use the lowest common denominator between mail clients, which is plain text. Regards, Nate
Re: Could we start accepting rich-text postings on the gcc lists?
For me the most annoying thing about HTML burdened emails is idiots who choose totally inappropriate fonts, that make their stuff really hard to read. I choose a font for plain text emails that is just right on my screen etc. I do NOT want it overridden. And as for people who use color etc, well others have said enough there .
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 5:00 PM, Richard Kenner wrote: >> It's just that an increasing number of mail agents are configured by >> default to send rich-text. > > And people who know enough about computing to work on compilers don't know > how to change the default on their MUA? That seems like a poor reason to > make such a change. I already addressed this upthread. We are starting to talk in circles. The point is not to add unnecessary irritation. Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
> It's just that an increasing number of mail agents are configured by > default to send rich-text. And people who know enough about computing to work on compilers don't know how to change the default on their MUA? That seems like a poor reason to make such a change.
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 4:41 PM, Richard Kenner wrote: > Similarly for text-only vs. "rich text". You may argue that there's no > compatibility issue, but I disagree. As was pointed out upthread, when > people use "rich text", they often start to use colors or other mechanisms > to express themselves, which can now be dependent on the rendering agent > used to read the email. Requiring people to express themselves using only > words seems to me to encourage the sorts of discipline that we require in > contributors. We disagree on this point, then. While rich-text can be abused, it is not my experience that people do abuse it to the point of making their postings illegible. The markings you see commonly used are monospace font alterations, bolding and lists. I have noticed no correlation between the ability to use a markup language and quality of contributions. But more than anything, people write plain text with no markups. It's just that an increasing number of mail agents are configured by default to send rich-text. So, I disagree that we will start seeing posts with animated gif images, magenta backgrounds and green fonts. Would you be willing to give it a try? If we measure any loss in quality, then we can always flip back to text-only. Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
> It's not that they *cannot* follow an arbitrary rule. It is that the > rule bears no relation with the quality of their work, so they see it > as an artificial roadblock which merely irritates them. Add enough > irritants and they may decide to take their contributions elsewhere. Coding standards are "arbitrary" rules. For the vast majority of coding standards, you can't make a technical argument for or against them. We all agree to use the same standard because we understand that uniformity is important. Similarly for text-only vs. "rich text". You may argue that there's no compatibility issue, but I disagree. As was pointed out upthread, when people use "rich text", they often start to use colors or other mechanisms to express themselves, which can now be dependent on the rendering agent used to read the email. Requiring people to express themselves using only words seems to me to encourage the sorts of discipline that we require in contributors.
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 4:27 PM, Richard Kenner wrote: >> And restricting writers, may result in the loss of contributors in the >> medium/long term. > > We have a lot of things we do that "restrict" writers. We insist that > patches be tested. We insist that coding standards be followed. We > insist that good documentation practices be applied. We don't allow certain > changes at certain times in the process. Etc. No. You are confusing artificial restrictions with QOI. Coding and testing standards are paramount for the long term viability of the project. > Are there really people who are disciplined enough to follow those rules > who can't or won't follow a "text-only" rule? It's not that they *cannot* follow an arbitrary rule. It is that the rule bears no relation with the quality of their work, so they see it as an artificial roadblock which merely irritates them. Add enough irritants and they may decide to take their contributions elsewhere. Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
> And restricting writers, may result in the loss of contributors in the > medium/long term. We have a lot of things we do that "restrict" writers. We insist that patches be tested. We insist that coding standards be followed. We insist that good documentation practices be applied. We don't allow certain changes at certain times in the process. Etc. We do this because we value quality above quantity. Are there really people who are disciplined enough to follow those rules who can't or won't follow a "text-only" rule?
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 4:14 PM, Andrew Haley wrote: > On 11/23/2012 08:12 PM, Andrew Pinski wrote: >> On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote: >>> In this day and age of rich-text capable mailers, restricting postings >>> to be text-only seems quaint and antiquated. Are there any hard >>> requirements that force us to only accept plain text messages? > > It's a reasonable compromise, I would have thought: it makes things > easier for the reader while restricting the writer. There are many > more readers than writers, so this is a win. Well, it's not actually restricting writers, as I showed in that thread (there are others). When the writer reaches the intended individual recipient, they proceed to ignore the rejection message from the list. This is a net loss for us. And restricting writers, may result in the loss of contributors in the medium/long term. We are putting several roadblocks for new contributors. This is not a good long term strategy for us. Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
On 11/23/2012 08:12 PM, Andrew Pinski wrote: > On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote: >> In this day and age of rich-text capable mailers, restricting postings >> to be text-only seems quaint and antiquated. Are there any hard >> requirements that force us to only accept plain text messages? It's a reasonable compromise, I would have thought: it makes things easier for the reader while restricting the writer. There are many more readers than writers, so this is a win. Andrew.
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 03:35:57PM -0500, Diego Novillo wrote: > On Fri, Nov 23, 2012 at 3:31 PM, Ruben Safir wrote: > >> > > >> > incorrect accessment > >> > >> I can't parse this. > > > > > > Maybe HTML markup can help you. > > > > > > Stupid conversation > > No need to respond in such an arrogant and condescending manner. I do > not understand what "incorrect accessment" means. Here is 50 cents kid. Get yourself a real operating system. Are we done with this nonsense yet and can we get back to discussing the GNU complier? Ruben ~~~ So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 © Copyright for the Digital Millennium
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 3:31 PM, Ruben Safir wrote: >> > >> > incorrect accessment >> >> I can't parse this. > > > Maybe HTML markup can help you. > > > Stupid conversation No need to respond in such an arrogant and condescending manner. I do not understand what "incorrect accessment" means. Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
Why are you using google for your mail? Can't you get a real mail client and a real mail access? Or maybe you work for google, in which I can undersand it.
Re: Could we start accepting rich-text postings on the gcc lists?
> > > > incorrect accessment > > I can't parse this. Maybe HTML markup can help you. Stupid conversation
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 3:12 PM, Andrew Pinski wrote: > On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote: >> In this day and age of rich-text capable mailers, restricting postings >> to be text-only seems quaint and antiquated. Are there any hard >> requirements that force us to only accept plain text messages? > > I think it is a bad idea to accept non plain text messages (except for > attachments). > >> >> I'm seeing two developments because of this: >> >> 1. Frustration on the part of developers who get their posts rejected. >> This happens to me when I'm on my phone, the phone mailer does not >> even offer the option of sending text-only mail (I filed a bug about >> it ~3 years ago). This is mildly annoying, but annoying nonetheless. >> Recently, I had to teach a couple of new developers how to set their >> mailer to send plaintext messages (I felt like a dinosaur). > > This frustration is going to be on other people side if we start > allowing rich-text emails. Plain text is still more readable than > most richtext for the plain reason as the formatting is gone. What mailers are you thinking of? All the ones I've used in the last decade or so have been perfectly capable of dealing with rich-text. > If you feel like a dinosaur for helping developers to set their > mailers to send plaintext messages, then there is a problem with how > people are learning about email and the internet and why richtext is > bad news. I'm trying to adapt to the new reality of the internet. Not fight it. > >> >> 2. Posts disappear and are not re-posted in text form. If the message >> was CC'd to another maintainer, then the original posters does not >> care that their message got rejected. They got to their intended >> recipient, who typically responds, leaving broken threads on the >> mailing list. For example, check the thread index for >> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00011.html. You'll >> notice that there are no messages from Dmitry Vyukov, despite him >> sending no less than 6 replies to that thread. > > It is up to the contributor to read the requirements before submitting > patches and plain text emails are a documented requirement right now. It is also up to the contributor to not care and take their contributions elsewhere. > Bad formatted emails are less likely to happen with plain text. > Allowing rich text will cause people to have worse formatted email. Do you have data to support this? > >> >> I'm more concerned about #2. Today's software is more than capable of >> dealing with rich text. Is it really that important for us to stick >> to this requirement? >> >> If the reason is "because we like it this way", please consider the >> impact on contributors and would-be contributors. Why add one more >> aggravation to the already long list? > > It is not just because we like it this way, rich text (or in some > cases html) can cause security holes. Again. Data? > PS I think this really should go to the gcc@ list rather than > overseers list because even though overseers is in control of the > machines, the decision about allowing rich text is a gcc policy rather > than a machine policy. Sure. First I wanted to find out whether this requirement is just a technical limitation with our mailing list software. Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 3:14 PM, Ruben Safir wrote: > On Fri, Nov 23, 2012 at 12:12:17PM -0800, Andrew Pinski wrote: >> On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote: >> > In this day and age of rich-text capable mailers, restricting postings >> > to be text-only seems quaint and antiquated. Are there any hard >> > requirements that force us to only accept plain text messages? > > > incorrect accessment I can't parse this.
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 12:12:17PM -0800, Andrew Pinski wrote: > On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote: > > In this day and age of rich-text capable mailers, restricting postings > > to be text-only seems quaint and antiquated. Are there any hard > > requirements that force us to only accept plain text messages? incorrect accessment
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote: > In this day and age of rich-text capable mailers, restricting postings > to be text-only seems quaint and antiquated. Are there any hard > requirements that force us to only accept plain text messages? I think it is a bad idea to accept non plain text messages (except for attachments). > > I'm seeing two developments because of this: > > 1. Frustration on the part of developers who get their posts rejected. > This happens to me when I'm on my phone, the phone mailer does not > even offer the option of sending text-only mail (I filed a bug about > it ~3 years ago). This is mildly annoying, but annoying nonetheless. > Recently, I had to teach a couple of new developers how to set their > mailer to send plaintext messages (I felt like a dinosaur). This frustration is going to be on other people side if we start allowing rich-text emails. Plain text is still more readable than most richtext for the plain reason as the formatting is gone. Formatting in rich-text emails make most richtext emails hard to read. People like to reply in a different color and that just makes it hard to figure out who is replying to who. If you feel like a dinosaur for helping developers to set their mailers to send plaintext messages, then there is a problem with how people are learning about email and the internet and why richtext is bad news. > > 2. Posts disappear and are not re-posted in text form. If the message > was CC'd to another maintainer, then the original posters does not > care that their message got rejected. They got to their intended > recipient, who typically responds, leaving broken threads on the > mailing list. For example, check the thread index for > http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00011.html. You'll > notice that there are no messages from Dmitry Vyukov, despite him > sending no less than 6 replies to that thread. It is up to the contributor to read the requirements before submitting patches and plain text emails are a documented requirement right now. Bad formatted emails are less likely to happen with plain text. Allowing rich text will cause people to have worse formatted email. > > I'm more concerned about #2. Today's software is more than capable of > dealing with rich text. Is it really that important for us to stick > to this requirement? > > If the reason is "because we like it this way", please consider the > impact on contributors and would-be contributors. Why add one more > aggravation to the already long list? It is not just because we like it this way, rich text (or in some cases html) can cause security holes. Formatting issues are worse with rich text emails. Also once you start allowing richtext emails, you will find that people start depending on rich text to format tables and other things and the plain text part will not be readable. Thanks, Andrew Pinski PS I think this really should go to the gcc@ list rather than overseers list because even though overseers is in control of the machines, the decision about allowing rich text is a gcc policy rather than a machine policy.
