Fwd: Upcoming changes to our JS coding style
Magnus Melin wrote on 29.08.19 21:38:
Thunderbird always used 80ch.
That is simply not true. Otherwise we wouldn't have this discussion.
I've been around much longer than you, and I can certify that 80 chars
was always a guideline, but not a hard limit.
There's a huge difference between "You should not eat too much sugar"
(or salt or milk) and "You must never ever eat sugar".
Most core devs said they prefer 100 chars as max. And how you push this
through, despite better knowledge? This is causing more problems than it
solves. I showed the actual damage that this does, with very concrete
examples.
On 29 Aug 2019 22:14, Ben Bucksch wrote:
Most core devs said they prefer 100 chars as max. And how you push
this through, despite better knowledge? This is causing more problems
than it solves. I showed the actual damage that this does, with very
concrete examples.
https://www.mozilla.org/en-US/about/governance/policies/module-ownership/
Quote: Module owners are not tyrants.
Calendar is done with 100 chars as we speak, I still haven't see a try
run. When that's done, we should inspect the result an see whether we
like it.
I think on matters of taste with no technical value we should vote in
the Engineering Steering Committee. My vote for now would be: Do
Calendar and then see. There is absolutely no need to rush this through.
Jörg.
On 29-08-2019 23:14, Ben Bucksch wrote:
Magnus Melin wrote on 29.08.19 21:38:
Thunderbird always used 80ch.
That is simply not true. Otherwise we wouldn't have this discussion.
I've been around much longer than you, and I can certify that 80 chars
was always a guideline, but not a hard limit.
I never said it was imposed as a hard limit. It's nevertheless the limit
we've used.
There's a huge difference between "You should not eat too much sugar"
(or salt or milk) and "You must never ever eat sugar".
Most core devs said they prefer 100 chars as max. And how you push
this through, despite better knowledge? This is causing more problems
than it solves. I showed the actual damage that this does, with very
concrete examples.
FTR, I do think the imports change is not ideal, but that will sort it
self out once we start using standard import statements, which shouldn't
be that far off (maybe a year though). Prettier puts those on one line.
-Magnus
On 08/29/2019 02:40 PM, Jörg Knobloch wrote:
On 29 Aug 2019 22:14, Ben Bucksch wrote:
Most core devs said they prefer 100 chars as max. And how you push
this through, despite better knowledge? This is causing more problems
than it solves. I showed the actual damage that this does, with very
concrete examples.
People who are not core developers should stop spamming this list. And
stop voting over and over and over...
https://www.mozilla.org/en-US/about/governance/policies/module-ownership/
Quote: Module owners are not tyrants.
Sorry Jörg, this is hardly correct. And if it has "no technical value",
why should an engineering committee decide. It is purely a decision to
reduce complexity and deviation from our major upstream code provider.
Regardless of personal tastes.
On 29-08-2019 23:40, Jörg Knobloch wrote:
https://www.mozilla.org/en-US/about/governance/policies/module-ownership/
Quote: Module owners are not tyrants.
Calendar is done with 100 chars as we speak, I still haven't see a try
run. When that's done, we should inspect the result an see whether we
like it.
I think on matters of taste with no technical value we should vote in
the Engineering Steering Committee.
Never established, and would not decide on such an issue anyway. Clearly
someone needs to take the decision, and in this case it's the module owner.
My vote for now would be: Do Calendar and then see. There is
absolutely no need to rush this through.
Delaying is time away from other work. There's no time like the present.
No technical value? This is rather about other values, such as
consistency making it easier to contribute. And monetary value: I hope
you realize any unnecessary differences from mozilla-central would
have significant costs over time (we have more semi-forked files than
you realize, fighting with the tooling etc.). I'm not willing to put
resources on a thing like that when we can easily avoid it.
-Magnus
Magnus Melin wrote on 29.08.19 23:00:
On 29-08-2019 23:40, Jörg Knobloch wrote:
we should vote in the Engineering Steering Committee.
Never established
Factually untrue:
https://mail.mozilla.org/pipermail/tb-planning/2017-July/005610.html
Clearly someone needs to take the decision, and in this case it's the
module owner.
The decision needs to be good for the project, and most core developers
disagree with you.
The Engineering Council was deliberately established to be over the
module owner, see section B3.
And this mailing list is where the ESG discusses. That's what we're doing.
On 29 Aug 2019 23:17, Ben Bucksch wrote:
The Engineering Council was deliberately established to be over the
module owner, see section B3.
The Thunderbird Council passed a vote on 2017-06-23 as follows:
"Engineering decisions: New module owners (makes decisions): Kent, Jörg,
Magnus, Ben".
This group if "technical directors" was destined to take decisions of
far reaching consequences. Magnus wasn't present at the meeting and he
later declared the vote null and void since it wasn't inline with the
Mozilla Governance system of Module Owners.
Conclusion: The project has a deficit of technical governance reform,
and any attempt at it so far has failed.
Jörg.
P.S.: See last two paragraphs of
http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/2018-August/001277.html
On 29 Aug 2019 23:00, Magnus Melin wrote:
Clearly someone needs to take the decision, and in this case it's the
module owner.
Right.
If I understood it correctly, Philipp decided on 100 chars for Calendar.
What has the MailNews owner decided? Oops, another technical governance
building site :-(
So if Calendar and MailNews went with 100 chars, would you go with 80?
On 8/28/2019 7:08 PM, Ben Bucksch wrote:
Maybe we should configure the line width to be 120, for all lines. 80
should still be the goal, but a little leeway helps a lot, in cases
like the mentioned one. After all, we're not working on 80x25 char
green monitors anymore, but on HD screens or more. I don't want this
extra space to be eaten by long lines and variable names, but a little
leeway is reasonable. So, I'd say "Try to stay within 80 chars" to
humans, and "120 chars max" to the computer formatter.
The goal of an automated formatter is to make the text as readable as
possible (using some set of heuristics) within a given line width. The
line width we are targeting for readability is 80 characters. Yes, that
limit was historically a soft limit, but the intention is that the text
would look readable within 80-char-width terminals, and if a line
slightly exceeded an 80-char terminal but was still perfectly readable,
then don't sweat trying to find where the best line break was to meet a
hard limit. So for computer formatter, the 80-character line-width is
the inherited rule for the formatter.
I will point out that there is no consensus on what the line width
should be. In the absence of consensus to make a change, the status quo
(of 80) prevails.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
On Thu, Aug 29, 2019 at 3:59 PM Ben Bucksch ben.bucksch@beonex.com wrote:
Jörg Knobloch wrote on 29.08.19 10:51:
Hands up who is still using vi in a terminal window ;-)
You can even resize terminal windows.
Hands up who is still using vi on physical green 80x25 char terminal!
;-)
For those young ones: Something like this:
http://cts.dmu.ac.uk/study/images/Viewpoint-1A-dumb-terminal-large.JPG
Ben
o/
I still use vi as my preferred editor in terminal windows, although I must
admit that it's mostly an alias to vim, vi-improved.
But even in my days at university (around '85) the VT-20 terminals were
being replaced in favor if sun-systems with X-windows.
But even those dumb terminals from the early days could already be switched
from 80 character mode into 132 character mode!
Onno