How to deal with Sunbird after its discontinuation

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

How to deal with Sunbird after its discontinuation

Simon Paquet-2
Hi guys,

there's been some discussion among Calendar developers on how to
treat Sunbird after its discontinuation and I want to move the
discussion into the public to get some wider feedback.

IMPORTANT:
Please don't turn this discussion into a discussion on the merits
of discontinuing Sunbird. The decision has been made. It won't be
changed.

Now that Sunbird 1.0 beta1 is out, our last release of Sunbird, as
stated here[1], there[2], here[3], there[4] and here[5], we need to
decide how to treat its leftovers, e.g. nightly builds or bug reports.

My personal opinion is that

1) We should close all existing bug reports dealing exclusively with
   Sunbird, while adding a status whiteboard entry at the same time
   to make them easily identifiable in case we want to resuurect those
   bug reports.

My main reason for this proposal is that open bugs tend to give users
the impression that they may be fixed in time. This obviously isn't
the case for Sunbird bugs and we should not leave that impression
with users.

2) We should discontinue all Sunbird nightly builds and focus
   exclusively on Lightning nightly builds. To make upgrading
   Lightning nightly builds easier, we should think hard about
   including the Lightning nightly updater add-on in Lightning nightly
   builds, but not in release builds.

The reason in my opinion is that producing Sunbird nightly builds
takes valuable CPU time away from our build machines, which we
could use in a better way. There's also the issue, that Sunbird
won't be actively maintained any longer, so the builds will break
at some point in time anyway and then we surely won't fix them. In
fact as far as I'm aware current 1.1pre nightly builds are already
broken.

I'd appreciate some feedback on this.

Cya
Simon

[1]
http://weblogs.mozillazine.org/calendar/2009/02/calendar_project_at_a_critical.html
[2]
http://weblogs.mozillazine.org/calendar/2009/02/more_on_the_sunbirdlightning_d.html
[3]
http://weblogs.mozillazine.org/calendar/2009/02/even_more_on_the_sunbirdlightn.html
[4]
http://weblogs.mozillazine.org/calendar/2009/08/how_to_save_sunbird.html
[5]
http://weblogs.mozillazine.org/calendar/2010/04/sunbird_10_beta1_now_available.html

--
Calendar Localisation (L10n) Coordinator
Calendar website maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog:     http://weblogs.mozillazine.org/calendar
_______________________________________________
dev-apps-calendar mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-calendar
Reply | Threaded
Open this post in threaded view
|

Re: How to deal with Sunbird after its discontinuation

Marcel Stör
On 16.04.2010 10:00, Simon Paquet wrote:
[...]
> 1) We should close all existing bug reports dealing exclusively with
> Sunbird, while adding a status whiteboard entry at the same time
> to make them easily identifiable in case we want to resuurect those
> bug reports.

+1

> 2) We should discontinue all Sunbird nightly builds and focus
> exclusively on Lightning nightly builds. To make upgrading
> Lightning nightly builds easier, we should think hard about
> including the Lightning nightly updater add-on in Lightning nightly
> builds, but not in release builds.

+1

I'm not a Sunbird developer, but maybe it's necessary to add 3) - let
(ex)-Sunbird developers decide about:
3) Make the bride i.e. Sunbird ready to be developed/maintained elsewhere.

Cheers,
Marcel

--
Marcel Stör, http://www.frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
Skype: marcelstoer
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
-> I kill Google Groups posts: http://improve-usenet.org

_______________________________________________
dev-apps-calendar mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-calendar
Reply | Threaded
Open this post in threaded view
|

Re: How to deal with Sunbird after its discontinuation

Robert Brand
In reply to this post by Simon Paquet-2
On 16.04.2010 10:00, Simon Paquet wrote:

> Now that Sunbird 1.0 beta1 is out, our last release of Sunbird, as
BTW: Do you provide automatic updates for this last release in the
meantime? My Sunbird 0.9 with update channel "release" still doesn't say
a word about the "beta".

> 1) We should close all existing bug reports dealing exclusively with
>   Sunbird, while adding a status whiteboard entry at the same time
>   to make them easily identifiable in case we want to resuurect those
>   bug reports.
Yes, sounds reasonable to me.

