Re: Plans for moving SeaMonkey and Thunderbird to Mercurial
Michiel van Leeuwen
> That is exactly my point. Once TB3 gets released, Lightning and TB
> will no longer be separate applications/extensions, but just one
> single application.
Wow. This is the first time I heard of this. All I read before was
lightning getting enabled by default for thunderbird. But now, it's just
one single app?
> That is a fine reason, but Lightning will follow the schedule of
> Thunderbird once TB3 gets out. We may do interim releases (that
> hasn't been decided yet), but the major releases will likely follow
> a joint Calendar/Mail roadmap.
Again, how is it possible that I didn't hear about this before? I do
read all the status meeting logs, read the newsgroups, read the blogs.
What else do I need to read?
Michiel
(f-up to mda.calendar)
Simon Paquet
>Simon Paquet wrote:
>> That is exactly my point. Once TB3 gets released, Lightning and TB
>> will no longer be separate applications/extensions, but just one
>> single application.
>
>Wow. This is the first time I heard of this. All I read before was
>lightning getting enabled by default for thunderbird. But now, it's just
>one single app?
TB3 will be shipped as Thunderbird, not as Thunderbird+Lightning.
Therefore it is a single application. What did you expect?
>> That is a fine reason, but Lightning will follow the schedule of
>> Thunderbird once TB3 gets out. We may do interim releases (that
>> hasn't been decided yet), but the major releases will likely follow
>> a joint Calendar/Mail roadmap.
>
>Again, how is it possible that I didn't hear about this before? I do
>read all the status meeting logs, read the newsgroups, read the blogs.
>What else do I need to read?
http://weblogs.mozillazine.org/calendar/2008/05/next_release_09_and_beyond.html
mentioned it IMO.
Simon
--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
Michiel van Leeuwen
> TB3 will be shipped as Thunderbird, not as Thunderbird+Lightning.
> Therefore it is a single application. What did you expect?
When TB3 includes lightning, that doesn't mean that lightning can no
longer live on it's own. They can perfectly be seperate applications. I
think it would make a lot of sense for them to be. For example,
lightning is a lot less mature. I think it will want to release more
often then TB.
>>> That is a fine reason, but Lightning will follow the schedule of
>>> Thunderbird once TB3 gets out. We may do interim releases (that
>>> hasn't been decided yet), but the major releases will likely follow
>>> a joint Calendar/Mail roadmap.
>> Again, how is it possible that I didn't hear about this before? I do
>> read all the status meeting logs, read the newsgroups, read the blogs.
>> What else do I need to read?
>
> http://weblogs.mozillazine.org/calendar/2008/05/next_release_09_and_beyond.html
> mentioned it IMO.
I don't read it in there. All that post says is that lightning will move
to the trunk, and mentions TB3 because there must be some trunk TB for
lightning to be installed into. It doesn't say anything about future
releases.
Michiel
Eric Valette
> Simon Paquet wrote:
>> TB3 will be shipped as Thunderbird, not as Thunderbird+Lightning.
>> Therefore it is a single application. What did you expect?
>
> When TB3 includes lightning, that doesn't mean that lightning can no
> longer live on it's own. They can perfectly be seperate applications. I
> think it would make a lot of sense for them to be. For example,
> lightning is a lot less mature. I think it will want to release more
> often then TB.
Yes but on the other hand, the failure of lighning will no more be the
lightning team responsibility ;-)
I think you are too much on the technical side for analysing this
decision. In the same way, when the same teamdeclare they will be no 1.0
for TB2, they also have found a way to be safe on the TB2 side...
-- eric
Simon Paquet
>> TB3 will be shipped as Thunderbird, not as Thunderbird+Lightning.
>> Therefore it is a single application. What did you expect?
> When TB3 includes lightning, that doesn't mean that lightning can no
> longer live on it's own. They can perfectly be seperate applications.
> I think it would make a lot of sense for them to be. For example,
> lightning is a lot less mature. I think it will want to release more
> often then TB.
Please read the original post which started this sub-thread:
| That is a fine reason, but Lightning will follow the schedule of
| Thunderbird once TB3 gets out. We may do interim releases (that
| hasn't been decided yet), but the major releases will likely follow
| a joint Calendar/Mail roadmap.
Simon
Mark Banner
> Michiel van Leeuwen wrote on 17. Jun 2008:
>
>>> TB3 will be shipped as Thunderbird, not as Thunderbird+Lightning.
>>> Therefore it is a single application. What did you expect?
>
>> When TB3 includes lightning, that doesn't mean that lightning can no
>> longer live on it's own. They can perfectly be seperate applications.
>> I think it would make a lot of sense for them to be. For example,
>> lightning is a lot less mature. I think it will want to release more
>> often then TB.
>
> Please read the original post which started this sub-thread:
>
> | That is a fine reason, but Lightning will follow the schedule of
> | Thunderbird once TB3 gets out. We may do interim releases (that
> | hasn't been decided yet), but the major releases will likely follow
> | a joint Calendar/Mail roadmap.
I think what also hasn't been decided is how Thunderbird and Lightning
will be shipped "as one application", there are at least two
possibilities at the moment. One of those (keep it as an extension)
would allow interim releases.
However I would expect much closer development between Thunderbird &
Lightning. For example I am already trying to remember to consider the
effects on Lightning of various changes we are making within the address
book and autocomplete areas especially.
Standard8
Robert Kaiser
> TB3 will be shipped as Thunderbird, not as Thunderbird+Lightning.
> Therefore it is a single application. What did you expect?
SeaMonkey also ships as "SeaMonkey", even though it includes ChatZilla,
venkman and DOMi, and they all still are their own
projects/extensions/"applications".
Robert Kaiser
Simon Paquet
The main difference being - as already said elsewhere - that those three
extensions are not exclusively developed for SeaMonkey. Therefore you
are comparing apples and oranges here.
Robert Kaiser
> The main difference being - as already said elsewhere - that those three
> extensions are not exclusively developed for SeaMonkey. Therefore you
> are comparing apples and oranges here.
In that case, those still are growing on different trees though *g*
Robert Kaiser
David Ascher
Can I suggest that we take this issue up in a conference call, to work
through the issues all at once?
Let's table this discussion until the next Thunderbird status meeting
(next Tuesday, 9:30am PST -- see
http://wiki.mozilla.org/Thunderbird/StatusMeetings/2008-06-24)
Simon, Daniel, if you could join it, it would be really helpful. If you
can't, let me know, and we can schedule a separate call. Robert and the
Tb folks tend to be there already.
--david
Justin Wood (Callek)
Just for record, can we schedule this so that the Hg part is first in
the meeting, so that those not interested in other TB status
information/discussions don't have to hold out for that :-)
--
~Justin Wood (Callek)
David Ascher
> you didn't quote what part of the conversation (shared hg repo, how
> to do future Lightning releases after TB3, hg repo structure) didn't
> seem to be getting anywhere. What do you want to discuss on the ?
> confcall?
> Personally, I still haven't seen much discussion here. I would prefer
> it to take this out a while longer to see, whether we can come to
> some kind of conclusion or whether we need to discuss this in a more
> direct fashion in a confcall.
We can give it a try. (note: setting followup to m.d.a.c, because I had
to pick something).
I think that the starting point is the expected role of calendaring in
the thunderbird project. It strikes me that establishing that will drive:
* how independent the subprojects are
* how updates happen
* how many checkins are expected to span the multiple codebases (and
therefore how problematic having different repos would be)
* the resulting optimal hg repo structures
Layered on top of that is the impact of the Tb+Lightning relationship on
Seamonkey, which I don't understand yet.
My personal take is that, _long term_:
1) We want calendaring to be well integrated, so that we have as smooth
a user experience as possible (better than what is possible with Tb2 +
Lightning 0.8, for example). I wouldn't be surprised if some of the
things that make sense from a UX POV are simply not possible using just
an extension.
2) We want the impact of the code on the user experience to be
proportional to the need for the features. So that if someone wants to
use the TODO management feature, they can do just that. If someone
wants to use just hosted calendars, they can do just that. etc. The
analogy there is that in Thunderbird, if you don't setup a News account,
then the fact that Thunderbird does News is invisible to you. This kind
of "progressive UX" strikes me as a positive thing, especially in the
world of calendaring, where some UIs are overwhelming.
3) I'm most interested in talking about what we could do with a
collaborative development community, rather than talking about the
boundaries which are reflected in the existing codebase. For example, I
suspect that when we get around to talking about microformat and
pseudo-microformat detection in Thunderbird, that the people with
experience in calendaring might have interesting and relevant
experience. I also expect that discussion about features like "notes"
should be informed by the work done in task management. Etc.
4) I have thoughts and opinions about where calendaring in Tb should go.
I suspect everyone on the Tb team does as well, and everyone in the
Lightning team does as well. I doubt we have had enough discussion
about what the differences of opinion might be at this stage. Planning
doesn't seem like the right forum for it, either.
I'm explicitly not making any statements about Hg, because I don't
understand the rationales for separation of repos for example. My
default assumption given that we've come from a world of everything in
one repo was to move to two repos, not twenty. But as I said above, my
expectation is that those questions are easier to answer once we know
where we want to go.
> As a sidenote: Making it to the TB status call is always hard for me due
> to the lack of a toll-free international dial-in number. I need to be at
> home to dial-in toll-free via Skype, which is often hard for me to do,
> because at 6:30pm CET I'm often still at work.
Noted, that sucks. It'd be nice to come up with a source of
non-north-american DIDs that we could hook into the Mozilla Asterisk
system. (filed https://bugzilla.mozilla.org/show_bug.cgi?id=439766).
--david
Simon Paquet
> I think that the starting point is the expected role of calendaring
> in the thunderbird project. It strikes me that establishing that
> will drive:
>
> * how independent the subprojects are
> * how updates happen
> * how many checkins are expected to span the multiple codebases
> (and therefore how problematic having different repos would be)
> * the resulting optimal hg repo structures
>
> Layered on top of that is the impact of the Tb+Lightning
> relationship on Seamonkey, which I don't understand yet.
Well, it is pretty obvious that the SeaMonkey team wants to have
calendaring functionality in the product. It just hasn't materialized
yet, even though Robert has put out money for it. That basically means
that there is *currently* no relationship between Lightning and
SeaMonkey and therefore no relationship of TB+Lightning and SeaMonkey
either.
> My personal take is that, _long term_:
> 1) We want calendaring to be well integrated, so that we have as
> smooth a user experience as possible (better than what is
> possible with Tb2 + Lightning 0.8, for example). I wouldn't be
> surprised if some of the things that make sense from a UX POV
> are simply not possible using just an extension.
Agreed.
> 2) We want the impact of the code on the user experience to be
> proportional to the need for the features. So that if someone
> wants to use the TODO management feature, they can do just
> that. If someone wants to use just hosted calendars, they can
> do just that. etc. The analogy there is that in Thunderbird,
> if you don't setup a News account, then the fact that Thunderbird
> does News is invisible to you. This kind of "progressive UX"
> strikes me as a positive thing, especially in the world of
> calendaring, where some UIs are overwhelming.
I have a slightly different take on that. I agree that this progressive
UX is a good thing. I just don't think that you can separate stuff like
event management (plain calendaring) and task management (ToDo stuff)
that way. I see both of those more in a way that you guys currently
expose the different mail protocols (POP3, IMAP). They are there, but
unless you create a new account they don't get in your way.
> 3) I'm most interested in talking about what we could do with a
> collaborative development community, rather than talking about
> the boundaries which are reflected in the existing codebase.
Agreed.
> 4) I have thoughts and opinions about where calendaring in Tb should
> go.
I surely hope so :-)
> I suspect everyone on the Tb team does as well, and everyone in
> the Lightning team does as well.
That is very likely.
> I doubt we have had enough discussion about what the differences
> of opinion might be at this stage. Planning doesn't seem like
> the right forum for it, either.
Yes. I think what prompted the post to .planning was the hg repo
issue. The topic got somewhat adjusted during the discussion.
>> As a sidenote: Making it to the TB status call is always hard for
>> me due to the lack of a toll-free international dial-in number.
Let me rephrase that a little bit. I really don't need a toll-free
dial-in number. A local (German) dial-in number would suffice, as
I have a fixed-line phone flatrate at home and at the office, which
is more and more the case in German homes.
> Noted, that sucks. It'd be nice to come up with a source of
> non-north-american DIDs that we could hook into the Mozilla
> Asterisk system.
> (filed https://bugzilla.mozilla.org/show_bug.cgi?id=439766).
Thanks.
Cya
Robert Kaiser
> Well, it is pretty obvious that the SeaMonkey team wants to have
> calendaring functionality in the product. It just hasn't materialized
> yet, even though Robert has put out money for it. That basically means
> that there is *currently* no relationship between Lightning and
> SeaMonkey and therefore no relationship of TB+Lightning and SeaMonkey
> either.
That's a very one-dimensional view, as you forget the existing
relationship between Thunderbird and SeaMonkey, independent of any
calendaring functionality.
But you're right that SeaMonkey wants to gain calendaring functionality
in the long term. Unfortunately, we still have a huge pile of other
things on our plate that need to get fixed first.
> I have a slightly different take on that. I agree that this progressive
> UX is a good thing. I just don't think that you can separate stuff like
> event management (plain calendaring) and task management (ToDo stuff)
> that way. I see both of those more in a way that you guys currently
> expose the different mail protocols (POP3, IMAP). They are there, but
> unless you create a new account they don't get in your way.
OK, just another argument for reworking the account management to be
easier to extend with additional account types (which is in people's
heads already as a long-term goal, probably post-TB3 though).
This should be done in a way that extensions can add their account types
though (independent of the question if calendaring is one or not).
>> 4) I have thoughts and opinions about where calendaring in Tb should go.
>
> I surely hope so :-)
>
>> I suspect everyone on the Tb team does as well, and everyone in the
>> Lightning team does as well.
>
> That is very likely.
I even have thoughts and opinions about where calendaring in SeaMonkey
should go. ;-)
>> I doubt we have had enough discussion about what the differences of
>> opinion might be at this stage. Planning doesn't seem like the right
>> forum for it, either.
>
> Yes. I think what prompted the post to .planning was the hg repo
> issue. The topic got somewhat adjusted during the discussion.
I still think this would be a topic that fits .planning, as it covers
planning of the future of more than one Mozilla project - and something
where I'd expect people more familiar to build system structure and hg
management to possibly have some input.
Robert Kaiser
Dan Mosedale
> My personal take is that, _long term_:
>
> 1) We want calendaring to be well integrated, so that we have as smooth
> a user experience as possible (better than what is possible with Tb2 +
> Lightning 0.8, for example). I wouldn't be surprised if some of the
> things that make sense from a UX POV are simply not possible using just
> an extension.
I agree. I also think it's important that we should try to make it
possible to do everything in an extension. That said, knowing the
Thunderbird code, I think the realities of the situation are that we're
not always going to have the bandwidth to do The Right Thing w.r.t.
modularity, and we're sometimes going to need to make sacrifices there
for the sake of user experience. The inclusion of MathML in Gecko is a
past example of this sort of situation.
> 3) I'm most interested in talking about what we could do with a
> collaborative development community, rather than talking about the
> boundaries which are reflected in the existing codebase. For example, I
> suspect that when we get around to talking about microformat and
> pseudo-microformat detection in Thunderbird, that the people with
> experience in calendaring might have interesting and relevant
> experience. I also expect that discussion about features like "notes"
> should be informed by the work done in task management. Etc.
In my mind, the above point is in many ways the most important takeaway,
and the examples are good ones. Notes in particular seems like it
doesn't lend itself well to being sliced apart into "calendar" and
"mail" chunks, and I imagine there will be other things in the UI with
the same issue.
At the very least, it should be possible for folks working on
calendaring features to do so in tight alignment with folks working on
other Thunderbird features, and logistical decisions such as what code
lives in what repository should be subordinate to that.
Dan
Robert Kaiser
> At the very least, it should be possible for folks working on
> calendaring features to do so in tight alignment with folks working on
> other Thunderbird features, and logistical decisions such as what code
> lives in what repository should be subordinate to that.
Right. And they might even be independent from that to a certain point.
I think there are good arguments in either direction, and I want to
emphasize that I'm not convinced yet of any specific repo structure,
starting from the suite and mail sharing to including calendar in that.
I think it would be good if we can have a meeting of people who have
some kind of leadership role (I know, we probably all don't have people
who can make hard decisions alone) in SeaMonkey, Thunderbird and
Calendar projects, ideally together with someone who really understands
all the hg/mozilla2 stuff well (such as bsmedberg), so that we can
figure out a path that sounds reasonable to all of us.
IMHO, we should come to a point where we have a plan very soon now, so
we can influence where 1.9.1 goes if we decide to jump on that train.
Once we have that plan, it's our decision how fast we actually implement
that (though, if we follow roughly the way I already did some work for,
I'd love to have it not bitrot too much).
Robert Kaiser
Philipp Kewisch
should be rolled out, I had the feeling we agreed that Lightning will
be released as part of Thunderbird, staying with the name
"Thunderbird" instead of something like "Thunderbird with Lightning".
OTOH I don't think we actually decided on *how* Lightning should be
integrated in detail. Simon, Michiel, I think you both have the same
opinion but a slight misunderstanding.
I personally also think that we are better off that Lightning stays an
extension, but packaging it into Thunderbird by default. This way we
have some advantages:
* We can do intermediate releases of Lightning, due to the difference
in maturity.
* Users that don't want an email client that also does calendaring
(maybe because they think it slows down the app, or is just in the
way) can disable/uninstall lightning
* Integration into seamonkey is probably easier this way.
If it turns out that we want to hide Lightning as an extension, this
can still be done using <em:hidden> in the extensions manager.
Regarding the actual topic, I don't understand the actual consequences
quite yet, but I'm open for new and hip build systems and hope that at
some point my custom patchset scripts will become obsolete ;-)
Philipp
Simon Paquet
> Maybe I missed some things myself w.r.t how lightning and
> Thunderbird should be rolled out, I had the feeling we agreed
> that Lightning will be released as part of Thunderbird, staying
> with the name "Thunderbird" instead of something like "Thunderbird
> with Lightning". OTOH I don't think we actually decided on *how*
> Lightning should be integrated in detail.
Exactly.
> I personally also think that we are better off that Lightning stays
> an extension, but packaging it into Thunderbird by default. This
> way we have some advantages:
>
> * We can do intermediate releases of Lightning, due to the
> difference in maturity.
> * Users that don't want an email client that also does calendaring
> (maybe because they think it slows down the app, or is just in
> the way) can disable/uninstall lightning
> * Integration into seamonkey is probably easier this way.
These are all fine reasons to continue to package Lightning as an
extension and I agree that we should probably continue to package it
as such until we have a better understanding of our place, role and
goals in the wider Thunderbird universe.
However once we have that, it might be prudent to reexamine that
decision.
> If it turns out that we want to hide Lightning as an extension,
> this can still be done using <em:hidden> in the extensions manager.
Personally, I don't see this to be related to the issue at hand in
any way. We could very well hide Lightning in TB3 even though we
ship it as an extension.
Daniel Boelzle
> Philipp Kewisch wrote on 22. Jun 2008:
>
>> Maybe I missed some things myself w.r.t how lightning and
>> Thunderbird should be rolled out, I had the feeling we agreed
>> that Lightning will be released as part of Thunderbird, staying
>> with the name "Thunderbird" instead of something like "Thunderbird
>> with Lightning". OTOH I don't think we actually decided on *how*
>> Lightning should be integrated in detail.
>
> Exactly.
Just to add one reason I remember from the discussion we had on the F2F:
We actually saw a great chance for the calendar project, because once
lightning is part of thunderbird, the calendar project will be much more
visible than before. I hope we will attract more users, but also
developers then.
Thus it's a reasonable priority to make that integration as good as
possible. That doesn't mean at all that we don't want to improve Sunbird
or support SeaMonkey in the future, but I think we need to stay
focussed, because we only have very few regular contributors.
>
>> I personally also think that we are better off that Lightning stays
>> an extension, but packaging it into Thunderbird by default. This
>> way we have some advantages:
>>
>> * We can do intermediate releases of Lightning, due to the
>> difference in maturity.
>> * Users that don't want an email client that also does calendaring
>> (maybe because they think it slows down the app, or is just in
>> the way) can disable/uninstall lightning
>> * Integration into seamonkey is probably easier this way.
>
> These are all fine reasons to continue to package Lightning as an
> extension and I agree that we should probably continue to package it
> as such until we have a better understanding of our place, role and
> goals in the wider Thunderbird universe.
>
> However once we have that, it might be prudent to reexamine that
> decision.
>
>> If it turns out that we want to hide Lightning as an extension,
>> this can still be done using <em:hidden> in the extensions manager.
>
> Personally, I don't see this to be related to the issue at hand in
> any way. We could very well hide Lightning in TB3 even though we
> ship it as an extension.
IMO another good topic for the FFox summit.
regards,
Daniel
Robert Kaiser
> Thus it's a reasonable priority to make that integration as good as
> possible. That doesn't mean at all that we don't want to improve Sunbird
> or support SeaMonkey in the future, but I think we need to stay
> focussed, because we only have very few regular contributors.
I fully agree, but I'm pretty sure the decision of calendar sharing a
repository with SeaMonkey and Thunderbird is actually more or less
independent from how well the integration is, which again is independent
of how big the cooperation is which still is independent of if it's
technically an extension or not.
Of course, there might be some connections between those, but every item
of that list can be achieved independent of how the others are resolved.
The one item of biggest interest to me currently is the repository, and
I'd like to have that solved way before the Summit, at least have a
decided plan, ideally even a start of implementing it. I'm pretty sure a
lot of details to discuss will result from this, which we can then
discuss there. (Calendar will need some structural changes to the code
wrt. extensions/lightning and extensions/webdav in any of those cases.)
I'm not sure yet if sharing the repo between all of us or keeping at
least calendar in a separate repo is the best way but there are good
arguments in both ways. I guess it's probably best if we find some way
where people from all three projects can discuss this more directly,
ideally with someone like bsemedberg, who knows hg and mozilla-central
strcuture well.
Robert Kaiser