Try builds being updated to mozilla-central nightlies
Nick Thomas
submissions to the try server. The Tab Candy builds which made a splash
over the weekend [2] are automatically updating to the latest Minefield
(mozilla-central) nightlies and losing the Tab Candy functionality.
This started happening when the tryserver was upgraded recently, when
the mozconfigs were duplicated over from m-c. Try builds now end up on
the 'nightly' update channel and find updates; previously the were on
'default' and weren't served any.
We can certainly revert that change but I want to check that is the
desired outcome. Obviously we don't want to yank people off a build they
may wish to test for several days, but neither should we leave people
stranded on old builds (when the change is probably in m-c or a release
anyway). The update server doesn't allow us a middle ground of updating
people after their build is more than N days old.
My suggestion is that we change the channel from 'nightly' to
'tryserver' so that we can at least count the numbers of users, and have
a way to provide updates if we want to. 'default' is no good because we
can't distinguish try builds from people compiling their own.
Suggestions/comments ?
Cheers,
Nick
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=581791
[2] http://bit.ly/ciU6xa
Dave Townsend
> Bug 581791 [1] presents an interesting problem for builds created by submissions to the try server. The Tab Candy builds which made a splash over the weekend [2] are automatically updating to the latest Minefield (mozilla-central) nightlies and losing the Tab Candy functionality. This started happening when the tryserver was upgraded recently, when the mozconfigs were duplicated over from m-c. Try builds now end up on the 'nightly' update channel and find updates; previously the were on 'default' and weren't served any.
I think this is actually the correct default choice. I think most try builds that people advertise are one-time test builds and in general we want to update people to nightlies. Obviously it would be nice to only do that when the particular feature they are testing is in the nightlies but I'm sure we aren't going to think about doing that for anything but very special cases.
If people want to avoid that for specific cases then they can set the update channel in the custom mozconfig for their try build
Robert Kaiser
> My suggestion is that we change the channel from 'nightly' to
> 'tryserver' so that we can at least count the numbers of users, and have
> a way to provide updates if we want to. 'default' is no good because we
> can't distinguish try builds from people compiling their own.
> Suggestions/comments ?
Maybe we should generally implement a mechanism like the one I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=581319 for, and be more
aggressive about warnings when we are on other channels than release (or
possibly beta).
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! :)
Ben Hearsum
Hash: SHA1
On 10-07-27 12:40 AM, Nick Thomas wrote:
> My suggestion is that we change the channel from 'nightly' to
> 'tryserver' so that we can at least count the numbers of users, and have
> a way to provide updates if we want to. 'default' is no good because we
> can't distinguish try builds from people compiling their own.
> Suggestions/comments ?
What if we were to leave the try builds on the "nightly" channel and
require custom mozconfigs to set an alternative channel, if desired. It
would require upfront knowledge of this requirement but at least the
general case would be handled very well.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkxOzKMACgkQJE25Np0n+NtKAACdH0mEcYmBfS1cCVPmH8UV0EW4
x8UAn2t+zSwcrwc60pEp2tjThi7fLCi4
=RRd7
-----END PGP SIGNATURE-----
Ben Hearsum
Hash: SHA1
On 10-07-27 8:10 AM, Ben Hearsum wrote:
> On 10-07-27 12:40 AM, Nick Thomas wrote:
>> My suggestion is that we change the channel from 'nightly' to
>> 'tryserver' so that we can at least count the numbers of users, and have
>> a way to provide updates if we want to. 'default' is no good because we
>> can't distinguish try builds from people compiling their own.
>> Suggestions/comments ?
>
> What if we were to leave the try builds on the "nightly" channel and
> require custom mozconfigs to set an alternative channel, if desired. It
> would require upfront knowledge of this requirement but at least the
> general case would be handled very well.
Oops, I didn't read d.a.firefox before replying. Carry-on!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkxOzOIACgkQJE25Np0n+NtwMQCdF/cF3DfvyWW/4hrf+F/1rQ0a
0/kAn1Fo31LRagVUxj5Nt/MNSsfSfVFU
=WZXF
-----END PGP SIGNATURE-----
Benjamin Smedberg
> What if we were to leave the try builds on the "nightly" channel and
> require custom mozconfigs to set an alternative channel, if desired. It
> would require upfront knowledge of this requirement but at least the
> general case would be handled very well.
I don't think this is a good option. If you want feedback on a tryserver
build, you definitely don't want people automatically updating to tomorrow's
nightly (which will often come out before you've had a chance to test and
blog about your tryserver build).
I think we should try your suggestion first: make a tryserver update channel
by default first, and measure to see how big the problem is. I can imagine a
future world where we use the tryserver update channel automatically, and
publish a *major* update prompt once a week for old tryserver build. But I
wouldn't spend energy on that plan unless we have lots of stranded users.
--BDS
John O'Duinn
Seems like there are two different topics here:
1) What should a TryServer build update to? (or "Why does a TabCandy
build generated on TryServer update to nightly on mozilla-central?")
=====================================================================
TryServer builds intentionally upgrade to latest mozilla-central builds.
This is because updating to newer TryServer builds doesnt make sense.
Recall that TryServer builds are for people to experiment with - all
sorts of people can push any vintage of changeset to TryServer to build.
For example, a newer TryServer build can be based off an *older* code
revision, and be totally unrelated to TabCandy. Having a user "upgrade"
("downgrade"? "crossgrade"?) to a newer TryServer build is not useful in
this scenario, and users would usually lose their TabCandy functionality
anyway.
We felt that abandoning a TryServer user, with no ability to update, was
bad. Instead, we defaulted to migrating those experimental users to the
latest Minefield mozilla-central nightly. Unless I'm missing something,
I suggest the current default behavior remain.
2) Where should TabCandy builds be distributed from?
====================================================
The TabCandy developers are already using one of the rentable project
branches ("maple") for the TabCandy project. This is in addition to any
TryServer builds they do. Going forward, Aza will make sure all TabCandy
code changes are landed on the "maple" project branch, and all future
TabCandy builds announced for testing will be from this "maple" project
branch.
To enable better testing, before TabCandy lands on mozilla-central,
RelEng will enable updates on "maple" branch. This will allow TabCandy
users to update to newer TabCandy builds. The curious can follow
https://bugzilla.mozilla.org/show_bug.cgi?id=574803.
(Once TabCandy has finished landing into mozilla-central, Aza will file
bug to have RelEng custom-update any remaining users on maple branch to
mozilla-central or mozilla-20 as he feels is appropriate. The "maple"
branch will then be freed up for the next project needing a rentable
project branch.)
Hopefully that helps clarify? Let me know if I missed anything ok?
tc
John.
=====
On 7/26/10 10:04 PM, Dave Townsend wrote:
> On Jul 26, 2010, at 21:40, Nick Thomas wrote:
>
>> Bug 581791 [1] presents an interesting problem for builds created by submissions to the try server. The Tab Candy builds which made a splash over the weekend [2] are automatically updating to the latest Minefield (mozilla-central) nightlies and losing the Tab Candy functionality. This started happening when the tryserver was upgraded recently, when the mozconfigs were duplicated over from m-c. Try builds now end up on the 'nightly' update channel and find updates; previously the were on 'default' and weren't served any.
>
> I think this is actually the correct default choice. I think most try builds that people advertise are one-time test builds and in general we want to update people to nightlies. Obviously it would be nice to only do that when the particular feature they are testing is in the nightlies but I'm sure we aren't going to think about doing that for anything but very special cases.
>
> If people want to avoid that for specific cases then they can set the update channel in the custom mozconfig for their try build
>
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Mike Beltzner
cheers,
mike
>>> Bug 581791 [1] presents an interesting problem for builds created by submissions to the try server. The Tab Candy builds which made a splash over the weekend [2] are automatically updating to the latest Minefield (mozilla-central) nightlies and losing the Tab Candy functionality. This started happening when the tryserver was upgraded recently, when the mozconfigs were duplicated over from m-c. Try builds now end up on the 'nightly' update channel and find updates; previously the were on 'default' and weren't served any.
>>
Axel Hecht
> I think you may have missed the follow-on conversation where pretty much everyone agreed that TryServer builds should either be set to the "default" channel or to a "tryserver" channel and not receive updates. The rationale for this was that a tryserver build would contain some experimental sort of functionality which may or may not make it into the tree, and may need to be used for functionality and testing comparison against recent nightly or release builds. Thus, updating isn't really a desirable outcome.
proper way to not silently take people off a try server build without
loosing them?
Also, yay for having update channels for disposable project branches,
really.
Axel