Heading towards Calendar 1.0 Beta 1
Philipp Kewisch
of Sunbird/Lightning that fits together well. Due to other obligations
this goal has slipped quite a bit. We have tagged the list of blocking
bugs [1] by bugs needed for the beta and those we can move into the
next beta.
Currently, there is only one bug [2] left that we really need to solve
for this beta. It has a preliminary patch and will require string
changes. Unfortunately, the mentioned bug is not quite trivial, since
a lot of UI changes need to be done and we haven't quite agreed on
some aspects.
This means we will announce a string freeze as soon as the bug has
been fixed and release 2 weeks afterwards, or sooner if all strings
have been translated earlier.
Nevertheless, we'd like to provide a beta as soon as possible. To help
make this possible what we need most at the moment is testing! Please
download Thunderbird 3 Beta 2 at:
http://www.mozillamessaging.com/en-US/thunderbird/3.0b2/
And our latest nightly version of Lightning:
ftp://ftp.mozilla.org/pub/calendar/lightning/nightly/latest-comm-central/
Be sure to back up your data before using this version, since it
upgrades your local storage database. Downgrading is not easily
possible afterwards without creating a new profile.
IMPORTANT:Note however as we've announced in an earlier blog post [3]
this will be the last release for the time being that includes
Sunbird. This means that now more than ever, testing is needed to make
sure that Sunbird doesn't contain any critical bugs.
If you want future Sunbird releases to happen and either have
experience with the Mozilla build architecture or are willing to
learn, please do send me an Email and I'll send you some information
to get you started.
We will make an effort towards releasing more beta versions of
Lightning on the road towards 1.0 to make sure the next release will
be as bug-free as possible and still contain the nice new features we
have been working on. Remember that we need you to fulfill this goal!
Without your valuable testing, we will surely be up for a surprise in
case a critical bug has made it into the final version without notice.
Philipp
[1]
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Calendar&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=flagtypes.name&type0-0-0=substring&value0-0-0=blocking&field0-1-0=flagtypes.name&type0-1-0=substring&value0-1-0=%2B&columnlist=bug_id,short_desc,status_whiteboard&order=status_whiteboard,bug_id
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=456385
[3] http://weblogs.mozillazine.org/calendar/2009/02/calendar_project_at_a_critical.html
Stefan Sitter
> IMPORTANT:Note however as we've announced in an earlier blog post
> [3] this will be the last release for the time being that
> includes Sunbird. This means that now more than ever, testing is
> needed to make sure that Sunbird doesn't contain any critical
> bugs.
Do you mean Sunbird 1.0 Beta 1 will be the last release? Or Sunbird
1.0? In the former case I'd say that at least all the blocking1.0
bugs must be fixed first.
I hope you do not plan to turn off the Sunbird build servers
afterwards. Without the nightly builds it will be impossible to
attract new developers I'd say.
Simon Paquet
>> IMPORTANT:Note however as we've announced in an earlier blog post
>> [3] this will be the last release for the time being that
>> includes Sunbird. This means that now more than ever, testing is
>> needed to make sure that Sunbird doesn't contain any critical
>> bugs.
>
>Do you mean Sunbird 1.0 Beta 1 will be the last release?
Yes.
>Or Sunbird 1.0?
No.
>In the former case I'd say that at least all the blocking1.0 bugs
>must be fixed first.
I disagree. We should proceed. And proceeding means releasing once in a
while. It's sad that Sunbird has to go, but repeated requests for a new
maintainer have not sparked a response, so there's really nothing we can
do that would not adversely affect Lightning on the other hand.
>I hope you do not plan to turn off the Sunbird build servers afterwards.
We haven't really spoken about that. But I'd say, that without a future
Sunbird release, it doesn't make any sense to let the build servers
produce Sunbird builds any longer. Those servers could surely be put to
better use of their resources.
>Without the nightly builds it will be impossible to attract new
>developers I'd say.
Why? There's still Lightning around.
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
Martin Feitag
> Stefan Sitter wrote:
>
>>> IMPORTANT:Note however as we've announced in an earlier blog post
>>> [3] this will be the last release for the time being that
>>> includes Sunbird. This means that now more than ever, testing is
>>> needed to make sure that Sunbird doesn't contain any critical
>>> bugs.
>> Do you mean Sunbird 1.0 Beta 1 will be the last release?
>
> Yes.
>
>> Or Sunbird 1.0?
>
> No.
You won't even release a final Sunbird 1.0?
That's bad :-/
Stefan Sitter
> Stefan Sitter wrote:
>> Do you mean Sunbird 1.0 Beta 1 will be the last release?
>
> Yes.
>
>> Or Sunbird 1.0?
>
> No.
>
>> In the former case I'd say that at least all the blocking1.0
>> bugs must be fixed first.
>
> I disagree. We should proceed. And proceeding means releasing
> once in a while. It's sad that Sunbird has to go, but repeated
> requests for a new maintainer have not sparked a response, so
> there's really nothing we can do that would not adversely affect
> Lightning on the other hand.
This doesn't sounds like a good plan. I suggest to skip Sunbird
1.0b1 and release only Lightning 1.0b1. Later release a stable
Sunbird 1.0 together with Lightning 1.0 that contains the bug
fixes.
>> I hope you do not plan to turn off the Sunbird build servers
>> afterwards.
>
> We haven't really spoken about that. But I'd say, that without a
> future Sunbird release, it doesn't make any sense to let the
> build servers produce Sunbird builds any longer. Those servers
> could surely be put to better use of their resources.
>
>> Without the nightly builds it will be impossible to attract new
>> developers I'd say.
>
> Why? There's still Lightning around.
As long as nightly builds exist Sunbird users and contributors like
me can test them and provide patches for Sunbird and calendar
features. If no builds exists it is much harder to attract new
Sunbird testers and contributors.
In my opinion it is much easier to test calendaring functionality in
Sunbird compared to Lightning. For example I would not test an
regression as in Bug 463978 in Lightning. With Lightning you need to
test multiple Lightning builds against multiple Thunderbird builds,
especially if you don't know if it is a toolkit or calendar
regression. With Sunbird you just test build by build.
If the server cycles are required for other jobs I could imagine the
following: Turn off only the 'sunbird build' servers but keep the
'sunbird nightly' servers.
/Stefan
Simon Paquet
Please read this post
|From: Philipp Kewisch <kew...@gmail.com>
|Newsgroups: mozilla.dev.apps.calendar
|Subject: Calendar Project at a critical juncture
|Date: Thu, 19 Feb 2009 07:47:34 -0800 (PST)
|Message-ID: <643d23de-15fc-4a96...@r41g2000yqm.googlegroups.com>
and the accompanying discussion as well as
http://weblogs.mozillazine.org/calendar/2009/02/calendar_project_at_a_critical.html
and
http://weblogs.mozillazine.org/calendar/2009/02/more_on_the_sunbirdlightning_d.html
Simon Paquet
>>> In the former case I'd say that at least all the blocking1.0
>>> bugs must be fixed first.
>>
>> I disagree. We should proceed. And proceeding means releasing
>> once in a while. It's sad that Sunbird has to go, but repeated
>> requests for a new maintainer have not sparked a response, so
>> there's really nothing we can do that would not adversely affect
>> Lightning on the other hand.
>
>This doesn't sounds like a good plan. I suggest to skip Sunbird
>1.0b1 and release only Lightning 1.0b1. Later release a stable
>Sunbird 1.0 together with Lightning 1.0 that contains the bug
>fixes.
We're doing this, because we don't want to put any more developer
resources into keeping Sunbird alive. Your proposal would run counter to
that.
>>> Without the nightly builds it will be impossible to attract new
>>> developers I'd say.
>>
>> Why? There's still Lightning around.
>
>As long as nightly builds exist Sunbird users and contributors like
>me can test them and provide patches for Sunbird and calendar
>features. If no builds exists it is much harder to attract new
>Sunbird testers and contributors.
>
>In my opinion it is much easier to test calendaring functionality in
>Sunbird compared to Lightning. For example I would not test an
>regression as in Bug 463978 in Lightning. With Lightning you need to
>test multiple Lightning builds against multiple Thunderbird builds,
>especially if you don't know if it is a toolkit or calendar
>regression. With Sunbird you just test build by build.
As far as I know the plan is to let the Sunbird build machines produce
integrated Thunderbird builds instead (TB + LT in one package). That
would alleviate your concerns, right?
Martin Feitag
> Martin Feitag wrote:
>
>>>>> IMPORTANT:Note however as we've announced in an earlier blog post
>>>>> [3] this will be the last release for the time being that
>>>>> includes Sunbird. This means that now more than ever, testing is
>>>>> needed to make sure that Sunbird doesn't contain any critical
>>>>> bugs.
>>>> Do you mean Sunbird 1.0 Beta 1 will be the last release?
>>> Yes.
>>>
>>>> Or Sunbird 1.0?
>>> No.
>> You won't even release a final Sunbird 1.0?
>> That's bad :-/
>
> Please read this post
>
> |From: Philipp Kewisch<kew...@gmail.com>
> |Newsgroups: mozilla.dev.apps.calendar
> |Subject: Calendar Project at a critical juncture
> |Date: Thu, 19 Feb 2009 07:47:34 -0800 (PST)
> |Message-ID:<643d23de-15fc-4a96...@r41g2000yqm.googlegroups.com>
>
> and the accompanying discussion as well as
> http://weblogs.mozillazine.org/calendar/2009/02/calendar_project_at_a_critical.html
> and
> http://weblogs.mozillazine.org/calendar/2009/02/more_on_the_sunbirdlightning_d.html
>
> Simon Paquet
The first site said "Our next release will include Sunbird, but
subsequent releases won't [...]"
I don't consider a beta a "release", I was assuming 1.0 final (or gold
or however that may be called) would be the last real release. :-S
John Vivirito
>>> IMPORTANT:Note however as we've announced in an earlier blog post
>>> [3] this will be the last release for the time being that
>>> includes Sunbird. This means that now more than ever, testing is
>>> needed to make sure that Sunbird doesn't contain any critical
>>> bugs.
>> Do you mean Sunbird 1.0 Beta 1 will be the last release?
> Yes.
>
>> Or Sunbird 1.0?
> No.
I really hate to see Sunbird go. I personally love having a stand alone
calendar.
On this PC Lightning slows Thunderbird down. Is there something we can
do to help keep Sunbird alive?
> You won't even release a final Sunbird 1.0?
Is this really a good idea or will beta1 Be close to being a final
stable release.
when i say stable release i mean are all critical bugs will be fixed,
however UI bugs wont be fixed/applied after/before release of beta1?
> I don't consider a beta a "release", I was assuming 1.0 final (or gold
> or however that may be called) would be the last real release. :-S
I agree here beta isn't a real release. however i do understand not
wanted to put developers on something that is going to die. I would love
to see a final release so i can package it and include it in Ubuntu
repos and by not releasing a final release i will be unable to
officially add it in any Ubuntu release.
--
Sincerely Yours,
John Vivirito
https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246
"How can i get lost, if i have no where to go"
-- Metallica from Unforgiven III
Mark Banner
> On this PC Lightning slows Thunderbird down. Is there something we can
> do to help keep Sunbird alive?
Help lead and drive Sunbird development? (as has already been indicated
earlier in this thread).
Alternately, why not help sort out the performance issues so that
Lightning doesn't slow Thunderbird down?
Standard8
Simon Paquet
> I really hate to see Sunbird go. I personally love having a stand
> alone calendar.
> On this PC Lightning slows Thunderbird down. Is there something
> we can do to help keep Sunbird alive?
As outlined in the blog posts that I referenced earlier
| 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.
if someone (you?) steps up to keep Sunbird alive and running, we can
surely do Sunbird releases after 1.0 beta. This is a resource-issue
after all, nothing more, nothing less.
>> You won't even release a final Sunbird 1.0?
>
> Is this really a good idea or will beta1 be close to being a final
> stable release.
We hope that it will be better than 0.9. How close it will be to the
1.0 final is not something that I can comment on without a big
crystal bowl to look into.
There are old adages that the only problem with predictions is that
they concern the future. :-)
>> I don't consider a beta a "release", I was assuming 1.0 final
>> (or gold or however that may be called) would be the last real
>> release. :-S
>
> I agree here beta isn't a real release.
1.0 beta is as much a release as was 0.3, 0.5, 0.7, 0.8 or 0.9.
Simon
Stefan Sitter
> Stefan Sitter wrote:
>> 1.0b1 and release only Lightning 1.0b1. Later release a stable
>> Sunbird 1.0 together with Lightning 1.0 that contains the bug
>> fixes.
>
> We're doing this, because we don't want to put any more developer
> resources into keeping Sunbird alive. Your proposal would run
> counter to that.
>
>> like me can test them and provide patches for Sunbird and
>> calendar features. If no builds exists it is much harder to
>> attract new Sunbird testers and contributors.
>
> produce integrated Thunderbird builds instead (TB + LT in one
> package). That would alleviate your concerns, right?
Speaking for myself the opposite is true. If Sunbird is stopped
completely, all build servers are terminated and contributors are
discouraged to work on Sunbird I don't see any reason for further
contributions to the calendar project.
From my current understanding I thought that Sunbird is put on hold
until a new maintainer shows up. Unfortunately I don't have enough
time to work full time on this topic. But as long as Sunbird is just
put on hold there is hope that maybe someone shows up. During that
time I can continue testing Sunbird and contribute patches if time
permits.
/Stefan
Stefan Sitter
> 1.0 beta is as much a release as was 0.3, 0.5, 0.7, 0.8 or 0.9.
I disagree. In the previous releases new features were stabilized,
finalized if possible and the most painful errors and regressions
(i.e. the blocking bugs) were fixed before release. Your other
answer to me indicates that this is not planed for 1.0 beta.
That means we would release an unfinished build based on a new
platform with know errors and regressions. In that case it might be
better to stay with 0.9.
I still don't understand the difference between spending resources
now on doing a Sunbird 1.0 beta release versus spending the same
resources in two or three months on doing a Sunbird 1.0 release
release instead.
/Stefan
Simon Paquet
> Simon Paquet wrote:
>> 1.0 beta is as much a release as was 0.3, 0.5, 0.7, 0.8 or 0.9.
> I disagree. In the previous releases new features were stabilized,
> finalized if possible and the most painful errors and regressions
> (i.e. the blocking bugs) were fixed before release. Your other
> answer to me indicates that this is not planed for 1.0 beta.
I don't know the specifics. You would have to ask Philipp. He is the
project lead, so its his choice.
Sebastian Schwieger
FWIW, I agree with Stefan and Martin, that the last official release of
Sunbird should be a real release, not just a beta version. Skipping the
QA work for a Sunbird 1.0 beta release in favour of a final Sunbird 1.0
release sounds like a good plan to me.
If keeping the Sunbird build machines is a big help for the QA process,
as Stefan repeatedly tried to explain, then please consider keeping
those alive even after the 1.0 timeframe.
I'm happy to help out as time permits.
Just my two cents,
Sebo
Dan Mosedale
>
> FWIW, I agree with Stefan and Martin, that the last official release of
> Sunbird should be a real release, not just a beta version. Skipping the
> QA work for a Sunbird 1.0 beta release in favour of a final Sunbird 1.0
> release sounds like a good plan to me.
Unfortunately, that has several problems:
* it would set exactly the wrong expectation for end-users: it would be
encouraging them to entrust their data to an application which is likely
to not move forward
* it would lead to shipping a buggy version of Sunbird 1.0
* Sunbird would continue to exert drag on Lightning until 1.0 shipped.
Dan
Dan Mosedale
>> I disagree. We should proceed. And proceeding means releasing
>> once in a while. It's sad that Sunbird has to go, but repeated
>> requests for a new maintainer have not sparked a response, so
>> there's really nothing we can do that would not adversely affect
>> Lightning on the other hand.
>
> This doesn't sounds like a good plan. I suggest to skip Sunbird 1.0b1
> and release only Lightning 1.0b1. Later release a stable Sunbird 1.0
> together with Lightning 1.0 that contains the bug
> fixes.
The problem is that there's no guarantee (or even likelihood, given past
experience) that anyone will sign up to do that work at some later date.
Trading off one certain final release now against the small
probability of a release later doesn't seem fair to existing users.
> As long as nightly builds exist Sunbird users and contributors like me
> can test them and provide patches for Sunbird and calendar features. If
> no builds exists it is much harder to attract new Sunbird testers and
> contributors.
This is a fair point.
> If the server cycles are required for other jobs I could imagine the
> following: Turn off only the 'sunbird build' servers but keep the
> 'sunbird nightly' servers.
I'd be interested in hearing from gozer (who does the work of running
those servers): if he feels that the effort and hardware costs are
sufficiently low, in principle it would seem reasonable to leave them on
for a little while as long as those costs stay low. That said, if they
break for whatever reason, I'd expect it wouldn't be worth investing the
effort in fixing it unless Sunbird had significantly more contributors
than it does now.
Dan
Dan Mosedale
> Speaking for myself the opposite is true. If Sunbird is stopped
> completely, all build servers are terminated and contributors are
> discouraged to work on Sunbird I don't see any reason for further
> contributions to the calendar project.
You've done a lot of great work for the calendar project over the years;
it will make me sad if you decide to stop contributing entirely. I can
think of a bunch of great ways you could use your talents to make
Lightning better.
Dan
Dan Mosedale
> Simon Paquet wrote:
>> 1.0 beta is as much a release as was 0.3, 0.5, 0.7, 0.8 or 0.9.
>
> I disagree. In the previous releases new features were stabilized,
> finalized if possible and the most painful errors and regressions (i.e.
> the blocking bugs) were fixed before release. Your other answer to me
> indicates that this is not planed for 1.0 bet
My reading of Philipp's post was that the current belief is that the
nightlies are sufficiently stable for beta as they are now. Do you
disagree?
> That means we would release an unfinished build based on a new platform
> with know errors and regressions. In that case it might be better to
> stay with 0.9.
Worth considering, perhaps, if I'm wrong above.
> I still don't understand the difference between spending resources now
> on doing a Sunbird 1.0 beta release versus spending the same resources
> in two or three months on doing a Sunbird 1.0 release release instead.
I suspect I can answer your question above, but I first need to
understand what branches of which repositories Sunbird nightlies are
currently being built from. Do you know?
Dan
Martin Feitag
> On 4/1/09 4:18 AM, Sebastian Schwieger wrote:
>> FWIW, I agree with Stefan and Martin, that the last official release of
>> Sunbird should be a real release, not just a beta version. Skipping the
>> QA work for a Sunbird 1.0 beta release in favour of a final Sunbird 1.0
>> release sounds like a good plan to me.
>
> Unfortunately, that has several problems:
>
> * it would set exactly the wrong expectation for end-users: it would be
> encouraging them to entrust their data to an application which is likely
> to not move forward
Why would a final version (which could be declared as "that's it, no new
version planned atm") lead to expectations more than a beta? I beta
always sounds like it's on the way to final (at least for me and other
people in my surrounding)
> * it would lead to shipping a buggy version of Sunbird 1.0
Why that? It shouldn't be more buggy than 1.0 beta o_0
(I'm not into it so maybe an explanation can shed some light on that)
> * Sunbird would continue to exert drag on Lightning until 1.0 shipped.
As long as Lightning doesn't work with Seamonkey2.0 for instance and
nothing but Thunderbird there a people who can't/don't want to "migrate"
anyway, as switching to TB is not their intention.
Working with a (stable) final until there is a solution would be nice.
I doubt I can help as a non-programmer otherwise feel free to point me
in the right direction if an 1.0 final is considered possible with
additional help without real coding.
regards
Martin
John Vivirito
>> * Sunbird would continue to exert drag on Lightning until 1.0 shipped.
>
> As long as Lightning doesn't work with Seamonkey2.0 for instance and
> nothing but Thunderbird there a people who can't/don't want to
> "migrate" anyway, as switching to TB is not their intention.
> Working with a (stable) final until there is a solution would be nice.
really see what supporting Seamonkey-2.0 is bad idea?
At this time I don't see a calendar for Seamonkey-2.0.
Simon Paquet
> I doubt I can help as a non-programmer
Far from it. There are lots of ways that you can help as a
non-programmer.
> otherwise feel free to point me in the right direction if an 1.0
> final is considered possible with additional help without real coding.
I wrote about this on the calendar blog back in July 2008. See the
article here:
http://weblogs.mozillazine.org/calendar/2008/07/simons_notes_contributing_to_the.html
What this article totally misses is QA work, e.g.
- bug identification,
- bug confirmation
- testcase writing
- finding regression windows
- triaging bugs in bugzilla
- verifying bug fixes in nightly builds
- etc.
So let me know, where you want to help and I can point you in the
right direction.
Cya
Robert Kaiser
> On 04/02/2009 06:03 AM, Martin Feitag wrote:
>>> * Sunbird would continue to exert drag on Lightning until 1.0 shipped.
>>
>> As long as Lightning doesn't work with Seamonkey2.0 for instance and
>> nothing but Thunderbird there a people who can't/don't want to
>> "migrate" anyway, as switching to TB is not their intention.
>> Working with a (stable) final until there is a solution would be nice.
> I would love to see support for Seamonkey-2.0 and Lightning. I dont
> really see what supporting Seamonkey-2.0 is bad idea?
> At this time I don't see a calendar for Seamonkey-2.0.
The SeaMonkey team is working on getting SeaMonkey 2 into a state where
Lighting can work with it, but we're not yet there. For the final
release, we want to have this up and running.
Robert Kaiser
Dan Mosedale
> Dan Mosedale schrieb:
>> On 4/1/09 4:18 AM, Sebastian Schwieger wrote:
>>> FWIW, I agree with Stefan and Martin, that the last official release of
>>> Sunbird should be a real release, not just a beta version. Skipping the
>>> QA work for a Sunbird 1.0 beta release in favour of a final Sunbird 1.0
>>> release sounds like a good plan to me.
>>
>> Unfortunately, that has several problems:
>>
>> * it would set exactly the wrong expectation for end-users: it would be
>> encouraging them to entrust their data to an application which is likely
>> to not move forward
>
> Why would a final version (which could be declared as "that's it, no new
> version planned atm") lead to expectations more than a beta? I beta
> always sounds like it's on the way to final (at least for me and other
> people in my surrounding)
You've made a good point that there are actually two separable things
going on here:
* generally speaking, releasing something and calling it 1.0 sets the
expectation that the software is going to be maintained (security
updates), and, typically, further developed. Conveying the message to
people that this 1.0 program is different would be very difficult:
people don't tend to read things like release notes, and dialogs that
interrupt users' workflow are typically just clicked through without
reading.
* You're right that releasing a beta has the same problem. Perhaps we
should investigate some other way to name this final Sunbird release,
such as 0.95.
>> * it would lead to shipping a buggy version of Sunbird 1.0
>
> Why that? It shouldn't be more buggy than 1.0 beta o_0
> (I'm not into it so maybe an explanation can shed some light on that)
Because the core calendar code and Gecko will be continuing to evolve
without the Sunbird code getting QA coverage as that happens. This
tends to lead to bugs creeping in. Additionally, there is implicitly a
higher quality bar for a 1.0 version than for a beta version.
>> * Sunbird would continue to exert drag on Lightning until 1.0 shipped.
>
> As long as Lightning doesn't work with Seamonkey2.0 for instance and
> nothing but Thunderbird there a people who can't/don't want to "migrate"
> anyway, as switching to TB is not their intention.
> Working with a (stable) final until there is a solution would be nice.
One of the things that has been discussed in the past was the idea of
making a Thunderbird extension that simply hides all the mail-related
chrome entirely, so that Tb + Ltn + that extension could be used in a
style similar to Sunbird. If someone is interested in writing such a
thing, that might actually be the best way to service the users who
liked Sunbird better.
Dan
John Vivirito
> dev-apps-calendar mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-calendar
>
Thanks for the update.
Archaeopteryx
> should investigate some other way to name this final Sunbird release,
> such as 0.95.
if the current appVersion is the highest appVersion used with this
profile and if this isn't true, it will terminate the application.
> One of the things that has been discussed in the past was the idea of
> making a Thunderbird extension that simply hides all the mail-related
> chrome entirely, so that Tb + Ltn + that extension could be used in a
> style similar to Sunbird. If someone is interested in writing such a
> thing, that might actually be the best way to service the users who
> liked Sunbird better.
This also requires changes to the Thunderbird build, you need
"-no-remote" for one running process of Thunderbird and "Sunbird fake".
I had already asked when the Sunbird end of development was announced
and imho it's important to know that: What would be needed to be done to
keep Sunbird alive? Always reading "Sunbird needs contributors" without
further info isn't very helpful.
Archaeopteryx
Philipp Kewisch
newsgroups.
We indeed haven't talked about the build servers but unless the
hardware costs are immense (which I don't believe) I think nothing
speaks against keeping the build servers running. If we want to use
those machines to build a joint Thunderbird+Lightning, I think the
most reasonable thing to do is rather to cut down the number of
Sunbird builds (i.e no hourly builds, just nightly builds) rather than
turning them off completely. The initial barrier for getting involved
with Sunbird development will be much higher if setting up nightly
builds is the first thing the new leader has to do.
Since many people have asked what is needed to keep Sunbird alive, I
will follow up with a blog post soon (tm), also mentioning our ideas
on stripping down Thunderbird to only provide calendar features if
this is wanted in the long run. This might make it easier for new
contributors to step up. I apologize for not having thought of this
earlier.
Regarding the stability of the current releases, we are down to 14
blocker bugs. Even if the list stays like it is, I believe we are in
pretty good shape, with exception of the two bugs marked as major. We
have tagged some bugs in the whiteboard that should block 1.0beta1. I
will continue to stabilize and finalize features as long as the
strings bug is pending a decision. Stefan, again looking at this list
(please include the two major bugs) do you feel that a beta release
with these bugs open has sufficient quality for a final release of
Sunbird?
I'm open to calling the next Sunbird release Sunbird 0.9.5 to resolve
the expections put on 1.0 beta and 1.0 final versions, any objections
to doing so? The only ones I can think of is that it might give people
the feeling that it is built on mozilla-1.8, but since this
expectation is limited to geek mozilla users, I think its ok. Last I
looked, Sunbird is currently using a mozilla-1.9.1 toolkit.
Archaeopteryx, the script you are talking about, isn't this limited to
the storage database versions? In this case I think we are fine,
regardless of what we name the product version. Or is there some other
script?
I hope this answers some questions. One last thing: I want you all to
know that I am interested in finding solution we can all live with.
Although this is often not possible, I'm open to a change of plans in
case of reasonable requests that don't hinder work on lightning
excessively.
Philipp
Stefan Sitter
> Stefan Sitter wrote:
>> I still don't understand the difference between spending
>> resources now on doing a Sunbird 1.0 beta release versus
>> spending the same resources in two or three months on doing a
>> Sunbird 1.0 release release instead.
>
> I suspect I can answer your question above, but I first need to
> understand what branches of which repositories Sunbird nightlies
> are currently being built from. Do you know?
http://hg.mozilla.org/comm-central/
http://hg.mozilla.org/releases/mozilla-1.9.1/
http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/
Stefan
Simon Paquet
>Since many people have asked what is needed to keep Sunbird alive, I
>will follow up with a blog post soon (tm), also mentioning our ideas
>on stripping down Thunderbird to only provide calendar features if
>this is wanted in the long run.
Good idea.
>This might make it easier for new contributors to step up. I
>apologize for not having thought of this earlier.
One thing we also need to fix before we let Sunbird rest in peace is the
localization story of Lightning.
Currently localizers get localized Sunbird builds on a daily basis if
their localization is green. This is invaluable for testing purposes.
This is currently not possible for Lightning and is a major hurdle that
was already mentioned at FOSDEM 2009.
Any idea on how we can fix that?
Simon Paquet
Hubert Gajewski
> Currently localizers get localized Sunbird builds on a daily basis if
> their localization is green. This is invaluable for testing purposes.
> This is currently not possible for Lightning and is a major hurdle that
> was already mentioned at FOSDEM 2009.
>
> Any idea on how we can fix that?
Deliver nightly xpi packages for each locale separately.
--
Hubert Gajewski
Aviary.pl
http://www.aviary.pl
Martin Feitag
> Martin Feitag wrote on 02. Apr 2009:
>
>> I doubt I can help as a non-programmer
>
> Far from it. There are lots of ways that you can help as a
> non-programmer.
>
>> otherwise feel free to point me in the right direction if an 1.0
>> final is considered possible with additional help without real coding.
>
> I wrote about this on the calendar blog back in July 2008. See the
> article here:
>
> http://weblogs.mozillazine.org/calendar/2008/07/simons_notes_contributing_to_the.html
>
> What this article totally misses is QA work, e.g.
> - bug identification,
> - bug confirmation
> - testcase writing
> - finding regression windows
> - triaging bugs in bugzilla
> - verifying bug fixes in nightly builds
> - etc.
>
> So let me know, where you want to help and I can point you in the
> right direction.
>
> Cya
> Simon
>
Without being a (web-)developer and PR-guy (English is not my mother
tongue), I'm left with the followig I guess:
* Development of a real project roadmap
* More developer documentation
* Regular user polls
* Creation of a list of easy to fix bugs
according to your text. (or QA mentioned here)
Judging easy to fix bugs *might* be possible with (my) limited
understanding of code, but I am wondering how a non-programmer can write
roadmaps or even developer documentation? Because all such things I've
seen require detailed knowledge of interfaces or similar of the code of
a project (but maybe I will become enlight(en)ed now ;-))
If none of the above apply to my abilities, QA would be fine too I guess
regards
Martin
Philipp Kewisch
(litmus.mozilla.org) into mozmill tests.
There is a new tool called mozmill [1] that can be used to record
automated tests in Mozilla applications. The goal is to be able to run
this tool with the usual build process [2]. Before this tool came
along,
we lived with manual testing from our full-time QA and a couple of
part
time community members. Until now, we have recorded/written only one
test [3].
We have a tool called litmus [4] where all manual tests are kept. I
think it would be a good start to convert all possible litmus tests
into
automated tests.
Since mozmill is in a quite early stage, there are some bugs and
missing
features that might require a bit getting used to or writing
javascript,
but I think its quite straightforward.
For you to get started, I'd recommend to get the latest thunderbird
nightly [5] (or tb3 beta 2 when it comes out) together with the latest
lightning nightly [6]. Then you'll have to install the latest SVN
version of mozmill [7] (since it includes the recorder which makes
things quite a bit easier). If you need help installing that version,
please feel free to ask.
A bug you might hit quite early is that mozmill has its problems
with multiple windows [8]. When I created the first test, I recorded
all
actions in one window, stopped the recording, saved the commands to an
editor, then recorded the steps for the next window.
There is also a bug on getting the right window controller. Right now,
mozmill uses either a predefined controller for Firefox, or gets the
controller by the window's title. This of course doesn't really work
since switching to calendar mode or even to a Thunderbird folder will
cause the window title to change. Take a look at how I created the
controller in the existing test for what to change.
After you've finished recording the test, you'll have some code that
allows you to travel through the windows, but whats still missing is
testing if certain fields actually have the value you'd expect them to
have. There are a set of functions [9], [10] available to do this, you
can see them in action in the mentioned alarm mozmill test.
In any case, please do hang out in #calendar on irc.mozilla.org, my
nickname is Fallen. I'll be happy to help out and if I'm not around
I'm
sure someone else will pick up. If you need specific help on mozmill,
go
ahead and ask either ctalbert or mikael or adamc (the last two will be
in #qa). ctalbert is also a calendar contributor, the three together
are
the original authors of mozmill. I'm sure ctalbert can also answer a
more calendar-specific question on mozmill.
I'm looking forward to hearing from you, thank you again for looking
into the Calendar Project!
Philipp
[1] https://wiki.mozilla.org/QA/TDAI/Mozmill
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=457265
[3]
http://mxr.mozilla.org/comm-central/source/calendar/test/mozmill/alarm-defaultvalue.js
[4]
https://litmus.mozilla.org/show_test.cgi?searchType=by_category&product_id=5
[5] ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-central/
[6]
ftp://ftp.mozilla.org/pub/calendar/lightning/nightly/latest-comm-central/
[7] https://wiki.mozilla.org/QA/TDAI/Mozmill#To_Get_the_Latest_Source_Code
[8] https://bugzilla.mozilla.org/show_bug.cgi?id=473144
[9] http://code.google.com/p/mozmill/wiki/ControllerAPI
[10] http://code.google.com/p/mozmill/wiki/JavascriptUnittestModule
Peter Weilbacher
> I'm sorry I haven't responded earlier, I didn't have an eye on the
> newsgroups.
>
> We indeed haven't talked about the build servers but unless the
> hardware costs are immense (which I don't believe) I think nothing
> speaks against keeping the build servers running. If we want to use
> those machines to build a joint Thunderbird+Lightning, I think the
> most reasonable thing to do is rather to cut down the number of
> Sunbird builds (i.e no hourly builds, just nightly builds) rather than
> turning them off completely. The initial barrier for getting involved
> with Sunbird development will be much higher if setting up nightly
> builds is the first thing the new leader has to do.
>
> Since many people have asked what is needed to keep Sunbird alive, I
> will follow up with a blog post soon (tm), also mentioning our ideas
> on stripping down Thunderbird to only provide calendar features if
> this is wanted in the long run. This might make it easier for new
> contributors to step up. I apologize for not having thought of this
> earlier.
Did this blog post ever happen?
Because I am using Sunbird myself on Linux and OS/2 (and rarely,
Windows), I would be very unhappy to see it go. I would like to help
with the development but my efforts to keep all the Mozilla programs
alive on OS/2 and the restriction to my decreasing spare time probably
make this unrealistic. Doing releases might be possible...
But to get any further in this discussion I would like to know things
like:
- what are the main time consumers for Sunbird development?
- how many patches/bugs are expected to be Sunbird-only?
- how much time does one need to make a full release?
- what local resources (hard/software) would one need?
- what remote resources (build machines at Mozilla Hq or whereever)
would one have access to?
I guess QA would not be such a big problem. SeaMonkey seems to
basically post QA calls in the newsgroups before every release, and
enough people test on their platform(s). That should work for
Sunbird, too.
Cheers,
Peter.
P.S.: Is there an update on the release planning for 1.0 beta1 or
0.9.5 or whatever it is going to be called?
Simon Paquet
>> We indeed haven't talked about the build servers but unless the
>> hardware costs are immense (which I don't believe) I think nothing
>> speaks against keeping the build servers running. If we want to use
>> those machines to build a joint Thunderbird+Lightning, I think the
>> most reasonable thing to do is rather to cut down the number of
>> Sunbird builds (i.e no hourly builds, just nightly builds) rather than
>> turning them off completely. The initial barrier for getting involved
>> with Sunbird development will be much higher if setting up nightly
>> builds is the first thing the new leader has to do.
>>
>> Since many people have asked what is needed to keep Sunbird alive, I
>> will follow up with a blog post soon (tm), also mentioning our ideas
>> on stripping down Thunderbird to only provide calendar features if
>> this is wanted in the long run. This might make it easier for new
>> contributors to step up. I apologize for not having thought of this
>> earlier.
>
>Did this blog post ever happen?
Not that I'm aware.
For the rest, Philipp is the only one that can adequately answer your
questions.
Philipp Kewisch
>
> Because I am using Sunbird myself on Linux and OS/2 (and rarely,
> Windows), I would be very unhappy to see it go. I would like to help
> with the development but my efforts to keep all the Mozilla programs
> alive on OS/2 and the restriction to my decreasing spare time probably
> make this unrealistic. Doing releases might be possible...
>
> But to get any further in this discussion I would like to know things
> like:
> - what are the main time consumers for Sunbird development?
From personal experience, managing the community takes quite a bit of
time. This would include blogging, possibly helping other (Sunbird)
developers, and managing support requests. Aside from that, another
time consumer is obviously development. If all that you want is to
keep Sunbird alive (i.e no new features, just bugfixes), then it might
not be that bad, but that won't really make Sunbird future proof. New
concepts like gloda (search indexing database) need some extra work so
that Sunbird can take advantage of them. Triaging bugs from my
perspective is not that much work, but on the other hand, others from
the team (most notably ssitter) take care of much triage work (i.e ask
reporters what version they are using, debug messages, etc) and thats
probably not negligible either.
> - how many patches/bugs are expected to be Sunbird-only?
Right now, there are only about 40 bugs marked as Sunbird Only. There
may be additional bugs that are in other components that need Sunbird
specific work though.
> - how much time does one need to make a full release?
Not really sure how to answer this. A release (even if its just an
alpha/beta) should happen every few months. Blocking bugs should be
defined and worked on. Before the release, there needs to be a string
freeze of at least 2 weeks (depending on the volume of strings
changed) in which localizers can take care of translating the strings.
Then there should be a code freeze where only bugs that fix urgent
regressions and bugs directly related to the release are checked in.
During this phase, it should be made sure that the product is tested.
Also, release candidate builds are often determined during this phase
to increase visibility. This phase takes at least 2 weeks, with 1
additional week per additionally needed release candidate.
> - what local resources (hard/software) would one need?
I personally only have a Linux Laptop. The more operating systems you
have available the better, i.e if there are mac or windows specific
issues.
> - what remote resources (build machines at Mozilla Hq or whereever)
> would one have access to?
I guess that depends on what you need, you'd have to arrange with
gozer here.
> P.S.: Is there an update on the release planning for 1.0 beta1 or
> 0.9.5 or whatever it is going to be called?
I'm trying to cut down the blocker bugs for 1.0beta1 right now,
although my time is limited.
Regards,
Philipp
Simon Paquet
>> - what remote resources (build machines at Mozilla Hq or whereever)
>> � would one have access to?
>
>I guess that depends on what you need, you'd have to arrange with
>gozer here.
Let me add that in the past both the Mozilla Foundation and Mozilla
Messaging have been pretty helpful in acquiring and managing build
machines for us. I would expect that to continue.
Simon Paquet
--
Thunderbird/Calendar Localisation (L10n) Coordinator
Thunderbird l10n blog: http://thunderbird-l10n.blogspot.com
Calendar website maintainer: http://www.calendar-project.org