Closed Bug 401779 Opened 17 years ago Closed 9 years ago

Integrate Lightning Into Thunderbird by Default and Ship Thunderbird with Lightning Enabled

Categories

(Thunderbird :: Build Config, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: worcester12345, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007102903 SeaMonkey/2.0a1pre
Build Identifier: 

This is the bug which Bug 349870 – Build Thunderbird with preinstalled Lightning was intended to be. 

It is to actually build a shipping product of Thunderbird with integral Lightning with no further work necessary by end users. This should be a complete build one can download from the web site. There should be a choice of whether to install Lightning which is selectable by a check box.


Reproducible: Always

Steps to Reproduce:
Download Thunderbird.
Actual Results:  
No Lightning installed.

Expected Results:  
Thunderbird with Lightning installed by default or by checkbox at install time.

No additional information at this time.
Flags: blocking-thunderbird3?
Depends on: 349870
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
You know what, there is no real reason this can't happen in 2.x. is there?
TB 2.x is on a stable release branch. You don't add major new features to such a branch.
(In reply to comment #1)
> You know what, there is no real reason this can't happen in 2.x. is there?

Several thoughts.
- It would be adding new features onto the existing maintainance branch -
something we don't normally allow.
- I expect this would require additional QA on the existing Thunderbird
maintainance branch which wouldn't be wanted (yes, the calendar teams have done
thier own testing, but I expect MoCo would want to check it more).
- It would cause the addition of new strings on the maintainance branch.
Although its an extension, it would require input from all locales that
currently ship with Thunderbird that don't ship with Lightning (no idea how
many that is), causing them extra effort where it has already been promised
there won't be.
- This would be something for the Thunderbird & Calendar teams to discuss, but
the focus may be better on developing and testing to include it in a future
release.
Points taken. I thought it would be far simpler and easier to implement than this, but the language issues alone are probably very large ones.

Here's to hoping for a new branch soon (2.5?) and then a 3.0 shortly after. It has been a long while, hasn't it.
Keywords: platform, polish
I was going to just now add "polish" key word, but saw I already did. Why was this removed?
Keywords: helpwanted
Because polish means "change this image, or add CSS for prettier buttons, and the UI will look a lot better," not "combine two products into one." And helpwanted means "the people in charge of this product or module want this to happen, but don't have the engineers available to assign to writing the code" not "the reporter wants this to happen."
Keywords: helpwanted
I see Seamonkey has another extension checkbox added recently. I'd say that calendar would be more popular than Palmsync would be.

Bug 322568 – PalmSyncInstall has not been built since October [SM suite] 


Keywords: helpwanted, mail3, mail6
Summary: Ship Thunderbird with integrated Lightning → Ship Thunderbird with integrated Lightning on as default
Thunderbird was initially designed as a light-weight stand-alone mail/news client. Adding the Lightning extension as an integrated component would deviate from this concept. Thus, while I fully support the integration efforts of Lightning into the suite (bug 313822), I'm a bit in doubt if it should be a default part of Thunderbird. However, it appears that its integration into Thunderbird is the preferred direction of the new Mozilla Messenger Co. (congratulations to its formal establishment, by the way!).

If Thunderbird is going to be shipped as one installer with Lightning (and possibly other components) added, IMO it is necessary to provide an option in the installer to opt out of these extensions. Some people may not need or want it, others may prefer other extensions instead. The same line of argumentation applies here as in bug 409490 for ChatZilla and SeaMonkey, which also provides a good example that such installer options can be added to the NSIS installer.
... and that's "Mozilla Messaging" of course, sorry for the typo. :-)
Should definently be an option during installation or at the very least, be able to disable via addons manager.
Given that other components/extensions may follow Lightning in being bundled into the Thunderbird installer, this should be done in the "best" way here to have a generic model. Installing all components first and then just allow to disable them implies carrying around unnecessary overhead. Also, if - for whatever reason they may have - somebody wants to install his or her own preferred calendar extension, those potentially interfere with each other.

A simple additional dialog in the installer

 [x] Install mail/news and calendar
 [ ] Install mail/news only

could be extended to the commonly found two-step dialog

 [x] Complete install
 [ ] Custom install
 [ ] Install mail/news only

