Abandon the calendar extension
Simon Paquet
Hi guys,
since a few people are now making an effort to discuss more publicly
about stuff that has only been discussed via mail or IRC in the past,
I'll try to follow this effort.
Before I start, let me state, that everything in this post is just my
personal opinion and not necessarily the opinion of the other calendar
developers or the project as a whole. I would also advise everyone to
keep this a civil discussion and not start a flamewar here.
Okay, now it is my opinion that we should seriously consider to abandon
the development of the calendar extension for Firefox, Thunderbird and
Seamonkey and just concentrate on Lightning and Sunbird in the future.
My reasons for this are as follows:
- No active calendar developer currently works on the calendar
extension or is interested in devoting his time to the extension.
- Although requests have been made by the current calendar developers,
nobody has stepped forward and offered to actively maintain the
calendar extension.
- While the extension gets all the features and bugfixes that Sunbird
gets, no effort is made from the developer side to actively test it,
which means that nobody really knows what the current state of the
extension really is.
- Actively maintaining the extension would mean a much more complex
testing matrix for the calendar developers. Currently we have to
test code checkins on our three major platforms (Windows, Linux, Mac)
for Lightning and Sunbird. Testing the calendar extension would
mean testing on all three platforms for all three products (Firefox,
Thunderbird, Seamonkey). This means 9 additional combinations have
to be tested.
- Lightning is the superior product in terms of functionality and is
already available for Thunderbird. In the future it may be made
available for Firefox. If Seamonkey finally manages to move to the
new toolkit code, Lightning can be easily be ported to Seamonkey.
- The calendar extension hasn't been actively maintained for months.
IMO it is better and much more credible to openly say that this is
not gonna change, than to keep it in this state of limbo in the
coming months and still have users who are waiting for an update,
which may never appear.
I would be interested in hearing your thoughts on that.
--
Simon Paquet
Sunbird/Calendar/Lightning website maintainer
http://www.mozilla.org/projects/calendar
zeddock
-zeddock
Let's see where this goes....
zeddock
-zeddock
Bob Burns
stand alone, as long as it works.
--
--------------------
"Every day is Saturday when you're retired."
Bob Burns
Mill Hall PA
Joey Minta
this stage, however, I don't think we're quite to a point where we can
abandon it. There are two reasons: Firefox and SeaMonkey. I spent a
few days at one point playing around with getting Lightning to work in
Firefox in a clean, out-of-the-box way. Although I made some progress,
there were still significant technical obstacles to making this work
reliably. Until we're sure that we have a replacement calendar project
for Firefox (and SeaMonkey?), or at least that we know what the
replacement looks like and when it will arrive, I tend to think we
should keep the calendar project in it's current state of limbo.
Perhaps next week's status meeting will shed more light on the above
question, though and make the status of the calendar xpi more clear.
Either way, it seems to me that a discussion on browser-calendaring
(supplamental to the one on the Calendar blog) needs to precede any
decision on the calendar xpi's status.
-Joey
Peter Weilbacher
> - No active calendar developer currently works on the calendar
> extension or is interested in devoting his time to the extension.
> - Although requests have been made by the current calendar developers,
> nobody has stepped forward and offered to actively maintain the
> calendar extension.
Let me call it CalExt for short.
Could this not continue similar to tier-2 platforms, where fixes are
done by voluteers when necessary? The OS/2 platform still works like
that. It's a bit "dangerous" but until now it works quite well (about 3
people contribute actively with a small (<10) community of active testers).
I don't see why that shouldn't work for the much smaller calendar
codebase, especially as most (all?) of the changes would be almost
identical for Sunbird and CalExt.
> - While the extension gets all the features and bugfixes that Sunbird
> gets, no effort is made from the developer side to actively test it,
> which means that nobody really knows what the current state of the
> extension really is.
Now that I finally got it to build for OS/2 (last weekend), it seems to
work fine for SeaMonkey. So I don't really see the point of officially
abandoning it now. That said, although I have contributed some very
minor patches I am not familiar with the code nor existing known bugs.
The one problem that got noticed is that although localizations exist,
not all of them are up to date, or they are updated but not in the CVS
tree. If I understood KaiRo correctly this is at least partly due to
restrictions that you Calendar guys have for l10n checkins.
> - Actively maintaining the extension would mean a much more complex
> testing matrix for the calendar developers. Currently we have to
> test code checkins on our three major platforms (Windows, Linux, Mac)
> for Lightning and Sunbird. Testing the calendar extension would
> mean testing on all three platforms for all three products (Firefox,
> Thunderbird, Seamonkey). This means 9 additional combinations have
> to be tested.
See below, I agree to reduce this to 3 combinations (CalExt on
SeaMonkey, 4 if OS/2 is included), once I can get my Evolution calendar
imported, I will be able to more actively test on Linux and OS/2 and do
bug triaging.
Is there a testing framework for Sunbird that you follow regularly or at
least before releases and that could be adopted for CalExt?
> - Lightning is the superior product in terms of functionality and is
> already available for Thunderbird. In the future it may be made
> available for Firefox. If Seamonkey finally manages to move to the
> new toolkit code, Lightning can be easily be ported to Seamonkey.
When Lightning reaches a state when the release notes do not state that
dataloss is to be expected _and_ it works as extension to a SeaMonkey
release then it might be a time to totally abandon CalExt.
> - The calendar extension hasn't been actively maintained for months.
Just yesterday mostafah checked in a small patch for me. :-) (OK, I
agree, that isn't active maintenance.)
> IMO it is better and much more credible to openly say that this is
> not gonna change, than to keep it in this state of limbo in the
> coming months and still have users who are waiting for an update,
> which may never appear.
All users who previously used CalExt in the Mozilla 1.7.x suite deserve
that we at least keep it updated until there is a real integrated
alternative. Even in the small OS/2 community there was quite a demand
for that.
I would agree to abandon it for Firefox and Thunderbird, though. For
users of those apps Sunbird should be a viable alternative.
Peter.
Joey Minta
difficulties encountered in developing both "calExt" and Sunbird:
https://bugzilla.mozilla.org/show_bug.cgi?id=306079
https://bugzilla.mozilla.org/show_bug.cgi?id=330716
https://bugzilla.mozilla.org/show_bug.cgi?id=325660
Peter Weilbacher wrote:
> The one problem that got noticed is that although localizations exist,
> not all of them are up to date, or they are updated but not in the CVS
> tree. If I understood KaiRo correctly this is at least partly due to
> restrictions that you Calendar guys have for l10n checkins.
KaiRo and others have done some great work on helping us get the l10n
situation fixed. We asked them to hold off making more changes until
Lightning 0.1 was released.
> Is there a testing framework for Sunbird that you follow regularly or at
> least before releases and that could be adopted for CalExt?
Not particularly. There is http://wiki.mozilla.org/Calendar:Tests but
that's not much. Mostly we rely on the fairly heavy use that nightly
builds get and the theory that enough eyes will spot most bugs.
>
>> - Lightning is the superior product in terms of functionality and is
>> already available for Thunderbird. In the future it may be made
>> available for Firefox. If Seamonkey finally manages to move to the
>> new toolkit code, Lightning can be easily be ported to Seamonkey.
>
> When Lightning reaches a state when the release notes do not state that
> dataloss is to be expected _and_ it works as extension to a SeaMonkey
> release then it might be a time to totally abandon CalExt.
The important thing that I don't think enough people realize is that (1)
Current trunk Calendar, because it shares the same codebase, has the
same dataloss bugs and (2) "calExt v0.2" has, in my opinion, more
dataloss bugs than Lightning 0.1. The Lightning 0.1 was just much more
up front about them. At this stage of development, I would definitely
trust my data to Lightning over any older version of CalExt.
>
>> - The calendar extension hasn't been actively maintained for months.
>
> Just yesterday mostafah checked in a small patch for me. :-) (OK, I
> agree, that isn't active maintenance.)
Thanks for that, by the way!
-Joey
Jeff Beal
First off, I've been using the Calendar Extension for SeaMonkey, and I
like having it. I like having my browser, my mail client, and my
calendar all start up at once and all be in the same space on my Windows
taskbar.
Regarding Lightning, I would much rather use that than the Calendar
Extension, but I'm not willing to abandon SeaMonkey to do so. Once it
gets ported to SeaMonkey, I'm fully in support of killing the extension
once and for all.
In the meantime, if you want to sign me up for testing the extension on
the SeaMonkey/Windows XP portion of the matrix, go ahead (1 down, 8 to
go). I won't be able to promise much in terms of time, but if that's
what it takes for me to have an updated calendar for SeaMonkey, I'm all
for it.
--
Jeff Beal
Simon Paquet
>> - No active calendar developer currently works on the calendar
>> extension or is interested in devoting his time to the extension.
>> - Although requests have been made by the current calendar
>> developers, nobody has stepped forward and offered to actively
>> maintain the calendar extension.
>
> Let me call it CalExt for short.
>
> Could this not continue similar to tier-2 platforms, where fixes are
> done by voluteers when necessary? The OS/2 platform still works like
> that. It's a bit "dangerous" but until now it works quite well
> (about 3 people contribute actively with a small (<10) community of
> active testers).
Yes, this could continue, *if* we had such a small, but active
community doing the maintenance. The fact, that we do not have it,
leads me to the conclusion that it is better to abandon CalExt.
> The one problem that got noticed is that although localizations
> exist, not all of them are up to date, or they are updated but
> not in the CVS tree. If I understood KaiRo correctly this is at
> least partly due to restrictions that you Calendar guys have for
> l10n checkins.
Yes, this is a problem. I wonder if we do not need a person, who is
the single point of contact for the l10n community. Perhaps I should
volunteer for that job, now that Mostafah lacks the time to do this
task.
>> - Actively maintaining the extension would mean a much more
>> complex testing matrix for the calendar developers. Currently
>> we have to test code checkins on our three major platforms
>> (Windows, Linux, Mac) for Lightning and Sunbird. Testing the
>> calendar extension would mean testing on all three platforms
>> for all three products (Firefox, Thunderbird, Seamonkey). This
>> means 9 additional combinations have to be tested.
>
> See below, I agree to reduce this to 3 combinations (CalExt on
> SeaMonkey, 4 if OS/2 is included), once I can get my Evolution
> calendar imported, I will be able to more actively test on Linux
> and OS/2 and do bug triaging.
I would really favour it, if Seamonkey could make significant strides
toward the new toolkit migration. Then work could be done on getting
Lightning to work on Seamonkey.
> Is there a testing framework for Sunbird that you follow regularly
> or at least before releases and that could be adopted for CalExt?
We have http://wiki.mozilla.org/Calendar:Tests
>> - Lightning is the superior product in terms of functionality and
>> is already available for Thunderbird. In the future it may be
>> made available for Firefox. If Seamonkey finally manages to move
>> to the new toolkit code, Lightning can be easily be ported to
>> Seamonkey.
>
> When Lightning reaches a state when the release notes do not state
> that dataloss is to be expected _and_ it works as extension to a
> SeaMonkey release then it might be a time to totally abandon CalExt.
You might not be aware of it, but CalExt has exactly the same
dataloss bugs that Lightning has, due to their identical back-end.
>> IMO it is better and much more credible to openly say that this
>> is not gonna change, than to keep it in this state of limbo in
>> the coming months and still have users who are waiting for an
>> update, which may never appear.
>
> All users who previously used CalExt in the Mozilla 1.7.x suite
> deserve that we at least keep it updated until there is a real
> integrated alternative. Even in the small OS/2 community there
> was quite a demand for that.
I know that they deserve it. But this is Open-Source software. It only
works if someone works on it. And if such a person is not available,
the product dies. That's exactly the same as with the Mac Classic
support that was ended in 2002 for Mozilla products.
--
Simon Paquet
Sunbird/Calendar website maintainer
http://www.mozilla.org/projects/calendar
Simon Paquet
> At this stage, however, I don't think we're quite to a point where we
> can abandon it. There are two reasons: Firefox and SeaMonkey. I spent a
> few days at one point playing around with getting Lightning to work in
> Firefox in a clean, out-of-the-box way. Although I made some progress,
> there were still significant technical obstacles to making this work
> reliably. Until we're sure that we have a replacement calendar project
> for Firefox (and SeaMonkey?), or at least that we know what the
> replacement looks like and when it will arrive, I tend to think we
> should keep the calendar project in it's current state of limbo.
I agree with the Firefox part, if we decide that we want to build
a browser extension. I'm against that, given our resource situation,
as you well know.
I disagree that we should wait until we have a replacement project for
Seamonkey. The Seamonkey bug regarding the move to the new toolkit
(bug 255807) has basically stalled since its inception 19 months ago
and I see no sign from the Seamonkey developers that this will change
in the near future.
Right know I'm thinking that hell will freeze over earlier than
Seamonkey will move to the new toolkit. That's okay, it's the decision
of the Seamonkey developers where they allocate their resources, but
it is also our decision, whether we wait on them or not.
I say: We shouldn't wait any longer.
> Either way, it seems to me that a discussion on browser-calendaring
> (supplamental to the one on the Calendar blog) needs to precede any
> decision on the calendar xpi's status.
Since this is basically the "do we want a calendar extension on
Firefox"-question, I see no relation to the current topic, since this
extension will certainly not be CalExt but Lightning, if we decide to
go that route.
Matthias Bücker
to make things short:
I wouldn't bother about abandoning the calendar extension and I would
like to use lightning instead (you mentioned good reasons for this) just
now.
But unfortunately I am unable to import my calendars (from the calendar
extension) into lightning. As soon as this will be possible I definitely
will make the move!
Best Regards
Matthias
--
----------------------------------------------------------------------------
Dr. rer. pol. Matthias Bücker
mailTo:MatthiasDOTCDOTBueckerATt-onlineDOTde
----------------------------------------------------------------------------
Michiel van Leeuwen
> Okay, now it is my opinion that we should seriously consider to abandon
> the development of the calendar extension for Firefox, Thunderbird and
> Seamonkey and just concentrate on Lightning and Sunbird in the future.
What do you mean with abandoning the development? How is that different
from the current situation? No development is going on. No testing
resources are spend. No builds are made. Pretty much sounds like the
calendar extension is abandoned.
So, what do you want to change?
Michiel
Michiel van Leeuwen
> There are two reasons: Firefox and SeaMonkey.
Why do we have to have a calendaring solution for installation in those
apps? There are two other alternatives. I don't see the need for
spending time on firefox and seamonkey.
Especially not for SeaMonkey. There is hardly any movement there, and
supporting xpfe is getting quite a pain. Let's just stop even trying to
keep things working in there.
Michiel
Joey Minta
>> Either way, it seems to me that a discussion on browser-calendaring
>> (supplamental to the one on the Calendar blog) needs to precede any
>> decision on the calendar xpi's status.
>
> Since this is basically the "do we want a calendar extension on
> Firefox"-question, I see no relation to the current topic, since this
> extension will certainly not be CalExt but Lightning, if we decide to
> go that route.
>
I'm not 100% convinced of this fact. I finally today sat down at a
window's box and played around with the experimental CalExt, however,
and that makes me more convinced that Lightning might be the correct
solution *for now*. (It had the same issue, an undesired closure on the
composite calendar, that Lightning does.) The scary situation is that
the integration hooks planned to link Lightning and Thunderbird will
eventually make this solution impossible. In that case, it may be that
the CalExt framework is a more reasonable solution to work from, rather
than Lightning, and having it 'killed' now would mean more work for
whomever took up that task later.
Joey Minta
> Joey Minta wrote:
>> There are two reasons: Firefox and SeaMonkey.
>
> Why do we have to have a calendaring solution for installation in those
> apps?
potential that users may want it. And because that potential exists, I
don't think we want to hurt our ability to meet that demand (by killing
calendar.xpi) until we're sure we know what we're planning to do about
it. That's why I suggested that the browser-calendaring debate take
place first.
-Joey
Joey Minta
> What do you mean with abandoning the development? How is that different
> from the current situation?
my mind, 'abandoning' would be the equivalent of no longer requiring
that patches even make a token effort at keeping calendar.xpi alive.
We'd probably also restructure the website to make it less prominent and
try to phase out support questions/answers regarding it.
-Joey
Simon Paquet
>> I disagree that we should wait until we have a replacement project
>> for Seamonkey. The Seamonkey bug regarding the move to the new
>> toolkit (bug 255807) has basically stalled since its inception 19
>> months ago and I see no sign from the Seamonkey developers that
>> this will change in the near future.
>
> Did you not read the SeaMonkey wiki page I pointed you to?
Yes, I did. And I see nothing that looks like an actual project plan
there. I see the tasks laid out, but I don't see any sort of milestones,
estimated completion dates, etc.
I also see no public discussion about the move to the new toolkit
anywhere in a public forum, be it the Seamonkey blog or the new
newsgroup.
If I missed something, I would be grateful if someone could point me
to the right place.
>> Right know I'm thinking that hell will freeze over earlier than
>> Seamonkey will move to the new toolkit. That's okay, it's the
>> decision of the Seamonkey developers where they allocate their
>> resources, but it is also our decision, whether we wait on them
>> or not.
>
> Is this really part of the civil discussion that you wanted to have?
Sorry for the little rant. But do you really disagree with me based
on the stuff that is out in the open?
Simon Paquet
> Do you have any download statistics for the nightlies?
Not that I'm aware of, but this is a question that has been bugging
me for months. I should mail preed and ask him if it would be
possible to get some statistics on nightly and release downloads.
>>> Just yesterday mostafah checked in a small patch for me. :-)
>>> (OK, I agree, that isn't active maintenance.)
>>
>> Thanks for that, by the way!
>
> Well, it was a lot more fun than in many other parts of the Mozilla
> tree, where such small patches sit in review queues for up to several
> months, and then take again as long to get checked in. If I had more
> time and had found a way to be a more active user of CalExt I would
> definitely try to contribute more patches. Perhaps that happens in the
> next weeks when I get a bit more time.
Thanks, we appreciate your efforts very much.
Simon Paquet
> Well, AFAIK Adrian was doing Windows builds every now and then,
> I heard about Linux builds from somebody in the German newsgroups
> (Hartmut?). I don't think that they stopped providing them. Of
> course, as none of them is advertised on the Calendar website, so
> very few people find them and and even fewer do some real testing.
>
> If there would be nightly (or at least weekly) builds or regular
> contributed builds that appear on
> <http://www.mozilla.org/projects/calendar/download.html> I am pretty
> sure that testers would be there. Is there any possibility that the
> machines that build one of the other Calendar nightlies could be set
> up so that they produce something like this for the three platforms?
> Any other suggestions?
What I could offer you as a short-term solution would be to put some
links on the CalExt download page that point to these unofficial
builds, if someone could provide me with a comprehensive list of
those sites and the assurance that the person doing these builds
won't stop doing it two weeks after I put the link on the download
page.
>> You might not be aware of it, but CalExt has exactly the same
>> dataloss bugs that Lightning has, due to their identical back-end.
>
> Thanks for pointing that out. That means that, currently, there is
> no Calendar based on Mozilla code in whatever form available that
> is considered stable for daily (or "production") use, right? Hmm,
> Sunbird 0.2?!
There is a CalExt xpi based on the code of Sunbird 0.2 and it is
probably more stable than Lightning 0.1, but as Joey already pointed
out, it has probably many more dataloss bugs than Lt 0.1 and I
wouldn't really trust my data to it if I were you.
Simon Paquet
Pretty much everything that Joey already said plus an official
announcement that we no longer support CalExt to make our users
aware of its status.
Peter Weilbacher
I agree that not much progress is visible from the outside. But those
wiki entries are fairly recent so it's not really stalled.
Perhaps somebody in .seamonkey wants to comment, Xpost there.
Peter.
Stephan Schaefer
> Michiel van Leeuwen wrote:
>> What do you mean with abandoning the development? How is that
>> different from the current situation?
> We currently reject patches that blatantly break the calendar.xpi. In
> my mind, 'abandoning' would be the equivalent of no longer requiring
> that patches even make a token effort at keeping calendar.xpi alive.
That's what I would actually expect. If there are no current builds how
are you going to check if a patch actually breaks CalExt or not ? Are
you sure that other reviewers do it the same way ?
My feeling is that you put an additional burden onto the handful of
Calendar developers which makes contributing more painful than it should
be. Two calendar applications are more than enough.
I strongly suggest following the proposal to abandon the calendar
extension and to refactor the code accordingly by removing CalExt
specific things in order to improve the readability of the code and to
concentrate on more important things. This would be a bigger benefit for
the community than half-heartedly supporting an extension by pretending
that it is still alive.
Stephan
Joey Minta
> Joey Minta wrote:
>> Michiel van Leeuwen wrote:
>>> What do you mean with abandoning the development? How is that
>>> different from the current situation?
>> We currently reject patches that blatantly break the calendar.xpi. In
>> my mind, 'abandoning' would be the equivalent of no longer requiring
>> that patches even make a token effort at keeping calendar.xpi alive.
>
> That's what I would actually expect. If there are no current builds how
> are you going to check if a patch actually breaks CalExt or not ?
> Are
> you sure that other reviewers do it the same way ?
Yes.
>
> My feeling is that you put an additional burden onto the handful of
> Calendar developers which makes contributing more painful than it should
> be. Two calendar applications are more than enough.
I'm not convinced that's true. Leaving Firefox users without a
calendaring extension seems like it would be ignoring a sizable
population of the current calendar userbase.
>
> I strongly suggest following the proposal to abandon the calendar
> extension and to refactor the code accordingly by removing CalExt
> specific things in order to improve the readability of the code and to
> concentrate on more important things. This would be a bigger benefit for
> the community than half-heartedly supporting an extension by pretending
> that it is still alive.
I think QA is a bigger reason to drop CalExt than code-readability. We
have only a few scattered #IFDEFs in the code, and that's it. While
abandoning CalExt would let us CVS-remove some files, I don't think the
files that would remain would be improved significantly.
Johannes Kastl
> There is a CalExt xpi based on the code of Sunbird 0.2 and it is
> probably more stable than Lightning 0.1, but as Joey already pointed
> out, it has probably many more dataloss bugs than Lt 0.1 and I
> wouldn't really trust my data to it if I were you.
AFAIK the "old" code (sunbird 0.2) will not run in SM. At least the
old calendar.xpis will not work.
OJ
--
A bunch of security trolls had been hired to guard her. They paced the
corridor in a menacing group, talking in grunts and comparing the size
of their clubs.
(Harry Potter and the Prisoner of Azkaban)
Michiel van Leeuwen
> We currently reject patches that blatantly break the calendar.xpi.
Is that calendar.xpi in general, or calendar.xpi for seamonkey? I really
don't mind breaking the latter. Keeping calendar.xpi alive for firefox
is a lot less work, because it uses the same toolkit code as sunbird.
That means that we can use the same components etc. In theory, we could
use the same calendar.xul. We don't do that at the moment, which means a
lot more work.
Michiel
Michiel van Leeuwen
> Because users seem to want it. Or, at the very least, because there's a
> potential that users may want it.
I think the most important reason for users to want it to work in
firefox is that it always worked that way. I don't think that's a good
reason. If that is the only reason, we need to convince those users to
switch to some other solution (sunbird or lightning)
(I mean, thunderbird is also not available as an extension to firefox,
while in the past you did have mailnews inside the browser. If the split
worked there, why can't it work for calendar?)
Michiel
Andrew N Dowden
Okay, now it is my opinion that we should seriously consider to abandon
the development of the calendar extension for Firefox, Thunderbird and
Seamonkey and just concentrate on Lightning and Sunbird in the future ..I have been reading the discussion, and found a lot of it useful. There is a need to rationalize, but we don't necessarily know which branch needs to be pruned, and how aggressively.
.. I would be interested in hearing your thoughts on that.
The other factor is the community need over time. Will Seamonkey (tighter integration; 'modules' for browse, email, contact, and calendar) continue to have an audience, or will the standalone style of Firefox, Thunderbird, and Sunbird be augmented by further loosely integrated packages: 'CRM', blog / storage (photos, thoughts, opinion), etc. (all with useful extensions)
-- _______________________________________________ SoftDesign Group Dowden Software Associates P O Box 31 132, Lower Hutt 6315, NEW ZEALAND
Joey Minta
> Joey Minta wrote:
>> We currently reject patches that blatantly break the calendar.xpi.
>
> Is that calendar.xpi in general, or calendar.xpi for seamonkey?
that the status quo has been 'calendar.xpi in general'. It may be that
the outcome of this discussion will be that we kill seamonkey support,
but continue to try to keep firefox minimally alive.
-Joey
Martin Bagge / brother
> I think the most important reason for users to want it to work in
> firefox is that it always worked that way. I don't think that's a good
> reason. If that is the only reason, we need to convince those users to
> switch to some other solution (sunbird or lightning)
I use the extension for Fx daily, more frequent than lightning and the
extensoin från Tb. The main reason for this is that I always have
Firefox running in my computer, Tb is only used for storage and
searching in my mail archives and isn't there when needed. I guess a
good version of Sunbird in apt would be a resonable way for me to
switch, at least I haven't got the time to support the extension in
matters of resources.
> (I mean, thunderbird is also not available as an extension to firefox,
> while in the past you did have mailnews inside the browser. If the split
> worked there, why can't it work for calendar?)
I do miss the Suite, Seamonkey may have me switching back some time, how
knows =)
--
/Martin Bagge
mail: mar...@bagge.nu
PGP: http://martin.bagge.nu/pgp.asc
web: http://martin.bagge.nu
Peter Weilbacher
> Peter Weilbacher wrote on 22. Mar 2006:
>
>>> I disagree that we should wait until we have a replacement project
>>> for Seamonkey. The Seamonkey bug regarding the move to the new
>>> toolkit (bug 255807) has basically stalled since its inception 19
>>> months ago and I see no sign from the Seamonkey developers that
>>> this will change in the near future.
>>
>> Did you not read the SeaMonkey wiki page I pointed you to?
>
> Yes, I did. And I see nothing that looks like an actual project plan
> there. I see the tasks laid out, but I don't see any sort of milestones,
> estimated completion dates, etc.
>
> I also see no public discussion about the move to the new toolkit
> anywhere in a public forum, be it the Seamonkey blog or the new
> newsgroup.
Actually, it was always quite obvious that a SeaMonkey release with new
toolkit would never happen for the 1.8 branches (KaiRo just confirmed
that again in .seamonkey), so no matter how hard the SeaMonkey guys are
working on that the first SeaMonkey _release_ with toolkit will not
happen until mid 2007 or so.
Not sure what that means for CalExt, but a working version until that
release happens would be great...
Peter.
Ricardo Palomares Martinez
>
> Okay, now it is my opinion that we should seriously consider to abandon
> the development of the calendar extension for Firefox, Thunderbird and
> Seamonkey and just concentrate on Lightning and Sunbird in the future.
Now that it has been oficially stated than CalExt is no longer
maintained, this message is of no real use, but anyway...
>
> My reasons for this are as follows:
> (...)
> - Lightning is the superior product in terms of functionality and is
> already available for Thunderbird. In the future it may be made
> available for Firefox. If Seamonkey finally manages to move to the
> new toolkit code, Lightning can be easily be ported to Seamonkey.
The magic word seems to be "Toolkit" in the case of SeaMonkey, but
something else has to exist, as Lightning doesn't run in Firefox,
either. Is it because Firefox doesn't provide mail services?
Going back to SeaMonkey, :-) how tight is the dependency from toolkit
in Lightning? I mean, if someone intends to run Lightning on
SeaMonkey, will he have to modify a 10% of the XUL code? A 50%? Also,
do you think it would also imply to modify C/C++ code?
> - The calendar extension hasn't been actively maintained for months.
> IMO it is better and much more credible to openly say that this is
> not gonna change, than to keep it in this state of limbo in the
> coming months and still have users who are waiting for an update,
> which may never appear.
I can't say anything about Firefox users reasons, but the
disappointment for Mozilla Suite/SeaMonkey (MS/SM) users is that a
calendar extension has never really worked since Mozilla entered into
1.8alfa4 or so. Something (an API, I guess) changed in Mozilla 1.8 and
Calendar stopped working. *Maybe* fixing that would have been easier
at that past moment, and would have provided MS/SM users (and maybe
even Firefox 1.5 users too) an option. Among other things, that would
have provided the Calendar developers team a lot more of peace to
work. :-)
Anyway, that's the past, and that's nothing we can do to change it.
But it has a lot more sense to keep the calendar working in the suite
that in Firefox, because for each component (browser, mail/news,
calendaring) running inside the suite you have one less Gecko (yeah,
yeah, XULRunner, I know; in fact, I know since the original
Phoenix/Firebird/Firefox roadmap was announced, and we're still
waiting). And, while I simpathize with Calendar project, I think that
if, in the long term the proposal is to have either Fx+Sb or SM+Sb, it
may have more sense for SM users to look for another, more-mature,
calendaring options.
Ricardo.
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Simon Paquet
>> Okay, now it is my opinion that we should seriously consider to
>> abandon the development of the calendar extension for Firefox,
>> Thunderbird and Seamonkey and just concentrate on Lightning and
>> Sunbird in the future.
>
> Now that it has been oficially stated than CalExt is no longer
> maintained, this message is of no real use, but anyway...
I dont think that's true. It is true, that the current developers no
longer make a huge effort for CalExt, but they still reject patches
that would break CalExt and also CalExt is still working, when
building from the trunk. So a small effort is still made in maintaining
CalExt.
>> My reasons for this are as follows:
>> (...)
>> - Lightning is the superior product in terms of functionality
>> and is already available for Thunderbird. In the future it may
>> be made available for Firefox. If Seamonkey finally manages to
>> move to the new toolkit code, Lightning can be easily be ported
>> to Seamonkey.
>
> The magic word seems to be "Toolkit" in the case of SeaMonkey, but
> something else has to exist, as Lightning doesn't run in Firefox,
> either. Is it because Firefox doesn't provide mail services?
No. It is because the developers had their hands full with getting
Lightning 0.1 out of the door and that was hard enough for just one
product, so the focus was on Thunderbird.
Is is possible to get Lightning to work on Firefox, as Joey already
said in this thread.
> Going back to SeaMonkey, :-) how tight is the dependency from
> toolkit in Lightning? I mean, if someone intends to run Lightning
> on SeaMonkey, will he have to modify a 10% of the XUL code? A
> 50%? Also, do you think it would also imply to modify C/C++
> code?
As you can see from the provisional patch in Bug 313822 99% of it
is XUL/JS/DTD/CSS code. But as you can also see from this provisional
patch, much of the differing stuff comes from SM's XPFE heritage, e.g.
the additional #ifdef statements or the needed contents.rdf files,
which are no longer needed for Toolkit apps.
> Anyway, that's the past, and that's nothing we can do to change it.
> But it has a lot more sense to keep the calendar working in the
> suite that in Firefox, because for each component (browser,
> mail/news, calendaring) running inside the suite you have one
> less Gecko.
It would definitely make sense to support SM, but since the current
developers are not interested in SM and not credible maintainer has
come forth, there's not much that can be done, really.
My long-term vision for Calendar on Seamonkey would really be a whole
different story. It would be a Calendar app, that is built and shipped
with Seamonkey by default, just like the browser, the mail app, the
web editor and the IRC client.
This would also eliminate the need for regular versions of the calendar
XPI.
Simon Paquet
> Actually, it was always quite obvious that a SeaMonkey release with
> new toolkit would never happen for the 1.8 branches
Sure. I don't think anyone ever expected otherwise.
--
Simon Paquet
Sunbird/Lightning/Calendar website maintainer
http://www.mozilla.org/projects/calendar
Ricardo Palomares Martinez
> Ricardo Palomares Martinez wrote on 24. Mar 2006:
>> Now that it has been oficially stated than CalExt is no longer
>> maintained, this message is of no real use, but anyway...
>
> I dont think that's true.
Maybe I've misunderstood your other message in this thread:
http://groups.google.es/group/mozilla.dev.apps.calendar/msg/fa698298102bee09
You weren't really making such statement, were you?
>> Going back to SeaMonkey, :-) how tight is the dependency from toolkit
>> in Lightning? I mean, if someone intends to run Lightning on
>> SeaMonkey, will he have to modify a 10% of the XUL code? A 50%? Also,
>> do you think it would also imply to modify C/C++ code?
>
> As you can see from the provisional patch in Bug 313822 99% of it
> is XUL/JS/DTD/CSS code. But as you can also see from this provisional
> patch, much of the differing stuff comes from SM's XPFE heritage, e.g.
> the additional #ifdef statements or the needed contents.rdf files,
> which are no longer needed for Toolkit apps.
>
So, as a very first-impression based opinion, do you think that we
could have any chance of being successful if we pick a Lightning XPI,
write an install.js and contents.rdf for it and follow the same
modification pattern than the one showed in the provisional patch?
That could be done out of the CVS, as a community work, that wouldn't
disturb your focus on your development plan.
>
> My long-term vision for Calendar on Seamonkey would really be a whole
> different story. It would be a Calendar app, that is built and shipped
> with Seamonkey by default, just like the browser, the mail app, the
> web editor and the IRC client.
>
> This would also eliminate the need for regular versions of the calendar
> XPI.
I agree that calendaring would be definitely a good component, and
there has been a open bug for a long time now. Still, I think that it
would require an XPI packaging (every component in the SM installer is
prepared that way), although I suppose you mean that it could be done
as part of the build process and not require time on the Calendar
development team to prepare it.
Simon Paquet
>>> Now that it has been oficially stated than CalExt is no longer
>>> maintained, this message is of no real use, but anyway...
>>
>> I dont think that's true.
>
> Maybe I've misunderstood your other message in this thread:
>
> http://groups.google.es/group/mozilla.dev.apps.calendar/msg/fa698298102bee09
>
> You weren't really making such statement, were you?
My statement there was regarding what I think would be the right
thing to do, *if* we say that we abandon CalExt.
>>> Going back to SeaMonkey, :-) how tight is the dependency from
>>> toolkit in Lightning? I mean, if someone intends to run
>>> Lightning on SeaMonkey, will he have to modify a 10% of the
>>> XUL code? A 50%? Also, do you think it would also imply to
>>> modify C/C++ code?
>>
>> As you can see from the provisional patch in Bug 313822 99% of
>> it is XUL/JS/DTD/CSS code. But as you can also see from this
>> provisional patch, much of the differing stuff comes from SM's
>> XPFE heritage, e.g. the additional #ifdef statements or the
>> needed contents.rdf files, which are no longer needed for
>> Toolkit apps.
>
> So, as a very first-impression based opinion, do you think that
> we could have any chance of being successful if we pick a
> Lightning XPI, write an install.js and contents.rdf for it and
> follow the same modification pattern than the one showed in the
> provisional patch?
Yes, I think you would have a chance. There is just the possibility,
that a change in the mainline code could break it, without the
developer knowing about it.
>> My long-term vision for Calendar on Seamonkey would really be a
>> whole different story. It would be a Calendar app, that is built
>> and shipped with Seamonkey by default, just like the browser,
>> the mail app, the web editor and the IRC client.
>>
>> This would also eliminate the need for regular versions of the
>> calendar XPI.
>
> I agree that calendaring would be definitely a good component, and
> there has been a open bug for a long time now. Still, I think that
> it would require an XPI packaging (every component in the SM
> installer is prepared that way), although I suppose you mean that
> it could be done as part of the build process and not require time
> on the Calendar development team to prepare it.
Exactly.
Simon Paquet
>> Just to get this out on the table, the following bugs are examples of
>> difficulties encountered in developing both "calExt" and Sunbird:
>
> OK, I took a look at those bugs.
>
> [...]
>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=330716
>
> Here, I don't really understand how I could help. You calendar
> guys have to decide how to proceed with this, and if you want
> ifdefs in your files or not.
>
> I also don't understand why it would break CalExt with SeaMonkey.
> That doesn't have any icons, neither vertical nor horizontal, so
> why would changing the layout in Sunbird affect it?
Because moving to the new layout would also mean a move to the
PrefwindowV code and its <preferences> widget, which only exists in
Toolkit. Using it would therefore break CalExt on Seamonkey but not
on Firefox or Thunderbird if I'm not mistaken.
Joey Minta
> On Wed, 22 Mar 2006 13:47:20 UTC, Joey Minta wrote:
>
>> Just to get this out on the table, the following bugs are examples of
>> difficulties encountered in developing both "calExt" and Sunbird:
>
> OK, I took a look at those bugs.
not exhaustive. There are others as well, so solving them alone is not
sufficient.
>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=306079
>
> That looks like a bit of work, but as there is a lightning patch that
> one could port, probably not impossible.
Perhaps this is a good place to make the point: What is Sunbird
development meant to do until someone takes the time to take on this
'bit of work'? Our options are either (a) Push forward with the patch
and break CalExt (abandon) or (b) Hold up a necessary patch for Sunbird,
waiting for something that may never come.
>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=330716
>
> Here, I don't really understand how I could help. You calendar guys have
> to decide how to proceed with this, and if you want ifdefs in your files
> or not.
>
> I also don't understand why it would break CalExt with SeaMonkey. That
> doesn't have any icons, neither vertical nor horizontal, so why would
> changing the layout in Sunbird affect it?
As Simon said, the <preference>, <prefpane>, and <prefwindow> widgets
that would be used only exist in toolkit.
>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=325660
>
> Posted a first try of a patch.
Disclaimer: This is not an official review.
I took a look at the patch.
+// calendarDefaultTimezone() is not yet available from here
+//gAlarmSvc.timezone = calendarDefaultTimezone();
+gAlarmSvc.timezone = -1;
This will throw serious errors in the alarm code. The timezone
attribute is assumed to be a valid timezone string and '-1' is
definitely not.
This illustrates another point: Even if someone comes along willing to
maintain CalExt, it still puts an additional burden on the calendar/
peers to do these reviews. The time required would be less, obviously,
than fully maintaining the extension, but still significant. I'd wager
that, for instance, in order to fully finish off that bug, a peer will
have to spend 1-2 hours reviewing and guiding the patch process. That
may not seem like a lot, but spread out over a series of bugs, that time
can become significant. (Please don't take this as an insult to the
work you did on that bug in any way!)
-Joey
wg
> [X-Post to mozilla.support.calendar, F'up2 mozilla.dev.apps.calendar]
>
> Hi guys,
>
> since a few people are now making an effort to discuss more publicly
> about stuff that has only been discussed via mail or IRC in the past,
> I'll try to follow this effort.
>
> Before I start, let me state, that everything in this post is just my
> personal opinion and not necessarily the opinion of the other calendar
> developers or the project as a whole. I would also advise everyone to
> keep this a civil discussion and not start a flamewar here.
>
>
> Okay, now it is my opinion that we should seriously consider to abandon
> the development of the calendar extension for Firefox, Thunderbird and
> Seamonkey and just concentrate on Lightning and Sunbird in the future.
>
>
> extension or is interested in devoting his time to the extension.
> - Although requests have been made by the current calendar developers,
> nobody has stepped forward and offered to actively maintain the
> calendar extension.
> - While the extension gets all the features and bugfixes that Sunbird
> gets, no effort is made from the developer side to actively test it,
> which means that nobody really knows what the current state of the
> extension really is.
> - Actively maintaining the extension would mean a much more complex
> testing matrix for the calendar developers. Currently we have to
> test code checkins on our three major platforms (Windows, Linux, Mac)
> for Lightning and Sunbird. Testing the calendar extension would
> mean testing on all three platforms for all three products (Firefox,
> Thunderbird, Seamonkey). This means 9 additional combinations have
> to be tested.
> - Lightning is the superior product in terms of functionality and is
> already available for Thunderbird. In the future it may be made
> available for Firefox. If Seamonkey finally manages to move to the
> new toolkit code, Lightning can be easily be ported to Seamonkey.
> IMO it is better and much more credible to openly say that this is
> not gonna change, than to keep it in this state of limbo in the
> coming months and still have users who are waiting for an update,
> which may never appear.
>
>
I say dump it. Of course, I don't use the calendar extension (I use
Sunbird and in the future will probably use Lighting) so it is easy for
me to say that.
Personal preferences aside though, I think people need to be realistic
about how much can be done with the limited number of developers
available. I am someone who started watching the calendar project hoping
that someday it might produce something I could use as an alternative to
Outlook. Several years later, I am still waiting. If dumping one of the
calendar offshoots is what is necessary to get a quality product
released before I collect social security, I'm all for it.
The Mozilla foundation had to make the tough decision to stop
development of the Mozilla Suite so they could concentrate on
Firefox/Thunderbird. I think you guys are going to have to bite the
bullet and make a similar decision.
Michiel van Leeuwen
> Okay, now it is my opinion that we should seriously consider to abandon
> the development of the calendar extension for Firefox, Thunderbird and
> Seamonkey and just concentrate on Lightning and Sunbird in the future.
My current thoughts on this are:
- Make a calendar.xpi for firefox, that uses the same xul, css and js
file as sunbird does. This means it has the same looks (seperate
windows) and uses toolkit. It shouldn't be too painful to maintain,
because it shares almost all code with sunbird.
- Drop support for seamonkey. This means drop
calendar/resources/calendar.xul. This is still xpfe based, and will
cause problems with supporting later. (prefwindow comes to mind, but
also autocomplete, theming, toolbars, printing, etc)
- Stop supporting calendar.xpi for firefox when it really gets to be a
pain, or if there are different reasons to drop it
- Also drop calendar.xpi once (if ever) firefox runs on xulrunner, and
sunbird can share the same xulrunner.
- Maybe advertise calendar.xpi as less-supported: bugs need to be tested
against sunbird first.
Note: I already have a calendar.xpi that's based on sunbird, that wasn't
hard. But it has bugs: it goes wonky when you open the calendar window,
close it, and open it again. You can't do anything anymore. jminta
already looked at the problem, and it didn't seem easy to fix.
Michiel
Stephan Schaefer
> Simon Paquet wrote:
>> Okay, now it is my opinion that we should seriously consider to abandon
>> the development of the calendar extension for Firefox, Thunderbird and
>> Seamonkey and just concentrate on Lightning and Sunbird in the future.
>
> My current thoughts on this are:
> - Make a calendar.xpi for firefox, that uses the same xul, css and js
> file as sunbird does. This means it has the same looks (seperate
> windows) and uses toolkit. It shouldn't be too painful to maintain,
> because it shares almost all code with sunbird.
If this means that Lightning bugfixes only have to be tested against
SunBird and not against a third incarnation I fully agree. My biggest
concern is the additional effort for developers *and* reviewers to
maintain 3 calendar applications/extensions while the whole project is
still at a rather early phase in its development. If any decision
requires checking against 3 applications this will definitely slow down
the development process.
Making the calendar project as a whole more complicated than it should
be will not only attract fewer developers but might also discourage
existing ones.
> - Drop support for seamonkey. This means drop
> calendar/resources/calendar.xul. This is still xpfe based, and will
> cause problems with supporting later. (prefwindow comes to mind, but
> also autocomplete, theming, toolbars, printing, etc)
Agreed.
> - Stop supporting calendar.xpi for firefox when it really gets to be a
> pain, or if there are different reasons to drop it
You are referring to the fully sunbird-based xpi you are mentioning
above, right ? Then I fully agree - although we might have to define
what 'pain' exactly means... ;)
> - Also drop calendar.xpi once (if ever) firefox runs on xulrunner, and
> sunbird can share the same xulrunner.
Sure. Whenever that will be.
> - Maybe advertise calendar.xpi as less-supported: bugs need to be tested
> against sunbird first.
>
Makes sense.
> Note: I already have a calendar.xpi that's based on sunbird, that wasn't
> hard. But it has bugs: it goes wonky when you open the calendar window,
> close it, and open it again. You can't do anything anymore. jminta
> already looked at the problem, and it didn't seem easy to fix.
>
It would be great if you could come up with an estimate on how long it
will probably take or after what time another decision has to be made.
Regards,
Stephan
Michiel van Leeuwen
> If this means that Lightning bugfixes only have to be tested against
> SunBird and not against a third incarnation I fully agree. My biggest
In theory, Sunbird andthe extension would use the same code, so no
additional code is needed. In practice, you never know. We could state
that extension builds are not tested by developers, but instead rely on
testing by the community. (If there is no community willing to do at
least some testing, then we should just drop it)
>> - Stop supporting calendar.xpi for firefox when it really gets to be a
>> pain, or if there are different reasons to drop it
>
> You are referring to the fully sunbird-based xpi you are mentioning
> above, right ? Then I fully agree - although we might have to define
> what 'pain' exactly means... ;)
Yes, i mean the sunbird/toolkit based extension. I don't think we have
to define 'pain' right now. It's more like a warning: this extension
might not live forever.
> It would be great if you could come up with an estimate on how long it
> will probably take or after what time another decision has to be made.
That's a bit hard, as i don't know yet what the problem is. I guess it
has to do with releasing some objects, but not all. (from some stack
traces I got, nsITransactionManager seems involved)
Michiel
Dan Mosedale
>
> But unfortunately I am unable to import my calendars (from the calendar
> extension) into lightning. As soon as this will be possible I definitely
> will make the move!
>
If you haven't already, please file a bug on this issue with very
specific details about what sort of behavior you're seeing when you
attempt to import. Otherwise we won't be able to track it down and fix it.
Thanks,
Dan
Dan Mosedale
>
> While I tend to agree that CalExt would not be the correct way to go,
> I'm not 100% convinced of this fact. I finally today sat down at a
> window's box and played around with the experimental CalExt, however,
> and that makes me more convinced that Lightning might be the correct
> solution *for now*. (It had the same issue, an undesired closure on the
> composite calendar, that Lightning does.) The scary situation is that
> the integration hooks planned to link Lightning and Thunderbird will
> eventually make this solution impossible.
I don't see why this is necessarily true. With luck, we should be able
to factor the code in such a way that there is a "core" part of the
extension, and separate host-app hooks. Is there something specific
particular you're worried about?
Dan
Dan Mosedale
> If this means that Lightning bugfixes only have to be tested against
> SunBird and not against a third incarnation I fully agree. My biggest
> concern is the additional effort for developers *and* reviewers to
> maintain 3 calendar applications/extensions while the whole project is
> still at a rather early phase in its development. If any decision
> requires checking against 3 applications this will definitely slow down
> the development process. Making the calendar project as a whole more
> complicated than it should be will not only attract fewer developers but
> might also discourage existing ones.
Completely agreed. If we're to be productive, people need to be able to
spend most of their time doing actual calendaring work and not fighting
with the process, and we already have process problems today. Trying to
give everything the same level of support strikes me as very unlikely to
succeed.
This has been successfully addressed in other parts of the Mozilla
project using a concept of tiered support for various platforms and
applications, and I suspect something similar could be effective here.
See <https://bugzilla.mozilla.org/show_bug.cgi?id=313822#c3> for a short
explanation.
Dan