On Monday, March 17, 2025 10:34:39 PM Mountain Standard Time Jonas Smedegaard wrote: > Hi Soren, > > Quoting Soren Stoutner (2025-03-18 02:26:22) > > > On Sunday, March 16, 2025 3:35:21 AM Mountain Standard Time Cord Beermann wrote: > > > Hallo! Du (Soren Stoutner) hast geschrieben: > > > > > > <Listmaster-Hat status=on> > > > > > > >1. I assume the listmasters are subscribed to debian-devel, so > > > >when I posted the original discussion there I considered that I > > > >was including them. > > > > > > no, i'm not subscribed to that, you can't assume that, and it is > > > not a requirement for a DD, and not for a listmaster. (should > > > we read every list we run? That would be a fulltime job.) > > > I also think that the discussion is wrongly placed in d-devel > > > and > > > should go to d-project. > > > > I considered posting to debian-project instead of debian-devel, > > but I considered this to be a technical issue, and my > > understanding it that debian-devel is for technical issues and > > debian-project is for non-technical issues. > > > > > A side-thought: could this change cause problems for people that > > > rely on a screenreader? > > > > Possibly. The reason why I started the original thread on > > debian-devel was to see if making this change would have some > > unintended consequences that I had not considered. So far, > > nobody has responded indicating it would cause any particular > > problems for screen readers, but perhaps those who would know > > have not seen the thread yet. > > > > > >2. As described in the text that you snipped, this issue is > > > >bigger > > > >than just the lists. For example, it also applies to the BTS. > > > >As > > > >such, I don’t think the listmasters are the correct place to > > > >address it for the entire Debian project. I consider the > > > >discussion on debian-devel to have be the correct initial > > > >place, > > > >followed by this GR when it became apparent that some people > > > >were > > > >strongly opposed to the proposal and a consensus decision was > > > >not > > > >possible. > > > > > > Yes, we as the people that run those systems have to check if > > > our > > > tooling copes correctly with the removal of those suggestions. > > > That > > > involves the BTS, our archiving software and our filtering > > > software > > > (which contains a scoring mechanism based on content and > > > formatting) > > > > > > <Listmaster-Hat status=off> > > > > > > > > > I'm personally deeply unsympathetic to your proposal. > > > > > > Your Mails look horrible and are sometimes close to unreadable > > > in my Mailsetup (mutt in a xterm, I will not discuss this, just > > > a feedback). I usually don't have the time and the energy to > > > invest in such mails (reformatting so that quoting/commenting > > > is > > > possible). > > > > My mails do look horrible, and I apologize for that. It is > > because of a fairly recent change in Kmail that appears to try to > > adopt part of the format=flowed syntax, with no controls for > > turning it off. This exacerbates pre-existing problems with > > emails with hard-column limits. > > > > The fact that such emails look so horrible is exactly why I am > > making the proposal, as not having the MUA hard wrap text avoids > > all of these problems. As such, the timing if this particular > > Kmail bug (which creates unusable hard-line break in every > > outgoing email, which by the way are not visible during > > composition) is partially a blessing, as it clearly demonstrates > > why this change should be made. Even when this Kmail bug is > > fixed, these same problems will appear when text is quoted > > multiple times and exceeds the 80 column limit. > > Have you considered that your choice of MUA might be the problem > here, rather than the policies and conventions of Debian? This conversation is not about just one MUA, although it seems like many people want to attack the MUA I am using instead of discussing the issue at hand. In answer to your question, before I made the very first post on this subject I considered the the proposed change would be a benefit to the vast majority of MUAs out there. For example, it would improve the experience all of the MUAs I use frequently, which are Kmail, Thunderbird, Thunderbird on Android (which is a different codebase from the desktop version of Thunderbird), and Roundcube. It would also improve the experience on other MUAs I use infrequently, including Gmail’s web interface and Gmail’s Android client. In the course of the discussion I have learned that there are some MUAs where the benefit of the change are not completely positive. Mostly this appears to be for people who use Mutt with the various editors it supports. Based on the discussion on debian-devel, some of these negatives can be overcome by changing some of Mutt’s settings. Other aspects of this change would require changes in workflows that users of Mutt would find distasteful. For example, it was explained to me that in an offline conversation that mutt/vim scrolls by multiple lines at a time with the arrow keys when viewing text that has been wrapped by the receiving MUA while only scrolling one line at a time when viewing text that has been hard-wrapped by the sending MUA. Although I am sympathetic to resistance to anything that forces someone to change their workflow, I consider the benefits of this change to outweigh the negatives for the vast majority of MUAs. As such, I still consider this to be a change that should be implemented based on its merits. Recently there was an email asking if there were any negatives to emails that didn’t wrap outgoing text at 80 columns for screen readers. So far, nobody has brought up any concrete concerns with screen readers. However, if there was a concern in this area, and if it caused such problems that it made it impossible for a screen reader to parse such an email, then I would consider that to be a significant enough of an issue that I would change my position, because if there are downsides at that level for even a small number of users then I don’t think the change should be made even if it would benefit the majority of the other users. -- Soren Stoutner soren@debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part.