if additional components/extensions should be included later.
I'd take that one step further and instead of mail/news make the news part optional. I don't use news, chatzilla, or most of that other stuff. That, or just put it all in there, and make it so quick, tight, and seamless that there is no reason to complain. 
QA Contact: build → build-config
What happened to the mail3, mail6, and helpwanted key words here?
Keywords: helpwanted, mail3, mail6
check the bug activity - the peer removed them, one might guess for obvious reasons
Thank you for your quick reply. The reasons are not obvious to this volunteer bug reporter.


From the key word info section:

helpwanted   	Bugs or features which require coding assistance to fix or implement.

This one certainly applies.





mail3   	Most important features. These will be features and or feature extensions. Examples are Usability bugs, UE Spec non-compliance bugs, threading, searching, import tools, filters, biff, improvements to the 3 pane window or compose window. (for use in bug triaging)

This is indeed a usability bug, and one with "most important features".





mail6   	Low risk, high gain Mail bugs. Mail Bugs which require little engineering effort but have high user benefit that might not otherwise be covered under the other keywords.

The risk to enabling this is fairly low, and the benefit is extremely high. 


I do not see the reason to take these key words away in light of the above information.
Worcester12345, please stop spamming this bug with useless keywords! This issue is already on the list of release goals for TB3. See item 3 on

http://wiki.mozilla.org/Thunderbird:Thunderbird3#Increased_Adoption

Personally I don't see any value in keeping this bug open, but I'll leave the decision to close this bug to the TB owners and peers.
Keywords: helpwanted, mail3, mail6
I strongly second comment #11.

I might even consider the possibility of just making all parts of Thunderbird modular and optional, even mail.  That way people who just want news and IRC can be satiated just as easily as those who just want the current 2.x.x Mail/News arrangement.  But perhaps people will find that idea goes too far.

Personally, I want/will use Thunderbird purely for email; and I would be very happy if there was a way I could get just that functionality.

