Plans for the next calendar release
Philipp Kewisch
I'd like to discuss some things with you regarding the next calendar
release. We need to find a consensus on which branch to use and when
the next release will be.
On the Mozilla Summit the final plans for what Thunderbird 3.next will
be based on were made. The short version is that 3.next will be
released from comm-1.9.2, and there will be a release of Thunderbird
that uses the mozilla2.0 shortly after the Firefox 4.0 release. You
can see the details here: http://groups.google.com/group/tb-planning/browse_thread/thread/f2a72996faae24f6
So we basically have two options:
* Release another 1.9.2 based version when Thunderbird 3.next is
released.
* Release from Mozilla 2.0 together with the fitting Thunderbird
version.
Regarding comm-central / mozilla 2.0, the next release might be quite
far away. Firefox 4 is scheduled for Q1 2011, which probably means we
won't release until the beginning of Q2 2011. This sounds like a long
period. The upside is that we can concentrate on one nightly and can
more easily improve performance by making use of new CSS, XUL and
layout changes.
Regarding comm-1.9.2 / mozilla-1.9.2, this has the advantage that we
can release sooner and fix the critical caldav errors. On the
contrary, this means more work when doing checkins. Mozilla 2.0 has
caused us to do some invasive changes (new addons manager api, xpcom
component registration, upcoming jsval changes) that we can hardly
backport to comm-1.9.2. This means we might have to write separate
patches for comm-central and comm-1.9.2 which means more mechanical
work and less time for fixing bugs and new features. It also means we
need more QA, and might confuse our nightly users since there are two
active nightlys. We'll have to communicate this properly.
Right now I am in favor of what ssitter mentioned in another thread.
This means stay on trunk for active development and backport a select
number of patches. There are a few candidates I have in mind, mostly
related to caldav.
I'd really appreciate some input from others too!
Mark Banner
> Regarding comm-central / mozilla 2.0, the next release might be quite
> far away. Firefox 4 is scheduled for Q1 2011, which probably means we
> won't release until the beginning of Q2 2011. This sounds like a long
> period. The upside is that we can concentrate on one nightly and can
> more easily improve performance by making use of new CSS, XUL and
> layout changes.
Although there was a rumour about that, I checked recently and the aim
at the top is for releasing in October/November.
> It also means we
> need more QA, and might confuse our nightly users since there are two
> active nightlys. We'll have to communicate this properly.
Well, you already have two sets of nightlies ;-)
Standard8
Taraman
I think, since manpower is something we lack, we should choose the
last option Philipp mentions which comes from ssitter.
Having some important fixes backported should be enough for the
current release with the possibilities we have.
Maybe we can even make a bugfix-release from that.
Markus
Marcel Berteler
Remember that Calendar is not a stand alone product and always relies on
the TB developers and their releases. If they run late, Calendar can be
released but not used. Relying on the roadmap of TB has proven to be a
risk, so make sure that risk is either avoided, mitigated or accepted.
As the risk can not be avoided it needs to be mitigated and/or accepted.
When the decision was taken to stop developing for TB2 and focus on TB3,
this risk was 100% accepted and no mitigation was done. This did not
turn out to be the best decision as TB3 was delayed over and over again
and users where left with a stale product.
Although looking ahead is always great for developers and ensures
developers do not have to duplicate work, it also means that the current
users do not get to experience the fruits of all that labor until much
later on.
Lets learn from the past and besides accepting that Calendar is
dependent on the TB roadmap, put a mittigation strategy in place to deal
with delays.
To increase the user base of Calendar / Lightning right now I think it
is important to satisfy to current (potential) users and give them peace
of mind. That generally means that bugs will be fixed and pressing
improvements are developed for immediate use.
I think the best risk management strategy is:
- Get to a final release (LN1.0) on Comm-1.9.2
- Continue with bug fixes on Comm-1.9.2
- Continue to improve existing functionality on the Comm-1.9.2
- Develop new features on trunk (M2.0)
- Release LN2.0 after TB has released a (proven) stable version based on
M2.0)
Marcel
gNeandr
resources of the calendar team. Only that one point
> - Continue to improve existing functionality on the Comm-1.9.2
Focusing further developments to the new platform (M2.0) *only* makes
much more sense.
For me the example with TB2/TB3
> When the decision was taken to stop developing for TB2 and focus on
> TB3, this risk was 100% accepted and no mitigation was done. This did
> not turn out to be the best decision as TB3 was delayed over and over
> again and users where left with a stale product.
sounds a bit different. TB2 was always supported with bug fixing /
security updates. New features dropped into TB3 only (AFAIR). So anybody
was able to decided for *his* TB solution.
I agree with Philipp
> We'll have to communicate this properly.
It's ALL about just that!
Günter
Marcel Berteler
> It seems Marcel point's are well aligned with the very limited resources
> of the calendar team. Only that one point
>> - Continue to improve existing functionality on the Comm-1.9.2
> seems not to be appropriated.
> Focusing further developments to the new platform (M2.0) *only* makes
> much more sense.
>
> For me the example with TB2/TB3
>> When the decision was taken to stop developing for TB2 and focus on
>> TB3, this risk was 100% accepted and no mitigation was done. This did
>> not turn out to be the best decision as TB3 was delayed over and over
>> again and users where left with a stale product.
> sounds a bit different. TB2 was always supported with bug fixing /
> security updates. New features dropped into TB3 only (AFAIR). So anybody
> was able to decided for *his* TB solution.
TB2 was supported with bug fixes, but LN0.9 was the last release that
supported TB2 and no bug fixes / security patches where done on the
calendar project. That was way before TB3 was even considered safe or
stable so there was no fair choice for the end user. They simply had to
wait for TB3 to be released.
on 2008/10/02 I posted this question:
----
Am I correct is saying that what ever bug fixes are committed to LN
after 0.9 release will not make it into a nightly or release that will
work on TB2 and I am forced to move to TB3?
----
to which Simon replied:
------
Yes, that is correct. We simply do not have the development resources to
continue supporting the 1.8 branch (and therefore TB2) and at the same
time making Lightning ready for TB3.
------
I do not want to turn this tread into a discussion about past decisions,
all I want to make sure is that the decisions that where made are
critically looked at by those that are about to make important decisions
soon.
The fact that roughly 2 years after LN0.9 was released we are still on a
beta release of LN1.0 must indicate that something went wrong and I
don't think this project can afford to continue like this.
The worst that can happen when continuing to enhance the TB3 version of
Calendar is that the TB4 version will have less functionality compared
to when all efforts are focused on a TB4 version.
The worst that can happen when NOT continuing with enhancements is that
users loose faith in the project because of lack of progress, especially
if TB deadlines and targets are changed once again.
> I agree with Philipp
>> We'll have to communicate this properly.
> It's ALL about just that!
>
I fully agree that communication is key, but this software is a tool not
a luxury item or a totally new product.
If Honda builds an electric car they can afford to take 5 years while
waiting for the battery technology to improve because it is a new market
segment and a new product. In the mean time, all people that need a car
to drive to work will buy a petrol car but not necessarily a Honda just
because Honda will bring out an electric car when the battery technology
is ready.
Calendar is not a new product and therefore people will not switch when
the next release is ready. People switch at certain points only: when
frustrated, when buying a new PC, when their IT department upgrades
their software, etc. This is happening daily so why not try and attract
as many users as possible as soon as possible instead of telling them:
'but our next release will be really great!'
Lets focus on giving people a sense of security by providing a road map
with defined steps and deadlines and stick to it. Unfortunately the
project relies on the TB team and therefore any date that relies on
other people (in this case the TB3 team) is not a deadline but a wish as
there is unfortunately no way the Calendar team can assist the TB team
with meeting their deadlines as there is just not enough resources to do
this.
This has to be accepted and the team needs to make clear to the end
users what their risk management strategy is: Accept a dependency on a
not yet released product (TB4) or mitigate this risk by relying on an
already released and stable product (TB3).
Which ever choice is made, I hope it affects the user base of calendar
positively and that soon TB and Calendar will rule every desktop on earth!!!
I seem to be ranting on and on.. time for one more glass of wine and a
good night sleep.
gNeandr
taken to stop ... " is only speaking about TB! And that's what I was
commenting! And all the discussion is ONLY about which track to support
and which one to bring forward.
Yes, Lightning has a dependency with TB. But with respect to the
resources they have this thread is about an acceptable way for *all*
parties. Don't overload it with unrealistic expectations, that will
never help.
So once more:
security and patches for the 'old' LG yes, but further developments
*only* with M2.0.
Günter
Marcel Berteler
> Just to make clear: the part of your posting "When the decision was
> taken to stop ... " is only speaking about TB! And that's what I was
> commenting!
Gunter, sorry to have confused you. When I stated "stop developing *for*
TB2" I was referring to the development of calendar for TB2, not the
development *of* TB2.
> Don't overload it with unrealistic expectations, that will
> never help.
>
Exactly my point. Be realistic and assume that TB4 will have delays and
mitigate this risk.
> So once more:
> security and patches for the 'old' LG yes, but further developments
> *only* with M2.0.
That is your opinion and I have voiced mine.
I hope others will join this tread and give Phillip what he asked for: A
discussion among the users / developers leading to a consensus on which
branch to use and when the next release will be.
Marcel
Alan Lord (News)
>
> I'd really appreciate some input from others too!
Lightning is a very important extension for TB (probably the most
important for me) and one that lets TB provide one of the few
alternatives to Outlook that is cross platform. Which provides a great
way to start migrating users off Proprietary software and Windows.
Almost all the other major desktop apps are now catered for: OOo,
Firefox, Chrome, Gimp, Inkscape etc.
My request is that Lightning is enhanced/fixed/developed in terms of
features & functionality *before* porting to TB4. If TB3 was anything to
go by, TB4 could be a long way away before it reaches stability/maturity.
So, if it were my decision, I'd concentrate on working on all the big
bugs/feature requests in the current lightning platform first, then,
when TB4 is nearing prime-time start the migration.
HTH
Al
Mark Banner
> My request is that Lightning is enhanced/fixed/developed in terms of
> features & functionality *before* porting to TB4. If TB3 was anything to
> go by, TB4 could be a long way away before it reaches stability/maturity.
I'd like to point out, that using TB 3 as a "benchmark" for development
cycles of TB versions is not a good thing. The time between TB 2 and TB
3 was filled firstly with a change of company/management, and then a new
development team.
A lot has been learnt in the TB 3 and TB 3.1 cycles by the new team, and
those lessons will continue to feed back into new development. Therefore
I think it highly unlikely that we'd have a release from trunk that is a
significant way off (we haven't yet decided if it would be called TB 4
or not).
Standard8
Munroe
I have been a long-time user of Lightning. I see lightning's greatest
value, when paired with calDAV, to help replace enterprise calendaring.
I have been trying to deploy lightning as a viable solution for a
while. We first tried with 0.5. My vote is to focus on the current TB
release and work on bug-fixes and calDAV support (as well as other
features). While I am sure the TB team has learned a lot about release
cycles, I think trying to anticipate the TB releases has ultimately hurt
the usability and adoption of Lightning.
If providing more features and bug-fixes to the current branch means
6-month or 10-month delay when TB 4 is released, I don't really see that
as a tremendous problem. People that rely on calendaring would rather
not upgrade to the latest and greatest Thunderbird and have a more
robust mail+calendaring solution than always waiting for the next
release to get the feature they need.
EricNo.SpamValette
> On 30/07/10 20:25, Philipp Kewisch wrote:
>>
>> I'd really appreciate some input from others too!
>
> Lightning is a very important extension for TB (probably the most
> important for me) and one that lets TB provide one of the few
> alternatives to Outlook that is cross platform. Which provides a great
> way to start migrating users off Proprietary software and Windows.
> Almost all the other major desktop apps are now catered for: OOo,
> Firefox, Chrome, Gimp, Inkscape etc.
I could not agree more. Unfortunately, the outlook compatibility has
still a long way to be fully workable, especially now that outlook 2007
version and soon 2010 version start finding they way in enterprise system.
You can more easily change clients than a complete mailing system when
changing the server means no solution for remaining outlook users.
> My request is that Lightning is enhanced/fixed/developed in terms of
> features & functionality *before* porting to TB4. If TB3 was anything to
> go by, TB4 could be a long way away before it reaches stability/maturity.
Some recent post have shown that in term of memory consumption and cpu
usage, thunderbird 3 itself has to mature a bit.
> So, if it were my decision, I'd concentrate on working on all the big
> bugs/feature requests in the current lightning platform first, then,
> when TB4 is nearing prime-time start the migration.
I agree. The temptation to never finish things and rush to new version
has been used in the past with TB2. We had to wait long for having TB3
and even longer to get lightning into a semi useable shape. The status
is still somewhat beta. If ths continue, people will soon refuse to
change to new version if they do not bring something valuable for them.
There are bugs open for TB2 and lightning that have a lot of vote and
continue to accumulate them. Have a look, fix them first. I can wait for
switching to TB4 if TB3 works as expected. In the past, you guys forced
me to switch to TB3 because lightning on TB2 was dead. I happily
switched to TB3 because of a long standing html parsing bug, font
resizing commutation bug that never got fixed in TB2.
--eric
Philipp Kewisch
but at that point we had the feeling that Thunderbird 3 was just
around the corner. The Thunderbird team was also confident that they
would release soon, but things just didn't work out as expected. Yes,
we accepted the risk and shot ourselves in the foot. This is a past
decision that we can't undo. I still think that focusing on trunk is
the right thing to do, but we clearly are in need for a strategy to
still be able to bring out releases on the last branch if things take
longer. Note also that since the number of developers shrunk, it was
even less easy to backport fixes to 0.9.
There are various reasons to focus on trunk rather than the last
stable release. Back when Thunderbird 3 was released and we weren't
ready with Lightning, we had numerous complaints why Lightning wasn't
working with Thunderbird 3. I can imagine that we have lost more than
a few users due to this, I do hope they'll come back. The only way out
of this is to actively support two branches: keep the trunk nightly in
shape for the upcoming release of Thunderbird, and continue to fix the
last branch release. As Simon correctly mentioned we don't have enough
developer resources to do this. Doing so means double the QA, more
programming work since we need to backport features. Given that the
mozilla platform and also Thunderbird change substantially between
branches this is not just checking in the trunk patches on branch. For
example, the mozilla 1.8. branch forced us to some very horrible hacks
that we are really glad we got rid of. These hacks costed our
developers a great amount of time that I think could better be used to
fix bugs on trunk.
> The worst that can happen when continuing to enhance the TB3 version of
> Calendar is that the TB4 version will have less functionality compared
> to when all efforts are focused on a TB4 version.
> The worst that can happen when NOT continuing with enhancements is that
> users loose faith in the project because of lack of progress, especially
> if TB deadlines and targets are changed once again.
I think we have come to a consensus, that releasing 1.0b3 from
comm-1.9.2 is the right thing to do. This does mean that we have to
manage two branches. To compensate for the larger amount of work, we
have to keep the number of backported fixes down, which means less
user visible changes, giving users the feeling that calendar project
work progresses more slowly.
To make sure that your first point is taken care of, we should stick
to the mozilla-way of doing things: features (or anything, for that
matter) land on trunk first, then may be backported to the last
branch. Alan, Munroe, sorry this doesn't conform to your request, but
if we don't do it this way, then we will really piss of users: since
features will first be available and then may vanish in a later
release due to lack of time to port it. If we block releases on
porting all features, then we will never be able to meet release
deadlines.
> The fact that roughly 2 years after LN0.9 was released we are still on a
> beta release of LN1.0 must indicate that something went wrong and I
> don't think this project can afford to continue like this.
Would you feel this way if we would have called it Lightning 0.9, then
0.10 instead of 1.0b1 and 0.11 instead of 1.0b2 ? Version numbers are
hell and its hard to decide on these, but I think we are just not
ready (from a performance perspective) for a 1.0 release. The label
"beta" doesn't degrade the quality of the project, it should just make
clear that its not an 1.0 yet.
> If Honda builds an electric car they can afford to take 5 years while
> waiting for the battery technology to improve because it is a new market
> segment and a new product. In the mean time, all people that need a car
> to drive to work will buy a petrol car but not necessarily a Honda just
> because Honda will bring out an electric car when the battery technology
> is ready.
So if Honda just had 4 volunteer engineers working on developing,
assembling and testing their cars, I'm sure they will stop producing
petrol cars and concentrate on the electric car so they can bring
their users newer, better technology instead ;-) Otherwise they'll be
far behind since other companies have far more, paid engineers to
build cars.
> Lets focus on giving people a sense of security by providing a road map
> with defined steps and deadlines and stick to it. Unfortunately the
> project relies on the TB team and therefore any date that relies on
> other people (in this case the TB3 team) is not a deadline but a wish as
> there is unfortunately no way the Calendar team can assist the TB team
> with meeting their deadlines as there is just not enough resources to do
> this.
We can probably set all the deadlines we want. Unless we are very
pessimistic, its really hard to stick to deadlines on a volunteer
project. We do try to fulfill them, but its not that easy. About
defining steps, we do have a blocking list for 1.0 final and I will be
proposing a 1.0b3 roadmap soon. We try to release every 4 months, but
this usually turns out to be more due to various factors (including
but not limited to release engineering, last minute blockers, review
time, regressions).
So let me summarize what I think is the right path to continue:
* We will release 1.0b3 from comm-1.9.2, which will make it compatible
to Tb3.next
-- NOTE: It will at least be binary compatible with Tb3.1.x, but I'm
not sure we should officially support this (doubles QA again)
* Bugs and features will be fixed on trunk first and backported if
approved.
* Releasing from comm-1.9.2 will make project advancement seem slower,
this sucks but there's no way around it.
* We need to communicate things properly.
* Version numbers are hell!
Given the above considerations, do you all agree?
Philipp
Philipp Kewisch
> I agree that the decision to move to TB3 might not have been the best,
Of course I mean the past decision to switch development to tb3.0
without a strategy in case things go wrong, don't get me wrong. I'm
glad we were able to move to the code base of Thunderbird 3.0, lots of
things just got much easier!
Philipp
Munroe
I agree with everything. You make some good points. My only
thought/concern to add is that TB4 development seems to be non-existent.
I don't see discussion on the thunderbird-dev newsgroup, nor on the
wiki anywhere. Most of the chatter I see is in reference to TB3.2 or
older. Is TB 4 even being planned yet? or is TB4 just going to be a
port of tb3.2 onto gecko-2.0?
Ricardo Palomares Martínez
> So let me summarize what I think is the right path to continue:
>
>
> * We will release 1.0b3 from comm-1.9.2, which will make it compatible
> to Tb3.next
> -- NOTE: It will at least be binary compatible with Tb3.1.x, but I'm
> not sure we should officially support this (doubles QA again)
> * Bugs and features will be fixed on trunk first and backported if
> approved.
> * Releasing from comm-1.9.2 will make project advancement seem slower,
> this sucks but there's no way around it.
> * We need to communicate things properly.
> * Version numbers are hell!
>
>
> Given the above considerations, do you all agree?
Playing selfish, I really like it, :-) since I use Lightning on
SeaMonkey and concentrating Calendar on Gecko-1.9.2 would mean no new
features at all on SeaMonkey for a long time.
I know that working in trunk doesn't mean that Lightning nightlies can
work on SeaMonkey 2.1, but it makes it slightly more feasible. :-)
Ricardo
Philipp Kewisch
> I agree with everything. You make some good points. My only
> thought/concern to add is that TB4 development seems to be non-existent.
> I don't see discussion on the thunderbird-dev newsgroup, nor on the
> wiki anywhere. Most of the chatter I see is in reference to TB3.2 or
> older. Is TB 4 even being planned yet? or is TB4 just going to be a
> port of tb3.2 onto gecko-2.0?
I believe TB4 was only mentioned as a placeholder. The version numbers
aren't really final yet.
The current 3.2 is off Mozilla 2.0
There will most likely be an intermediate version of Thunderbird thats
based on 1.9.2, the version number is unknown.
In this thread, I guess TB4 = Thunderbird off Mozilla 2.0 (which is
currently labeled Thunderbird 3.2a1pre)
Philipp
Munroe Sollog
Ahah! That makes a lot of sense now. Thanks for clearing that up.
Mark Banner
>> beta release of LN1.0 must indicate that something went wrong and I
>> don't think this project can afford to continue like this.
>
> Would you feel this way if we would have called it Lightning 0.9, then
> 0.10 instead of 1.0b1 and 0.11 instead of 1.0b2 ? Version numbers are
> hell and its hard to decide on these, but I think we are just not
> ready (from a performance perspective) for a 1.0 release. The label
> "beta" doesn't degrade the quality of the project, it should just make
> clear that its not an 1.0 yet.
I actually saw a lot of comments from TB 2 up-graders along the lines of
the fact that we were forcing them to use a "beta" version. This is not
to say the next version should be 1.0, but users do read a lot into the
beta label and it probably doesn't help it is the only one available for
those TB version.
Standard8
Wayne Mery
(understand the technical reasons for the beta label but ...)
It probably also hurts adoption and perhaps even testing by people who
are not yet running it - which is OK if that is part of the rationale
for labeling it as beta. It also reflects badly on Thunderbird, along
the lines of Mark's comment.
--
QA/bugzilla advice ...
http://www.mibbit.com/chat/?server=irc.mozilla.org&channel=#tb-qa
evangelize ... http://www.spreadthunderbird.com/aff/165/
you can help with ... http://wiki.mozilla.org/Thunderbird:Testing
Robert Kaiser
> (understand the technical reasons for the beta label but ...)
>
> It probably also hurts adoption and perhaps even testing by people who
> are not yet running it - which is OK if that is part of the rationale
> for labeling it as beta.
There's also the fact that it's quite confusing to people that you're
jumping branches between mere betas. But then, I guess that's a decision
for the calendar team to make.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
Marcel Berteler
>
>
> So let me summarize what I think is the right path to continue:
>
>
> * We will release 1.0b3 from comm-1.9.2, which will make it compatible
> to Tb3.next
> -- NOTE: It will at least be binary compatible with Tb3.1.x, but I'm
> not sure we should officially support this (doubles QA again)
> * Bugs and features will be fixed on trunk first and backported if
> approved.
> * Releasing from comm-1.9.2 will make project advancement seem slower,
> this sucks but there's no way around it.
> * We need to communicate things properly.
> * Version numbers are hell!
>
>
> Given the above considerations, do you all agree?
>
> Philipp
I like your proposal, mainly because it is well through through, backed
up by arguments and takes the end-user into consideration. We can debate
about opinions but I really appreciate your lengthy well constructed
objective reply.
As for the version numbers, my personal preference would be to skip
alpha and beta release numbering if these releases are not really meant
to become a final release. What I mean with this is that I would expect
a beta release to be released as a final if no -new- bugs are found. At
the moment it looks more like the next release is going to be 0.9Gamma
;-) Rather continue numbering 0.10, 0.11, etc if you are not happy to
call it 1.0 yet. But as you said, version numbers are hell and it does
not change the stability of the product.
Marcel