866903 - Investigate removing calendar/sunbird/

Status: RESOLVED FIXED

(MailNews Core :: Build Config, defect)

Description

[Michael Shal [:mshal]]

While porting CPPSRCS to moz.build in comm-central, I noticed that the definition in calendar/sunbird/app/Makefile.in contains:

CPPSRCS         += $(STATIC_CPPSRCS)

Apparently STATIC_CPPSRCS was defined in static-config.mk, but that file was removed in 2011. From an IRC discussion with Callek/jcranmer, it sounds like the whole calendar/sunbird directory is obsolete and can be removed. If not, we should at least remove the obsolete Makefile.in statements that rely on static-config.mk to avoid further porting issues.

Comment 1

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.11pre) Gecko/20100526 Calendar/1.0b2pre

This is IIUC the last L32 build of Sunbird which was made available on the Mozilla FTP servers. I'm still using it as a fallback against a malfunction of Lightning but I know it won't be updated. Building for W32 and Mac ceased within a few days before and after that.

There have been halfhearted amateurish attempts by one SeaMonkey developer (who was it again? ewong? mcsmurf?) to build SeaMonkey at a later date, but with no definite success.

FWIW, I think Sunbird (the _freestanding_ Calendar application) can be regarded as having been at EOL for about 3 years. The Calendar team is very small and there is no visible hope of reviving that application at any foreseeable future time. Maybe the Sunbird-only source files not required by lightning.xpi or gdata-provider.xpi for any platform can be moved to some archive location.

Comment 2

[Tony Mechelynck [:tonymec]]

s/to build SeaMonkey/to build Sunbird/   …of course. It was a SeaMonkey developer who did it.

Comment 3

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I'd prefer to just remove the obsolete preferences. I could also live with removing the Makefiles. I'd like to keep calendar/sunbird around for archival purposes at least.

Stefan, what do you think?

Comment 4

[Mark Banner (:standard8)]

(In reply to Philipp Kewisch [:Fallen] from comment #3)
> I'd prefer to just remove the obsolete preferences. I could also live with
> removing the Makefiles. I'd like to keep calendar/sunbird around for
> archival purposes at least.

Well, it would be "archived" in hg history of course... (you could maybe tag as well).

Comment 5

[Stefan Sitter [:ssitter]]

I no longer care about Sunbird. About half a year ago Jonah Karau wrote in mozilla.dev.apps.calendar that he is working on reviving Sunbird. Have not read any new information since than. 

If you are going to remove calendar/sunbird ensure that you don't remove files that are still in use. For example calendar/sunbird/config/version.txt but there might be other files. 

In addition you could look into cleaning related directories like calendar/installer or other-licenses/branding/sunbird. And don't forget to remove e.g. --enable-application=calendar and other Sunbird related options.

Comment 6

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

In that case, lets do it. I'd appreciate a tag though, just for reference.

Comment 7

[Joshua Cranmer [:jcranmer]]

Lightning uses calendar/sunbird/config/version.txt for its version. I could move it somewhere else, but that might muck up release engineering. Grepping for sunbird in the codebase appears to show no other files used:
<http://mxr.mozilla.org/comm-central/search?string=sunbird>

Thus, my plan is to remove:
calendar/sunbird [except config/version.txt],
calendar/installer
calendar/{app.mozbuild, app-config.mk, build.mk, confvars.sh}
other-licenses/branding/sunbird
every mention of MOZ_SUNBIRD in the files that remain (calendar/moz.build, calendar/locales/Makefile.in, calendar/lightning/Makefile.in)

I think calendar/locales/en-US/{chrome/sunbird, installer, updater} can be removed, but l10n is so far removed from my area of expertise that I'm not going to try unless I'm told to.

I'm also going to post to m.d.a.calendar about the removal; if I hear no objections there, I'll try to push the removal at the end of this week or thereabouts.

Comment 8

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

(In reply to Joshua Cranmer [:jcranmer] from comment #7)
> Lightning uses calendar/sunbird/config/version.txt for its version. I could
> move it somewhere else, but that might muck up release engineering. Grepping
> for sunbird in the codebase appears to show no other files used:
> <http://mxr.mozilla.org/comm-central/search?string=sunbird>
I think we should be fine as long as any makefile that needs the lightning version is adapted. releng just does --enable-calendar.

> I think calendar/locales/en-US/{chrome/sunbird, installer, updater} can be
> removed, but l10n is so far removed from my area of expertise that I'm not
> going to try unless I'm told to.
I also think these can go. Please file a followup bug if you don't take care here. It might not be that bad to do this in the next cycle so that the string "changes" are not required for the upcoming ESR.

> I'm also going to post to m.d.a.calendar about the removal; if I hear no
> objections there, I'll try to push the removal at the end of this week or
> thereabouts.
Thanks for taking care of this! If you decide to do l10n, please also notify m.d.l10n.

Comment 9

[Joshua Cranmer [:jcranmer]]

Attachment: Removal

Something like this, I think. Including the commit message.

Comment 10

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 754575 [details] [diff] [review]
Removal

Review of attachment 754575 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me, r=philipp

We can probably clean up some things in the calendar/locales/Makefile.in, but I'd be fine with doing that in the l10n bug.

Comment 11

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I've just taken a look at the removals itself, I didn't actually apply this. What about version.txt and such?

Comment 12

[Joshua Cranmer [:jcranmer]]

(In reply to Philipp Kewisch [:Fallen] from comment #11)
> I've just taken a look at the removals itself, I didn't actually apply this.
> What about version.txt and such?

I'm keeping version.txt where it is for now, since I don't want to mess up anyone's release scripts.

Comment 13

[Joshua Cranmer [:jcranmer]]

Pushed:
https://hg.mozilla.org/comm-central/rev/f2e605ee5475