Calendar Project at a critical juncture
Philipp Kewisch
Lightning add-on to Thunderbird and the standalone Sunbird project, is
at a critical juncture. We feel it's important to communicate this to
our users and contributor community, as your input will determine how
the project continues.
Recently, several contributors who were working on the project full-
time have left the project or have shifted to free-time contributor
status due to other obligations. This means their contributions will
be limited to their spare time, which is quite sparse given a full-
time job and family. This is a significant change from recent years,
and if no new contributors come on board, it means that the rate of
change will decrease dramatically. Our releases will necessarily have
to become less frequent, and the amount of bug fixes and new features
per release will decrease.
As a result of this, we have to take stock, and figure out how we're
going to go forward.
First, as much as it pains us, we have decided to step back from
Sunbird maintenance. Our next release will include Sunbird, but
subsequent releases won't unless new contributors take on the work.
Trying to support both takes too much time, so we had to make a
painful prioritization decision.
Second, our next major goal is to have a version of Lightning that
will work well with Thunderbird 3. Lightning won't be built-in to
Thunderbird 3 for a variety of reasons (see this post [1] by David
Ascher for more on the topic), but we're still on track to have a
release that gives users of Thunderbird 2 & Lightning a migration
path. That version will be a significant upgrade from Lightning 0.9,
including notable performance and usability improvements.
There's a lot of work to do to reach our goals, and as a result we're
not yet planning much beyond that. This is where we need your input,
both in terms of direction-setting -- given limited resources, where
should we focus and why? and in terms of more directly useful help --
if you've been using Lightning for a while, and know a bit about
mozilla technologies (any of XUL, JavaScript, CSS), or want to help
test, write documentation, or do something else not listed here -- get
in touch!
This is really a tremendous opportunity for anyone who is interested
and willing to help make a difference here for the project and its
hundreds of thousands of users -- get involved!
I hope to hear more from you soon!
Philipp Kewisch (Calendar Project - lead developer)
Matthew Monaco
> Sunbird maintenance. Our next release will include Sunbird, but
> subsequent releases won't unless new contributors take on the work.
> Trying to support both takes too much time, so we had to make a
> painful prioritization decision.
I like this decision. I think the calendar is more useful coupled with the mail
client. In addition it just seems to me that it might be easier in the future
to take the lightning code and have it run by itself than force sunbird into an
extension (but then I have no experience with this).
> There's a lot of work to do to reach our goals, and as a result we're
> not yet planning much beyond that. This is where we need your input,
> both in terms of direction-setting -- given limited resources, where
> should we focus and why? and in terms of more directly useful help --
The thing I look most for in lightning is groupware abilities, CalDAV GroupDAV
etc. Lightning will obviously get more attention with more use and the biggest
niche I see that needs to be filled right now is an answer to MS's groupware. A
mail server, sufficient calendar/groupware server, and Thunderbird+Lightning can
do this.
> if you've been using Lightning for a while, and know a bit about
> mozilla technologies (any of XUL, JavaScript, CSS), or want to help
> test, write documentation, or do something else not listed here -- get
> in touch!
I recently tried my hand at modifying Lightning to give the option to display
tasks by on the calendar by duedate. I was surprised at how far I got to be
honest. However I hit a standstill when I couldn't find some of the code that
actually "draws" some of the stuff on the calendar. I'm sure the DOM inspector
would have helped me but I ran into version gridlock. The DOM inspector I
downloaded which said it'd work with my version would not. I tried hacking at
it a little but to no success. IN SHORT, I think that we've got to make sure
all of the tools required for Lightning development are compatible.
gNeandr
> IN SHORT, I think that we've got to make sure
> all of the tools required for Lightning development are compatible.
>
makes it very difficult to contribute.
LG as an >>extension<< should offer an easier process to build it .. as
it's for other extensions.
Maybe the team (?) could offer an additional way to generate the XPI as
long as no compilation is required.
I expect there are some -- or a lot of -- modifications and/or additions
possible going that way.
Günter
Simon Paquet
>> IN SHORT, I think that we've got to make sure
>> all of the tools required for Lightning development are compatible.
>>
>FMPOV the build system for LG tied to the 'general' TB build process
>makes it very difficult to contribute.
>LG as an >>extension<< should offer an easier process to build it .. as
>it's for other extensions.
>Maybe the team (?) could offer an additional way to generate the XPI as
>long as no compilation is required.
There's really no "team" anymore.
But why don't you make it happen?
Simon Paquet
--
Thunderbird/Calendar Localisation (L10n) Coordinator
Thunderbird l10n blog: http://thunderbird-l10n.blogspot.com
Calendar website maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
Robert Kaiser
> Maybe the team (?) could offer an additional way to generate the XPI as
> long as no compilation is required.
I actually think that compilation is required to build Lightning, so
providing such shortcuts is quite hard.
Robert Kaiser
gNeandr
> bits of calendar that are compiled (libical, etc.) into one add-on,
> and then have a separate chrome-only add-on. That might allow more
> agility.
>
> --david
Sounds very much about the approach I'm thinking about. Having a
'simple' process to generate the whole XPI, but NOT to necessarily have
to compile those certain parts. Any idea who can help for that?
Günter
Dan Mosedale
> I recently tried my hand at modifying Lightning to give the option to display
> tasks by on the calendar by duedate. I was surprised at how far I got to be
> honest. However I hit a standstill when I couldn't find some of the code that
> actually "draws" some of the stuff on the calendar. I'm sure the DOM inspector
> would have helped me but I ran into version gridlock. The DOM inspector I
> downloaded which said it'd work with my version would not. I tried hacking at
> it a little but to no success. IN SHORT, I think that we've got to make sure
> all of the tools required for Lightning development are compatible.
You picked the wrong day to download. :-) The branch version numbering
of Thunderbird changed just before today's builds were spun, and the
DOMi install.rdf hasn't yet been updated. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=467761#c1>.
Dan
Dan Mosedale
> You picked the wrong day to download. :-) The branch version numbering
> of Thunderbird changed just before today's builds were spun, and the
> DOMi install.rdf hasn't yet been updated. See
> <https://bugzilla.mozilla.org/show_bug.cgi?id=467761#c1>.
Whoops, that bug is for the last time this problem happened, I think
there's going to be another one for the current issue. But it should be
fixed soon.
Dan
Marcel Berteler
> Recently, several contributors who were working on the project full-
> time have left the project or have shifted to free-time contributor
> status due to other obligations. This means their contributions will
> be limited to their spare time, which is quite sparse given a full-
> time job and family. This is a significant change from recent years,
> and if no new contributors come on board, it means that the rate of
> change will decrease dramatically. Our releases will necessarily have
> to become less frequent, and the amount of bug fixes and new features
> per release will decrease.
Sorry to hear about the loss of dedicated resources. for those of you
that leave or have left: thanks for your work and I hope you will
continue to work on this great project in your spare time. All others
out there that do not yet contribute: Please start doing so and remember
that even the biggest ocean is made of drops of water.
>
> Second, our next major goal is to have a version of Lightning that
> will work well with Thunderbird 3. Lightning won't be built-in to
> Thunderbird 3 for a variety of reasons (see this post [1] by David
> Ascher for more on the topic), but we're still on track to have a
> release that gives users of Thunderbird 2 & Lightning a migration
> path. That version will be a significant upgrade from Lightning 0.9,
> including notable performance and usability improvements.
>
I think this is a great decision as I have stated before and welcome it
especially for the reasons of being able to release outside of the TB
release cycles.
> There's a lot of work to do to reach our goals, and as a result we're
> not yet planning much beyond that. This is where we need your input,
> both in terms of direction-setting -- given limited resources, where
> should we focus and why?
As a corporate user, interoperability and synchronization are the
biggest issues for me. If Calendar can communicate with most frequently
used other calendar tools out there and my fellow board members can
synch their MS phone than there is no reason anymore not to move to TB
and LN and finally get rid of our dependency on outlook.
I would opt for making sure the basics work 100% before adding other
features. Its better to have a program than can do 2 functions 100% than
5 functions 85%. With this I mean for example focus on making sure that
iTIP is working according to standards and ensuring it can cope with
non-standard requests from other widely used calendar tools before
adding any other feature.
As for additional calendar provider plugins / extensions, I think they
should eventually end up in the LN plugin as having extensions for
extensions is really confusing end users more than necessary. But I am
sure this is a debate on its own....
Keep up the good work.
Marcel
Archaeopteryx
and policies, i.e.
- Calendar mainly implemented features for business clients in the last
releases and now with the bundle with Thunderbird (which has Exchange
support not on its road map), this can't fully work (furthermore this is
a drop of the usual "event viewer" like a student, see
https://wiki.mozilla.org/Calendar:Target_Users ),
- performance hits have hardly been managed in the past,
- develop road maps for parts of the application and drive the coding in
a line from start to end (features shouldn't look like "under
construction; but Thunderbird has also this problem),
- who develops the code should also document it, because this is the
most time efficient and writing the documentation lets people check if
everything works logically and provides a more and more complete
documentation, encouraging add-on developers (who could implemented the
MAPI this way).
What would be needed to keep Sunbird alive (except from an up2date
design concept)? Maybe also the people who are interested in a further
development of Sunbird can show here up.
Archaeopteryx
Thomas Stache
> Recently, several contributors who were working on the project full-
> time have left the project or have shifted to free-time contributor
> status due to other obligations. This means their contributions will
> be limited to their spare time, which is quite sparse given a full-
> time job and family. This is a significant change from recent years,
> and if no new contributors come on board, it means that the rate of
> change will decrease dramatically. Our releases will necessarily have
> to become less frequent, and the amount of bug fixes and new features
> per release will decrease.
>
This has to be read as SUN having stopped funding of developers for
calendar, I hope they relocated the people and did not "let them go"
entirely. My best wishes to Daniel, Berend, Christian, Ause and the
others...
What I did not quite get: why was the situation kept so low key, out of
sight of the "community".
Hope to learn more in the coming weeks,
Thomas
Daniel boelzle
> gNeandr wrote:
>
>>> IN SHORT, I think that we've got to make sure
>>> all of the tools required for Lightning development are compatible.
>>>
>> FMPOV the build system for LG tied to the 'general' TB build process
>> makes it very difficult to contribute.
>> LG as an >>extension<< should offer an easier process to build it .. as
>> it's for other extensions.
>> Maybe the team (?) could offer an additional way to generate the XPI as
>> long as no compilation is required.
>
> There's really no "team" anymore.
like, and I suspect the same holds true e.g. for Philipp, Stefan,
Martin, Berend, ...you?
thanks,
Daniel
Mark Banner
Why not just grab a nightly xpi, unpack it into two directories, do some
work in one and install into TB, etc, then when it works, do a diff
between the directories?
That's slightly simplified, but should be good enough for starters.
Standard8
Daniel Boelzle
Sounds like the approach I'd suggest for "quickstart hackers", too.
Maybe somebody already has scripting at hand for this?
Daniel
Simon Paquet
>>> Maybe the team (?) could offer an additional way to generate the
>>> XPI as long as no compilation is required.
>
>> There's really no "team" anymore.
>
> Huh?
I meant to say that there's no *dedicated* team anymore at our former
corporate sponsor.
Cya
Simon
Robert Kaiser
> Daniel boelzle wrote on 20. Feb 2009:
>
>>>> Maybe the team (?) could offer an additional way to generate the XPI
>>>> as long as no compilation is required.
>>
>>> There's really no "team" anymore.
>>
>> Huh?
>
> I meant to say that there's no *dedicated* team anymore at our former
> corporate sponsor.
And it's noteworthy that there are successful project out there that
don't have a corporate sponsor and never had one and still are moving
along successfully with a community team. Sure, it's not always easy,
but it's doable. I very much hope the calendar project will continue to
work well as a community project, basically.
Robert Kaiser
Simon Paquet
>> Recently, several contributors who were working on the project full-
>> time have left the project or have shifted to free-time contributor
>> status due to other obligations. This means their contributions will
>> be limited to their spare time, which is quite sparse given a full-
>> time job and family. This is a significant change from recent years,
>> and if no new contributors come on board, it means that the rate of
>> change will decrease dramatically. Our releases will necessarily have
>> to become less frequent, and the amount of bug fixes and new features
>> per release will decrease.
>
>This has to be read as SUN having stopped funding of developers for
>calendar
Yes.
>I hope they relocated the people and did not "let them go" entirely.
They all still work there. Nobody lost their job AFAIK.
>What I did not quite get: why was the situation kept so low key,
>out of sight of the "community".
Corporate politics.
Simon Paquet
Bruno Browning
> And it's noteworthy that there are successful project out there that
> don't have a corporate sponsor and never had one and still are moving
> along successfully with a community team. Sure, it's not always easy,
> but it's doable. I very much hope the calendar project will continue to
> work well as a community project, basically.
I agree completely. This is one reason that I'm happy to see the
meetings moving to IRC. The conference calls have been useful for
coordinating production of code by people working full-time on the
project, but they have been I think less useful for creation of
community. We should also consider posting meeting logs to the wiki so
that even people who can't be online at the time of the meeting can see
what happened and have a chance to participate in decision-making.
bb
Robert Kaiser
If you're doing status meeting wiki pages like Firefox, Thunderbird or
SeaMonkey do, make sure to contact bsmedberg to also set up his script
to make those be auto-posted to planet as well.
Robert Kaiser