maildev@lists.thunderbird.net

Thunderbird email developers

View all threads

Fwd: Upcoming changes to our JS coding style

MM
Magnus Melin
Fri, Aug 30, 2019 7:57 AM

On 30-08-2019 00:17, Ben Bucksch wrote:

most core developers disagree with you.

Factually untrue on many levels actually. Not even a majority involved
in this thread, let alone devs from m-c. Not that it's a vote.

 -Magnus

On 30-08-2019 00:17, Ben Bucksch wrote: > most core developers disagree with you. Factually untrue on many levels actually. Not even a majority involved in this thread, let alone devs from m-c. Not that it's a vote.  -Magnus
MM
Magnus Melin
Fri, Aug 30, 2019 7:58 AM

On 30-08-2019 01:38, Jörg Knobloch wrote:

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.

Up to him. I would still recommend going with 80 there too for
consistency with everything else.

Calendar had good reasons to use 100ch earlier, due to their
non-standard use of the 4 space indent which meant 80ch doesn't get you
far. With the shift to 2 space indent now, I don't see good reasons to
diverge.

What has the MailNews owner decided?

Like you saw in the other sub-thread, that would be 80ch.

 -Magnus

On 30-08-2019 01:38, Jörg Knobloch wrote: > 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. Up to him. I would still recommend going with 80 there too for consistency with everything else. Calendar had good reasons to use 100ch earlier, due to their non-standard use of the 4 space indent which meant 80ch doesn't get you far. With the shift to 2 space indent now, I don't see good reasons to diverge. > > What has the MailNews owner decided? Like you saw in the other sub-thread, that would be 80ch.  -Magnus
BB
Ben Bucksch
Fri, Aug 30, 2019 10:48 AM

Jörg Knobloch wrote on 29.08.19 23:43:

On 29 Aug 2019 23:17, Ben Bucksch wrote:

https://mail.mozilla.org/pipermail/tb-planning/2017-July/005610.html
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".

I confirm that vote. I was present as Council member.

Kent's email was a reaction to that vote.

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.

Given that 4 out of 7 Council votes are the majority, and the Council is
officially responsible for steering the project, I claim that this was
valid.

The fact that this mailing list exists (which is where the ESC meets, in
form of a mailing list, and it was deliberately created as open list, so
that all core developers can participate and voice their opinion and be
heard), and the 3 of us (Jörg, Magnus and me) are discussing, shows that
the ESG is very well in place and active.

That's all I say about this. I'll otherwise let this case rest, because
line widths are not important enough to fight over, and I regret that I
made a debate out of it. I'm sorry for that.

We should focus on renewing the core architecture of Thunderbird instead.

Conclusion: The project has a deficit of technical governance

That I certainly agree with.

I love the work that BenC and Goeff are doing. Goeff is reactive to
addon author requests. This is great.

But the core questions like "everything is a URL" are not tackled at
all. I would invite BenC to lead here for such infrastructural and core
API changes.

Ben

Jörg Knobloch wrote on 29.08.19 23:43: > On 29 Aug 2019 23:17, Ben Bucksch wrote: >> https://mail.mozilla.org/pipermail/tb-planning/2017-July/005610.html >> 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". I confirm that vote. I was present as Council member. Kent's email was a reaction to that vote. > 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. Given that 4 out of 7 Council votes are the majority, and the Council is officially responsible for steering the project, I claim that this was valid. The fact that this mailing list exists (which is where the ESC meets, in form of a mailing list, and it was deliberately created as open list, so that all core developers can participate and voice their opinion and be heard), and the 3 of us (Jörg, Magnus and me) are discussing, shows that the ESG is very well in place and active. That's all I say about this. I'll otherwise let this case rest, because line widths are not important enough to fight over, and I regret that I made a debate out of it. I'm sorry for that. We should focus on renewing the core architecture of Thunderbird instead. > Conclusion: The project has a deficit of technical governance That I certainly agree with. I love the work that BenC and Goeff are doing. Goeff is reactive to addon author requests. This is great. But the core questions like "everything is a URL" are not tackled at all. I would invite BenC to lead here for such infrastructural and core API changes. Ben
BB
Ben Bucksch
Fri, Aug 30, 2019 2:49 PM

Onno Ekker wrote on 30.08.19 08:00:

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 [before 1985] could already be switched from 80 character mode into 132 character mode!

LOL, 132 chars it is, then!

(Just kidding. Apologies again for drumming on this so much yesterday.)