Empathy List Archives

JK

Jonathan Kamens

Sun, May 26, 2019 12:56 PM

Hi,

I mentioned this point in a recent thread, but it got buried there so I
want to pull it out and emphasize it here in the hope that that might help.

I track nightly build in my day-to-day use of TB, for reasons which I've
already explained and others have acknowledged are useful and helpful to
the community.

When the nightly build breaks, I need to "freeze" at the build before
the breakage until such time as the build is fixed.

This was once easy. Now, it is hard:

By default nightly is updated automatically; that wasn't the case
before.
Even when you disable the automatic nightly update, you get prompted
multiple times per day asking you to download and install the update.
After downgrading I have to specify --allow-downgrade when launching
Thunderbird or it won't let me run it against my profile.

Please, can we make this easier?

Optimally, there would be a hidden preference to disable upgrade
prompting completely, and another one to allow downgrades without
--allow-downgrade. These do not need to be visible in the UI; they would
be used only by people with a good reason to use them who go looking for
them.

Thanks,

Jonathan Kamens

Hi, I mentioned this point in a recent thread, but it got buried there so I want to pull it out and emphasize it here in the hope that that might help. I track nightly build in my day-to-day use of TB, for reasons which I've already explained and others have acknowledged are useful and helpful to the community. When the nightly build breaks, I need to "freeze" at the build before the breakage until such time as the build is fixed. This was once easy. Now, it is hard: * By default nightly is updated automatically; that wasn't the case before. * Even when you disable the automatic nightly update, you get prompted multiple times per day asking you to download and install the update. * After downgrading I have to specify --allow-downgrade when launching Thunderbird or it won't let me run it against my profile. Please, can we make this easier? Optimally, there would be a hidden preference to disable upgrade prompting completely, and another one to allow downgrades without --allow-downgrade. These do not need to be visible in the UI; they would be used only by people with a good reason to use them who go looking for them. Thanks, Jonathan Kamens

JK

Jörg Knobloch

Sun, May 26, 2019 1:10 PM

On 26/05/2019 14:56, Jonathan Kamens via Maildev wrote:

Please, can we make this easier?

Quick comment: There was
https://bugzilla.mozilla.org/show_bug.cgi?id=1481589, sadly WONTFIXed
with the reason to use enterprise policies. Now that we have implemented
those, we should be able to create and "anti-update" policy.

Jörg.

On 26/05/2019 14:56, Jonathan Kamens via Maildev wrote: > Please, can we make this easier? Quick comment: There was https://bugzilla.mozilla.org/show_bug.cgi?id=1481589, sadly WONTFIXed with the reason to use enterprise policies. Now that we have implemented those, we should be able to create and "anti-update" policy. Jörg.

PK

Philipp Kewisch

Sun, May 26, 2019 1:19 PM

I think the best way to go about this would be to create an update channel similar to nightly, beta, and release. Jörg or someone else driving the bustage fixes could somehow mark certain nightly builds as know working which would make them available in the new channel.

We need to be clear though that nightly is by definition an unstable channel. If you are running in it you need to put in the work yourself to keep it running.

Having a separate channel might be good for stability, but does lower the nightly testing capacities making it hard to actually provide stable nightly builds.

Philipp

On 26. May 2019, at 3:10 PM, Jörg Knobloch jorgk@jorgk.com wrote:

On 26/05/2019 14:56, Jonathan Kamens via Maildev wrote:
Please, can we make this easier?

Quick comment: There was https://bugzilla.mozilla.org/show_bug.cgi?id=1481589, sadly WONTFIXed with the reason to use enterprise policies. Now that we have implemented those, we should be able to create and "anti-update" policy.

Jörg.

Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

I think the best way to go about this would be to create an update channel similar to nightly, beta, and release. Jörg or someone else driving the bustage fixes could somehow mark certain nightly builds as know working which would make them available in the new channel. We need to be clear though that nightly is by definition an unstable channel. If you are running in it you need to put in the work yourself to keep it running. Having a separate channel might be good for stability, but does lower the nightly testing capacities making it hard to actually provide stable nightly builds. Philipp > On 26. May 2019, at 3:10 PM, Jörg Knobloch <jorgk@jorgk.com> wrote: > >> On 26/05/2019 14:56, Jonathan Kamens via Maildev wrote: >> Please, can we make this easier? > > Quick comment: There was https://bugzilla.mozilla.org/show_bug.cgi?id=1481589, sadly WONTFIXed with the reason to use enterprise policies. Now that we have implemented those, we should be able to create and "anti-update" policy. > > Jörg. > > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

JK

Jonathan Kamens

Sun, May 26, 2019 1:22 PM

On 5/26/19 9:19 AM, Philipp Kewisch wrote:

I think the best way to go about this would be to create an update channel similar to nightly, beta, and release. Jörg or someone else driving the bustage fixes could somehow mark certain nightly builds as know working which would make them available in the new channel.

This is making more work for the TB devs.

I am under the impression that they are pretty overwhelmed, so this does
not seem like the best plan.

Furthermore, a TB nightly that might be broken for one person might work
just fine for another, if the breakage is localized and in an area that
not everyone uses. I don't see why the best way to go about this would
be to centralize the decision-making rather than allowing people who run
nightly to decide for themselves when they need to stick with a
particular build.

jik

On 5/26/19 9:19 AM, Philipp Kewisch wrote: > I think the best way to go about this would be to create an update channel similar to nightly, beta, and release. Jörg or someone else driving the bustage fixes could somehow mark certain nightly builds as know working which would make them available in the new channel. This is making more work for the TB devs. I am under the impression that they are pretty overwhelmed, so this does not seem like the best plan. Furthermore, a TB nightly that might be broken for one person might work just fine for another, if the breakage is localized and in an area that not everyone uses. I don't see why the best way to go about this would be to centralize the decision-making rather than allowing people who run nightly to decide for themselves when they need to stick with a particular build. jik

RM

Richard Marti

Sun, May 26, 2019 1:32 PM

On 26.05.2019 15:10, Jörg Knobloch wrote:

On 26/05/2019 14:56, Jonathan Kamens via Maildev wrote:

Please, can we make this easier?

Quick comment: There was
https://bugzilla.mozilla.org/show_bug.cgi?id=1481589, sadly WONTFIXed
with the reason to use enterprise policies. Now that we have implemented
those, we should be able to create and "anti-update" policy.

Notice that this disables the Update button and you have to download the
newer version manually.

Richard

On 26.05.2019 15:10, Jörg Knobloch wrote: > On 26/05/2019 14:56, Jonathan Kamens via Maildev wrote: >> Please, can we make this easier? > > Quick comment: There was > https://bugzilla.mozilla.org/show_bug.cgi?id=1481589, sadly WONTFIXed > with the reason to use enterprise policies. Now that we have implemented > those, we should be able to create and "anti-update" policy. Notice that this disables the Update button and you have to download the newer version manually. Richard

maildev@lists.thunderbird.net

Please make it easier to stick on a specific nightly build