----- BACKGROUND STARTS -----than 80 characters are acceptable for computer-generated output
The text of the current mailing list code of conduct states:
"Wrap your lines at 80 characters or less for ordinary discussion. Lines longer
(e.g., ls -l)."having the ability to wrap the text of incoming emails and some older
https://www.debian.org/MailingLists/
There were historical reasons for requiring people to wrap outgoing emails relating to some older MUAs (Mail User Agents also known as email clients) not
screens being limited to an 80 character width.has the ability to wrap incoming lines.
These historical reasons no longer apply, as every MUA of which I am aware now
From a technical perspective, I believe having the sending MUA hard-wrap linesat a particular column is the incorrect approach because there is no
single line limit that works well on all receiving devices. Many cell phones have a display width of 40 columns or less, while modern desktops have a display width of far more than 80 columns. The only system that knows how big the viewport is where the mail will be displayed is the receiving MUA, so that is where decisions about line wrapping should be made.solution. Format=flowed is an RFC that proposes a system for
Having hard line wraps also causes problem with quoted text, where after multiple replies text will start to break in places that can make some of the quoted text appear to not be quoted. I am sure that everyone on the mailing lists has seen emails exhibiting that problem.
There has is some discussion about this issue on debian-devel beginning at:
https://lists.debian.org/debian-devel/2025/02/msg00302.html
In that discussion, several people have suggested the use of format=flowed as a
hard-wrapping text but including special codes that allow a receiving MUA to unwrap them and then rewrap them to the current viewport.requirement for communication on the mailing lists or a general
https://www.ietf.org/rfc/rfc2646.txt
Format=flowed never gained wide adoption by the majority of MUAs. Although I don't have any objections to anyone using it, I don't see it as an appropriate
solution to the problems of hard-wrapped text because it doesn't have wide enough
implementation.
----- BACKGROUND ENDS -----
----- GENERAL RESOLUTION STARTS -----Resolution.
It is no longer required that emails sent to or received from official Debian infrastructure like the mailing lists or the BTS (Bug Tracking System) be wrapped at any particular column, although users and automated systems may choose to wrap emails at any column they prefer. Using format=flowed is not required for emails, but users and automated systems may do so if they like. The maintainers of the mailing list code of conduct shall update the text relating to the wrapping of emails at 80 characters to be the following:
"There is no expectation that emails sent to the mailing lists are wrapped by the sender at a particular column, but those sending emails may wrap them if they choose."
In the future, they may modify the above text of the code of conduct to meet changing circumstances as long as it does not violate the spirit of this General
----- GENERAL RESOLUTION ENDS -----
--
Soren Stoutner
[email protected]
There has is some discussion about this issue on debian-devel beginning at:
https://lists.debian.org/debian-devel/2025/02/msg00302.html
In that discussion, several people have suggested the use of format=flowed as a
solution. Format=flowed is an RFC that proposes a system for hard-wrapping text
but including special codes that allow a receiving MUA to unwrap them and then >rewrap them to the current viewport.
----- BACKGROUND STARTS -----*snip as the content isn't important*
The text of the current mailing list code of conduct states:
"Wrap your lines at 80 characters or less for ordinary discussion. Lines longer
than 80 characters are acceptable for computer-generated output (e.g., ls -l)."
https://www.debian.org/MailingLists/
On Saturday, March 15, 2025 12:55:04 PM Mountain Standard Time Alexander Wirt wrote:
Am Sat, Mar 15, 2025 at 11:44:21AM -0700 schrieb Soren Stoutner:
----- BACKGROUND STARTS -----
The text of the current mailing list code of conduct states:
"Wrap your lines at 80 characters or less for ordinary discussion. Lines longer than 80 characters are acceptable for computer-generated output (e.g., ls -l)."
https://www.debian.org/MailingLists/
*snip as the content isn't important*
really? you want to override a delegate you never asked? What about creating a bug on l.d.o first and see what happens?
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.
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.
If I had opened a bug report on l.d.o first, would you have made the
requested change?
Am Sat, Mar 15, 2025 at 11:44:21AM -0700 schrieb Soren Stoutner:
----- BACKGROUND STARTS -----
The text of the current mailing list code of conduct states:
"Wrap your lines at 80 characters or less for ordinary discussion. Lines longer than 80 characters are acceptable for computer-generated output (e.g., ls -l)."
https://www.debian.org/MailingLists/
*snip as the content isn't important*
really? you want to override a delegate you never asked? What about
creating a bug on l.d.o first and see what happens?
Am Sat, Mar 15, 2025 at 01:26:01PM -0700 schrieb Soren Stoutner:wrote:
On Saturday, March 15, 2025 12:55:04 PM Mountain Standard Time Alexander Wirt
Am Sat, Mar 15, 2025 at 11:44:21AM -0700 schrieb Soren Stoutner:
----- BACKGROUND STARTS -----
The text of the current mailing list code of conduct states:
"Wrap your lines at 80 characters or less for ordinary discussion. Lines
longer than 80 characters are acceptable for computer-generated output (e.g., ls -l)."
https://www.debian.org/MailingLists/
*snip as the content isn't important*
really? you want to override a delegate you never asked? What about creating a bug on l.d.o first and see what happens?
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.
Of course we are, but you should not expect us to read anything. If you
want use to change a document in our domain, talk to us first and do it
like everyone does: create a bug.
On Sat, Mar 15, 2025 at 01:42:59PM -0700, Soren Stoutner wrote:
If I had opened a bug report on l.d.o first, would you have made the
requested change?
At this point, why not file the bug and see what the listmasters do?
At this point, why not file the bug and see what the listmasters do?
If Alexander indicates that he would be willing to implement the change
if I file a bug report then I will do so.
On Sat, Mar 15, 2025 at 02:06:45PM -0700, Soren Stoutner wrote:
At this point, why not file the bug and see what the listmasters do?
If Alexander indicates that he would be willing to implement the change
if I file a bug report then I will do so.
You disagree with a delegate. You're now attempting to use the "threat"
of a GR to bypass having a real conversation with the person responsible
for enforcing the decision you want?
Actual question for you, Soren -- are you happy with how this is going?
Alexander has been incredibly helpul and forward leaning over the years. Perhaps overworked, but I can't imagine starting the conversation off in
this way is the best way of going about this.
Why don't you approach the listmaster team in a lower stakes way and
have a conversation understanding what their point of view actually is
rather than trying to guess here.
I don't think listmaster@ really needs to reply to this with "yes/no", I think the whole premise and escalation here is a great indicator y'all
need to have a chat off-list or something, which likely needs to be
driven by you, Soren, and not try to keep jamming this through -- that's
only going to build resentment throughout the project and start yet
another stupid rift that we'll infight over for years. I'd love to avoid that.
I apologize for sending three copies of this proposal. The digital signature on the first two
was mangled for some reason. The signature on the copy I am responding to here should
be clean.
Having hard line wraps also causes problem with quoted text, where after
multiple replies text will start to break in places that can make some of the
quoted text appear to not be quoted. I am sure that everyone on the mailing >> lists has seen emails exhibiting that problem.
In that discussion, several people have suggested the use of format=flowed assolution. Format=flowed is an RFC that proposes a system for
a
hard-wrapping text but including special codes that allow a receiving MUA to >> unwrap them and then rewrap them to the current viewport.
I apologize for sending three copies of this proposal. The digital signature on the first two
was mangled for some reason.
On Sat, Mar 15, 2025 at 11:47:50AM -0700, Soren Stoutner wrote:
I apologize for sending three copies of this proposal. The digital signature on the first two was mangled for some reason.
Maybe you didn't wrap at 80 chars?
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.
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.
I am here for some time now (more than two decades) and I am a
listmaster for... too long and I can tell you: Debian does not work
like this.
----- BACKGROUND STARTS -----
The text of the current mailing list code of conduct states:
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.
A side-thought: could this change cause problems for people that
rely on a screenreader?
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).
Your proposal (and some of your mails with HTML and things) and your
approach feels to me like you are not willing to accept the "rules"
that we have given ourselves.
It is fine to question and also change those, but yet they haven't
been changed, so they should be honored.
Le Sat, Mar 15, 2025 at 11:44:21AM -0700, Soren Stoutner a écrit :
----- BACKGROUND STARTS -----
The text of the current mailing list code of conduct states:Hi Soren,
In this text, at some point, you need to state under which article
of the Debian constitution this GR falls and why.
After having done that, you may decide whether this GR is premature
because the avenues for resolving this issue without a GR have not
been exhausted.
Hi Soren,Beermann wrote:
Quoting Soren Stoutner (2025-03-18 02:26:22)
On Sunday, March 16, 2025 3:35:21 AM Mountain Standard Time Cord
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?
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
[email protected]
"Andrew" == Andrew M A Cater <[email protected]> writes:
I would be interested to hear if you are aware of any other decision
making process that you think should decide this issue. For example, imagine that I opened a bug against l.d.o and the listmasters decided
to implement the change I propose. Do you think those who are against
that change would be satisfied by that process?
I really don’t think that anything I have done could be described as jamming anything
through. I feel like I opened a respectful discussion on debian-devel. When that reached
the stage where it was obvious that a consensus decision was not possible, I moved to the
appropriate place for making Debian-wide decisions, which is the GR.
----- BACKGROUND STARTS -----
The text of the current mailing list code of conduct states:
"Wrap your lines at 80 characters or less for ordinary discussion. Lines longer
than 80 characters are acceptable for computer-generated output (e.g., ls -l)."
https://www.debian.org/MailingLists/
There were historical reasons for requiring people to wrap outgoing emails relating to some older MUAs (Mail User Agents also known as email clients) not
having the ability to wrap the text of incoming emails and some older screens being limited to an 80 character width.
These historical reasons no longer apply, as every MUA of which I am aware now
has the ability to wrap incoming lines.
From a technical perspective, I believe having the sending MUA hard-wrap lines
at a particular column is the incorrect approach because there is no single line
limit that works well on all receiving devices. Many cell phones have a display
width of 40 columns or less, while modern desktops have a display width of far
more than 80 columns. The only system that knows how big the viewport is where
the mail will be displayed is the receiving MUA, so that is where decisions about line wrapping should be made.
Having hard line wraps also causes problem with quoted text, where after multiple replies text will start to break in places that can make some of the quoted text appear to not be quoted. I am sure that everyone on the mailing lists has seen emails exhibiting that problem.
There has is some discussion about this issue on debian-devel beginning at:
https://lists.debian.org/debian-devel/2025/02/msg00302.html
In that discussion, several people have suggested the use of format=flowed as a
solution. Format=flowed is an RFC that proposes a system for hard-wrapping text
but including special codes that allow a receiving MUA to unwrap them and then
rewrap them to the current viewport.
https://www.ietf.org/rfc/rfc2646.txt
Format=flowed never gained wide adoption by the majority of MUAs. Although I don't have any objections to anyone using it, I don't see it as an appropriate
requirement for communication on the mailing lists or a general solution to the
problems of hard-wrapped text because it doesn't have wide enough implementation.
----- BACKGROUND ENDS -----
----- GENERAL RESOLUTION STARTS -----
It is no longer required that emails sent to or received from official Debian infrastructure like the mailing lists or the BTS (Bug Tracking System) be wrapped at any particular column, although users and automated systems may choose to wrap emails at any column they prefer. Using format=flowed is not required for emails, but users and automated systems may do so if they like.
The maintainers of the mailing list code of conduct shall update the text relating to the wrapping of emails at 80 characters to be the following:
"There is no expectation that emails sent to the mailing lists are wrapped by the sender at a particular column, but those sending emails may wrap them if they choose."
In the future, they may modify the above text of the code of conduct to meet changing circumstances as long as it does not violate the spirit of this General
Resolution.
----- GENERAL RESOLUTION ENDS -----
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 04:30:12 |
| Calls: | 12,099 |
| Calls today: | 7 |
| Files: | 15,003 |
| Messages: | 6,517,894 |