As discussed in various places, we want to ship Tb w/ calendaring, but won't block Tb3 if it slips.  "We'll ship it when it's ready".
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
Priority: -- → P1
We're shooting for b2, but we'll see!
Target Milestone: --- → Thunderbird 3.0b2
Depends on: 460263
No longer depends on: 460263
Target Milestone: Thunderbird 3.0b1 → ---
I somehow accidentally turned off   "Target Milestone  	Thunderbird 3.0b1" , and now can't put it back.
Target Milestone: --- → Thunderbird 3.0b1
For reference, I added Bug 516026 - Ship SeaMonkey with integrated Lightning on as default
(In reply to comment #11)
> Given that other components/extensions may follow Lightning in being bundled
> into the Thunderbird installer, this should be done in the "best" way here to
> have a generic model. Installing all components first and then just allow to
> disable them implies carrying around unnecessary overhead. Also, if - for
> whatever reason they may have - somebody wants to install his or her own
> preferred calendar extension, those potentially interfere with each other.
> 
> A simple additional dialog in the installer
> 
>  [x] Install mail/news and calendar
>  [ ] Install mail/news only
> 
> could be extended to the commonly found two-step dialog
> 
>  [x] Complete install
>  [ ] Custom install
>  [ ] Install mail/news only
> 
> if additional components/extensions should be included later.

If there isn't already a bug for this, could you please create it? Thanks.
(In reply to comment #25)
> (In reply to comment #11)
> > Given that other components/extensions may follow Lightning in being bundled
> > into the Thunderbird installer, this should be done in the "best" way here to
> > have a generic model. Installing all components first and then just allow to
> > disable them implies carrying around unnecessary overhead. Also, if - for
> > whatever reason they may have - somebody wants to install his or her own
> > preferred calendar extension, those potentially interfere with each other.
...
> If there isn't already a bug for this, could you please create it? Thanks.

There is no need for a separate bug at this time. When this bug gets implemented I'm sure we'll be looking at the appropriate decisions. However, until this bug is fixed there is absolutely no point in having a separate bug on something that we haven't looked at how to implement yet.
Can someone please change the target milestone, since that has now passed? Thanks.
Target Milestone: Thunderbird 3.0b1 → ---
Priority: P1 → --
I see you changed the target milestone, but isn't it supposed to be some future milestone now? Also, I see you changed the priority. Lightning is no longer a priority at all? Sure, I can see it changing from #1 to #2 maybe, but this is not exactly an unrequested, "backburner" issue. Thanks.
Keywords: helpwanted
Keywords: helpwanted
Target Milestone: --- → Future
Summary: Ship Thunderbird with integrated Lightning on as default → Integrate Lightning Into Thunderbird by Default and Ship Thunderbird with Lightning Enabled
One of the prerequisites for Lightning being built into Thunderbird is a steady number of regular contributors. Users expect a certain amount of stability regarding Thunderbird, so Lightning needs to keep up with this level for integration to happen.

This again means that each area of Lightning needs a strong module owner and performance and stability need to be on a similar Level. There are quite a few things we still need to work on and we need a lot more contributors to make sure things progress faster. I'm sorry this isn't going to happen as fast as you'd expect.
Me too...

Can the extension be built with Thunderbird OPTIONALLY for the time being? People downloading pre-built Thunderbird can still add Lightning as an extension.

But those building from source should be able to turn on something like --enable-lightning and get the extension built along with the rest of the application.

For those of us on "exotic" platforms (like FreeBSD), this is especially important because the extension is not available for download for us... Building it from source is possible, but involves rebuilding most of the comm-tree -- a serious waste of human and CPU time...
(In reply to comment #30)
> But those building from source should be able to turn on something like
> --enable-lightning and get the extension built along with the rest of the
> application.
You mean like in https://developer.mozilla.org/En/Simple_Thunderbird_build#Building_Thunderbird_and_Lightning ?
Why, yes, indeed, this seems like it! Testing it right now...
In the rapid release world, I'd suggest to build and ship at least the binary components of Lightning with Thunderbird. Maintaining a js-only extension is much less of a burden: it doesn't break with every single version; in the best case, it simply needs a version bump on amo, which is (or could be) done automatically.

On my Windows system, Lightning takes 4.38 MB, whereas the binary component calbasecomps.dll merely takes 220 KB.
Having Thunderbird automatically update to version 7 just killed my calendar. Having calendar as part of the base build would have eliminated this problem. Now I have to go back, and uninstall Thunderbird completely, and install version 5 or 6, and tell it not to update itself so my calendar will remain working. Please consider fixing this bug.
Worcester12345: We know about this bug, we will consider it when ready, but now is not yet the time.Please stop commenting everywhere about it, it only serves to waste our time and is contrary to the etiquette:

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Thunderbird 7 is on beta channel, which is why we're comfortable with releasing it there without Lightning; if it was a final release we wouldn't do so. However, we are working together to fix the problems with the automation, and make it easier to release Lightning. I would expect that by the time we get to the beta for 8, or definitely 9 at the outside, we'll be able to release compatible versions for Lightning at the same time.
(In reply to Mark Banner (:standard8) from comment #35)
> Worcester12345: We know about this bug, we will consider it when ready, but
> now is not yet the time.Please stop commenting everywhere about it, it only
> serves to waste our time and is contrary to the etiquette:
> 
> https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
> 
> Thunderbird 7 is on beta channel, which is why we're comfortable with
> releasing it there without Lightning; if it was a final release we wouldn't
> do so. However, we are working together to fix the problems with the
> automation, and make it easier to release Lightning. I would expect that by
> the time we get to the beta for 8, or definitely 9 at the outside, we'll be
> able to release compatible versions for Lightning at the same time.

Yes, but the missed point is that there would be an ENTIRE LAYER of this overhead eliminated by integrating the calendar, allowing developers to focus on the end product, not release coordination and compatibility. Thanks for the chance to clarify.
(In reply to Worcester12345 from comment #36)
> Yes, but the missed point is that there would be an ENTIRE LAYER of this
> overhead eliminated by integrating the calendar, allowing developers to
> focus on the end product, not release coordination and compatibility. Thanks
> for the chance to clarify.

Whether or not that would be reduced, it is not our policy at this moment in time. It may change in the future, but we're not at that point yet as already explained in comments earlier in this bug.
Target Milestone: Thunderbird 11.0 → ---

This is a great suggestion!

Today's releases of TB 12.0a1 and Lightning 1.4a1 are not compatible.


Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120106 Thunderbird/12.0a1 ID:20120106030028
…and the Lighting version compatible with TB's current beta was releases 2 weeks later, that's unacceptable for someone who is willing to use the beta version but is also dependent on the Lightning extension.
I do depend on Lightning for my schedule but I'm not going to come down that **** Mozilla. We people that use pre-release versions should expect issues to arise. It's up to us to find issues for them to fix so everything works properly in the official releases. I submit bugs and work with them to fix the bugs. I find that the Mozilla folks work very hard to fix problems as fast as they can.
Lightning is now working on my computer.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120106 Thunderbird/12.0a1 ID:20120106030028
(In reply to [Baboo] from comment #39)
> …and the Lighting version compatible with TB's current beta was releases 2
> weeks later, that's unacceptable for someone who is willing to use the beta
> version but is also dependent on the Lightning extension.

Please discuss on the forums, this is not appropriate for bugs and IMO it is not a reason to implement this bug as you are working with pre-release versions. Note it was already mentioned on the mozilla.dev.apps.calendar forum that holidays over Christmas were the issue and it shouldn't happen in future.
dascher: 	wanted-thunderbird3


Can we get this changed to 13?
Depends on: 322522
All the dependent bugs are fix, is it worth keeping this meta bug ?
(In reply to Ludovic Hirlimann [:Usul] from comment #44)
> All the dependent bugs are fix, is it worth keeping this meta bug ?

Only if Lightning is shipped by default with TB!
(In reply to Ludovic Hirlimann [:Usul] (away until August 5th) from comment #44)
> All the dependent bugs are fix, is it worth keeping this meta bug ?

(In reply to Brian King (Briks) [:kinger] from comment #45)
> (In reply to Ludovic Hirlimann [:Usul] from comment #44)
> > All the dependent bugs are fix, is it worth keeping this meta bug ?
> 
> Only if Lightning is shipped by default with TB!

At this point then, it is only a matter of holding a meeting to decide whether this is something we want to do (It is!), and then implement it.  Could someone please try this in a test environment?
Cannot find a version of Lightning which works with this version of Thunderbird:
Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/18.0 Thunderbird/18.0a1 ID:20120928033359
Severity: normal → major
Severity: major → normal
(In reply to Worcester12345 from comment #47)
> Cannot find a version of Lightning which works with this version of
> Thunderbird:
> Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/18.0 Thunderbird/18.0a1
> ID:20120928033359

1. lightning is an extension and so it's lack of availability isn't a "bug" for proper thunderbird functionality => ENH
2. this isn't the proper venue ask that lightning be updated for trunk builds
3. please don't spam the bug - even if you authored the bug it's bad bug etiquette
Severity: normal → enhancement
Lightning nightly test builds can be found in the usual place where they have been for the last years. It is interesting that you can find a Thunderbird comm-central nightly build but not a Lightning comm-central nightly build. For always up-to-date information see https://developer.mozilla.org/en-US/docs/Calendar/Calendar_Versions#Development_Snapshots
(In reply to Wayne Mery (:wsmwk) from comment #48)
> 1. lightning is an extension and so it's lack of availability isn't a "bug"
> for proper thunderbird functionality => ENH

This bug was about turning it from an extension into the actual product.

I am currently on Thunderbird 17, and was thinking of going to try out the Beta version 19, but I see a lot of complaints on https://addons.mozilla.org/en-US/thunderbird/addon/lightning/reviews/ about the versions not being in sync, again.  Having one less tree of code to maintain I would think make everyone's life easier in the end, on top of getting rid of the extraneous stuff to make the extension itself, and all the time overhead to keep it all working. 

I am hoping to see a synced up "version pair" come out again, until this bug gets fixed. Otherwise, one less Beta tester here.
Are there any plans to include Lighting as optional checkbox into the Thunderbird installer?
(In reply to Norbert from comment #51)
> Are there any plans to include Lighting as optional checkbox into the
> Thunderbird installer?

no (isn't it obvious?)


(In reply to Worcester12345 from comment #50)
> (In reply to Wayne Mery (:wsmwk) from comment #48)
> > 1. lightning is an extension and so it's lack of availability isn't a "bug"
> > for proper thunderbird functionality => ENH
> 
> This bug was about turning it from an extension into the actual product.
>
> I am currently on Thunderbird 17, and was thinking of going to try out the
> Beta version 19, but I see a lot of complaints on
> https://addons.mozilla.org/en-US/thunderbird/addon/lightning/reviews/ about
> the versions not being in sync, again.  Having one less tree of code to
> maintain I would think make everyone's life easier in the end, on top of
> getting rid of the extraneous stuff to make the extension itself, and all
> the time overhead to keep it all working. 

lightning is now being built along side thunderbird, so lightning updates should no be much less of an issue. And when lightning is fully js it should no longer be an issue.

> I am hoping to see a synced up "version pair" come out again, until this bug
> gets fixed. Otherwise, one less Beta tester here.

If what you are waiting on is "integration" then strap yourself in for a very long wait - there is no momentum nor enthusiasm amongst the thunderbird team to do this. 

If however your major reason for wanting this (integration bug) is more timely updates of lightning to various thunderbird updates and channels, then everyone's time and assistance (including users) is better spent helping improve and test those very things - which shockingly enough will be happening in beta, earlybird and daily, and NOT on release builds.  That work is occurring in areas such as  https://bugzilla.mozilla.org/buglist.cgi?f1=OP&o3=anywordssubstr&list_id=8653977&resolution=---&classification=Client%20Software&classification=Components&o2=anywordssubstr&f4=CP&query_format=advanced&j1=OR&f3=keywords&f2=short_desc&component=ICAL.js%20Integration&product=Calendar

In other words, making timely updates of lightning does not depend on this bug.  Indeed, this bug not sufficient to make that happen.


Removing calendar-integration because I don't think this bug meets the intent of calendar-integration keyword, which is "Used for Thunderbird bugs that would have benefit for calendar (i.e., adding ids, great features that would improve user experience)". But it would be great for everyone to identify/create/fix more bugs that meet that criteria so that the calendar experience is improved. Current bug list https://bugzilla.mozilla.org/buglist.cgi?keywords=calendar-integration
Whiteboard: [not currently planned]
Looking at bugs like Bug 733039 - Thunderbird is very slow when Lightning enabled , one can only wonder if they were better integrated, that this sort of problem would not exist at all.
(In reply to Worcester12345 from comment #53)
> Looking at bugs like Bug 733039 - Thunderbird is very slow when Lightning
> enabled , one can only wonder if they were better integrated, that this sort
> of problem would not exist at all.

Look, I know you really want someone to fix this bug, but let's not make spurious claims in support of doing so. The extension points that Lightning uses aren't especially performance-intensive, and in fact, the slow startup of Lightning is a reason to *delay* work on this bug, not to prioritize it. It would be a pretty bad move to ship Lightning to all users and slow everyone's startup when only a fraction of users actually want a calendar!
At the 2014 Thunderbird Toronto Summit, we discussed this issue and decided that we would attempt to ship Thunderbird 38 with Lightning as an included extension, but disabled by default.

To the issue in comment 29, the general feeling was that Lightning is not any different than the rest of Thunderbird at the moment.

Concerns about slowdown on startup may be real, but this is a disabled extension by default, so the issues are no different than they would be if someone chooses to install the extension, as a large number of Thunderbird users choose to do.
Keywords: feature
Whiteboard: [not currently planned]
(In reply to Kent James (:rkent) from comment #55)
> Concerns about slowdown on startup may be real, but this is a disabled
> extension by default, so the issues are no different than they would be if
> someone chooses to install the extension, as a large number of Thunderbird
> users choose to do.

just to clarify, that the summary of this bug report (by the author as of 2010-09-30 12:41:28 PDT) explicitly states "Lightning Enabled". If that's not what we are doing in 38 then perhaps we need a different bug report
That is true. (In reply to Wayne Mery (:wsmwk) from comment #56)
> (In reply to Kent James (:rkent) from comment #55)
> 
> just to clarify, that the summary of this bug report (by the author as of
> 2010-09-30 12:41:28 PDT) explicitly states "Lightning Enabled". If that's
> not what we are doing in 38 then perhaps we need a different bug report

That is true. But at this point, the option is either WONTFIX this bug for that reason, or "clarify" it to shipping disabled. If the OP or commenters object to my clarification, then I can go down the WONTFIX route. But methinks the more correct path is to morph this bug, and after Lightning is shipping disabled, if people feel strongly ask that it be shipped enabled. According to the current majority opinion, it is not going to be shipped enabled at the moment.
(In reply to Kent James (:rkent) from comment #57)
> That is true. (In reply to Wayne Mery (:wsmwk) from comment #56)
> > (In reply to Kent James (:rkent) from comment #55)
> > 
> > just to clarify, that the summary of this bug report (by the author as of
> > 2010-09-30 12:41:28 PDT) explicitly states "Lightning Enabled". If that's
> > not what we are doing in 38 then perhaps we need a different bug report
> 
> That is true. But at this point, the option is either WONTFIX this bug for
> that reason, or "clarify" it to shipping disabled. If the OP or commenters
> object to my clarification, then I can go down the WONTFIX route. But
> methinks the more correct path is to morph this bug, and after Lightning is
> shipping disabled, if people feel strongly ask that it be shipped enabled.
> According to the current majority opinion, it is not going to be shipped
> enabled at the moment.

I suggest creating a new bug, with shipping the extension, but disabled. That is a step toward fixing this bug, which is the ultimate goal here. This bug (401779) will depend on that bug getting fixed first. Once that code is in, then it is a matter of picking the right timing to turn it on by default. I would be OK if there were a checkbox at installation time, to turn it on or not. This might then also lead to the various "import" options to grab a current calendar to bring in.
Depends on: 1113183
Removing "feature" keyword, as that is currently used to flag bugs that we are targeting for the Thunderbird 38 release.
Keywords: feature
As I said in comment 57, we have looked over the request of this bug, and decided that the correct current approach is to NOT ship with Lightning enabled, ie WONTFIX. Rather than keep this bug open, I'm changing the status.

This does not mean that at some point in the future we might not reconsider, but there is no concrete action we want to take on this bug now, and we would not accept patches that fulfilled the request of this bug at this point in time.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Just a note that a LOT of the work to make this possible has now happened. 

Please reconsider this bug.
It was in fact decided to ship with lightning enabled by default for tb38 (barring any technical problems).
(In reply to Magnus Melin from comment #62)
> It was in fact decided to ship with lightning enabled by default for tb38
> (barring any technical problems).

So, was this bug totally forgotten?

Should this bug then be changed to "FIXED"?
Just a technicality, the status on this bug won't impact the feature. We ended up shipping with it enabled, and a notification bar to disable it. Work has been done in other bugs.
Resolution: WONTFIX → FIXED
What is the status of this now, in light of:
Thunderbird 52 and binary extensions
https://mail.mozilla.org/pipermail/tb-planning/2016-November/004964.html
"For a long time now, we have planned to stop supporting binary
extensions in Thunderbird 52. Binary extensions have been disabled in
Firefox for awhile now, and it has become increasingly untenable to
maintain that capability in Thunderbird.
..."

It is now IMPERATIVE that this not only be fully incorporated into the product, but remove all vestiges of it being an extension. Is there already a bug for that? If so, what one?
We've fixed the binary component situation in bug 1318258
Lightning disappeared in this version:
52.0b4 (32-bit)

Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Thunderbird/52.0 ID:20170223185626
Please don't post duplicate comments and open a new bug as mentioned in the other bug.
ere is the new, still UNRESOLVED bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1346794
Depends on: 1406499
No longer depends on: 1406499
(In reply to Mark Banner (:standard8) from comment #37)
> (In reply to Worcester12345 from comment #36)
> > Yes, but the missed point is that there would be an ENTIRE LAYER of this
> > overhead eliminated by integrating the calendar, allowing developers to
> > focus on the end product, not release coordination and compatibility. Thanks
> > for the chance to clarify.
> 
> Whether or not that would be reduced, it is not our policy at this moment in
> time. It may change in the future, but we're not at that point yet as
> already explained in comments earlier in this bug.

Well, several years have now passed. Can we revisit this thought?





(In reply to Jim Porter (:squib) from comment #54)
> uses aren't especially performance-intensive, and in fact, the slow startup
> of Lightning is a reason to *delay* work on this bug, not to prioritize it.
> It would be a pretty bad move to ship Lightning to all users and slow
> everyone's startup when only a fraction of users actually want a calendar!

Right now, it is slow anyhow, and Lightning is not working. Now is a GREAT TIME to move forward with merging this into the main product, and then move on without looking back. Your claim that a fraction want a calendar is completely off. Almost EVERYBODY wants a calendar nowadays. Right now, there is no working calendar in Thunderbird nightly. Opportunity.


(In reply to Kent James (:rkent) from comment #60)
> This does not mean that at some point in the future we might not reconsider,

"The future" is now.
You need to log in before you can comment on or make changes to this bug.