> 2) We should discontinue all Sunbird nightly builds and focus
>   exclusively on Lightning nightly builds. To make upgrading
>   Lightning nightly builds easier, we should think hard about
>   including the Lightning nightly updater add-on in Lightning nightly
>   builds, but not in release builds.
+1
Please don't remove Sunbird from comm-central as proposed in Bug 559066.
Doing so (or deleting Sunbird bugs instead of closing them) would make
it nearly impossible that anyone will work on Sunbird in the future.
People should be able to pull the code, build nightlies themselves and
maybe even provide patches so the builds don't break. Maybe unlikely,
yes, but it would be cool to preserve the chance.

Robert
_______________________________________________
dev-apps-calendar mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-calendar
Reply | Threaded
Open this post in threaded view
|

Re: How to deal with Sunbird after its discontinuation

Simon Paquet-2
mozrob wrote on 16. Apr 2010:

>> Now that Sunbird 1.0 beta1 is out, our last release of Sunbird, as
>
> BTW: Do you provide automatic updates for this last release in the
> meantime? My Sunbird 0.9 with update channel "release" still doesn't
> say a word about the "beta".

We should do that. I've already spoken with Philipp and Gozer about
this.

>> 2) We should discontinue all Sunbird nightly builds and focus
>>   exclusively on Lightning nightly builds. To make upgrading
>>   Lightning nightly builds easier, we should think hard about
>>   including the Lightning nightly updater add-on in Lightning
>>   nightly builds, but not in release builds.
>
> +1
> Please don't remove Sunbird from comm-central as proposed in Bug
> 559066. Doing so (or deleting Sunbird bugs instead of closing them)
> would make it nearly impossible that anyone will work on Sunbird
> in the future. People should be able to pull the code, build
> nightlies themselves and maybe even provide patches so the builds
> don't break. Maybe unlikely, yes, but it would be cool to preserve
> the chance.

We don't have to do that immediately, but the longer Sunbird stays
dormant, the less likely it is that it will get resurrected. So an
acceptable alternative would be to remove all Sunbird files in say
6 months and tag the tree at that point in time to make the files
easily recoverable.

Cya
Simon

--
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
_______________________________________________
dev-apps-calendar mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-calendar
Reply | Threaded
Open this post in threaded view
|

Re: How to deal with Sunbird after its discontinuation

Justin Wood (Callek)-2
In reply to this post by Simon Paquet-2
On 4/16/2010 4:00 AM, Simon Paquet wrote:

> Hi guys,
>
> there's been some discussion among Calendar developers on how to
> treat Sunbird after its discontinuation and I want to move the
> discussion into the public to get some wider feedback.
>
> IMPORTANT:
> Please don't turn this discussion into a discussion on the merits
> of discontinuing Sunbird. The decision has been made. It won't be
> changed.
>
> Now that Sunbird 1.0 beta1 is out, our last release of Sunbird, as
> stated here[1], there[2], here[3], there[4] and here[5], we need to
> decide how to treat its leftovers, e.g. nightly builds or bug reports.
>
> My personal opinion is that
>
> 1) We should close all existing bug reports dealing exclusively with
> Sunbird, while adding a status whiteboard entry at the same time
> to make them easily identifiable in case we want to resuurect those
> bug reports.

I'm for this in theory and goal; against it in implementation.

I'd actually suggest moving the bugs to the GRAVEYARD of bugzilla. Which
will make it obvious that they are there because they will not be worked
on, and we don't intend to ever care about them.

It is what the Graveyard is for.

--
~Justin Wood (Callek)
_______________________________________________
dev-apps-calendar mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-calendar
Reply | Threaded
Open this post in threaded view
|

Re: How to deal with Sunbird after its discontinuation

Stefan Sitter-2
In reply to this post by Simon Paquet-2
Regarding Sunbird builds I would propose the following:

Hourly builds: turn off

Nightly builds: keep them on 1.9.2 branch for testing and l10n
repackaging. this would be one build per day per platform. the build
time could be moved to a different time than Lightning to ensure that
Lightning nightly builds get all required resources.

L10n builds: turn off once you are able to provide localized Lightning
builds for testing

Update builds: turn off mar file generation for all nightly and hourly
builds. keep only for released builds.

_______________________________________________
dev-apps-calendar mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-calendar