Help Wanted - www.mozilla.org/start/
Gervase Markham
encourages people to upgrade their copy of Mozilla if it's old. However,
it breaks often, and the method it uses for distinguishing between
nightly and milestone builds no longer works. It also has trouble with
Firebird.
I'm looking for someone who knows JS to overhaul it and make it work in
a more sane, and easily-maintainable way. It shouldn't be a big job -
it's just that I don't have time to do it :-)
See bugs:
http://bugzilla.mozilla.org/show_bug.cgi?id=209537
Gerv
Michael Lefevre
> The page http://www.mozilla.org/start/ has a JavaScript sniffer which
> encourages people to upgrade their copy of Mozilla if it's old. However,
> it breaks often, and the method it uses for distinguishing between
> nightly and milestone builds no longer works. It also has trouble with
> Firebird.
>
> I'm looking for someone who knows JS to overhaul it and make it work in
> a more sane, and easily-maintainable way. It shouldn't be a big job -
> it's just that I don't have time to do it :-)
The JS is not a big job - the issue is that someone first needs to work
out what the script is going to do.
The UAs for nightly builds are the same as the UAs for release builds,
except for the build IDs. The build IDs for a release are different in
each build (across platforms, distributions, etc), so you'd need a list of
dozens of build ids for each release, which is not practical.
Given that there's no practical way of knowing whether the user has a
release build or a nightly, the script cannot do what it used to do.
Even if it had been working in a sane and easily-maintainable way (as it
was for release builds), it still wouldn't work for 1.4RC1 and 1.4RC2,
because the builds themselves don't have anything to identify them from
the other 1.4 branch nightlies. Anything written now will probably get
broken by the switch to Firebird.
The only way to make the script sane and easily-maintainable is if one can
know what Mozilla UAs are going to look like for future releases
(including release candidates), and that's not really possible. Even if
one can guess, should Mozilla 1.4 final users be encouraged to move to
1.5alpha? Firebird 0.8? 1.5 final? Should 1.0.x users be encouraged
to move to 1.4? or should they move to 1.5alpha?
see also
http://bugzilla.mozilla.org/show_bug.cgi?id=197927
nagging doesn't work for nightly builds
http://bugzilla.mozilla.org/show_bug.cgi?id=184770
nagging doesn't work for self-builds
http://bugzilla.mozilla.org/show_bug.cgi?id=152128
start page shouldn't recommend alpha release to people with a final
release
--
Michael
Geoff Leach
Michael, you were reporter of bug 197927 (nagging doesn't work for
nightly builds), and from what I see have been an active presence on all
the (recent) nagger bugs. I was reporter of bug 184770 (nagging doesn't
work for self-builds). For the record, there have been earlier rounds
related to this issue (bug 46488 for example), with from memory, other
(long) dialogues about UA strings somewhere.
As you say the Javascript is not that hard, the harder job is
defining/agreeing what the nagger should do.
Assuming:
0) We want to keep the nagger (I think we do).
1) There is no (practical) way to use the current UA string to
differentiate amongst release builds, nightly builds and (I add) self
builds. I agree with your assessment that this is the case.
2) We do not want to add/modify the UA string, build process or codebase
at the moment.
Suggestion (in part a response to you final set of questions above):
1) Remove the explicit test for nightlies, which does not work now as
the "+" suffix is not being used, and also remove the test for self
builds which, from what I can tell, never worked.
2) Nag users of an old _release_, i.e., not alpha, beta or release
candidate, about upgrading to the most recent release, but _not_ to
upgrade to latest alpha, beta, release candidate. For example, nag users
of 1.[1-3] release about upgrading to 1.4 release (assuming it is out by
the time the nagger script is updated) but not 1.5a. Use the
milestone/release version part of the UA string to identify version
being used.
3) Nag users of old alpha, beta, release candidates to upgrade to at
least the latest release, and if they feel like helping, to the latest
alpha, beta, release candidate. Again, use the milestone/release version
part of the UA string to identify version being used.
4) Remove the explicit test based on build id for the (way) old security
bug. Users of that version will be nagged to upgrade via 2 or 3 anyhow.
If there is a continuing _requirement_ to specifically advise of the
security problem then leave it in.
5) I'm still building and using the app-suite and havent been really
been using Mozilla Firebird (MF). However, I've just downloaded and run
MF 0.6 (for Linux), and likewise latest MF nightly. The Firebird version
is in the UA string at a different place to the Gecko "rv:" string. Both
nightly and 0.6 release are MF 0.6 in the UA string, but one is "rv:1.4"
and one is "rv:1.5a". That probably raises the need to look at both the
"rv" string and the MF version string for nagging MF users - but is MF
going to use alpha, beta etc? I would probably suggest not nagging the
MFers at all yet - and have an explicit test to not do so.
I would be happy to put together a simplified JS nagger based on above,
which would really just be a simplification of the existing nagger.
Should this discussion be shifted into bugzilla (new bug with
dependencies?).
Benedikt Kantus
> 2) Nag users of an old _release_, i.e., not alpha, beta or release
> candidate, about upgrading to the most recent release, but _not_ to
> upgrade to latest alpha, beta, release candidate. For example, nag users
> of 1.[1-3] release about upgrading to 1.4 release (assuming it is out by
> the time the nagger script is updated) but not 1.5a.
This sounds to me like we didn't want people to "really help us
testing". What use would it be if we were just before a, say, 1.5 final
release and nagged people to upgrading to 1.4?
> 3) Nag users of old alpha, beta, release candidates to upgrade to at
> least the latest release, and if they feel like helping, to the latest
> alpha, beta, release candidate. Again, use the milestone/release version
> part of the UA string to identify version being used.
This is what I would prefer, apart from the current state. We should
include that people can help us best when testing a nightly build.
I agree that the coding of the script is difficult with the current
design of the UA string.
-Bene
--
"I am not bound to please thee with my answer."
The Merchant of Venice
Gervase Markham
> the "+" suffix is not being used, and also remove the test for self
> builds which, from what I can tell, never worked.
The test for self builds should work, and if it doesn't, it can be made
to. Self builds have a Gecko date of 00000000.
> 4) Remove the explicit test based on build id for the (way) old security
> bug. Users of that version will be nagged to upgrade via 2 or 3 anyhow.
> If there is a continuing _requirement_ to specifically advise of the
> security problem then leave it in.
This can go.
Gerv
Andrew Schultz
>> 1) Remove the explicit test for nightlies, which does not work now as
>> the "+" suffix is not being used, and also remove the test for self
>> builds which, from what I can tell, never worked.
>
>
> The test for self builds should work, and if it doesn't, it can be made
> to. Self builds have a Gecko date of 00000000.
only in the titlebar. In the userAgent (which is the only thing the JS can get
at), the date is when the tree was first built.
--
------------------------------------------------------------------
Andrew Schultz | The views expressed might
ajsc...@eos.ncsu.edu | not represent those of NCSU.
http://www4.ncsu.edu/~ajschult/ | They are however, correct.
Michael Lefevre
>> 1) Remove the explicit test for nightlies, which does not work now as
>> the "+" suffix is not being used, and also remove the test for self
>> builds which, from what I can tell, never worked.
>
> The test for self builds should work, and if it doesn't, it can be made
> to. Self builds have a Gecko date of 00000000.
as someone else just pointed out, they don't - as it says in bug 184770.
self builds have the date the tree was first built, so self builders will
tend to have a build id which looks much older than their actual build
(and is identical to a "real" build from that original date), unless they
are fixing it up themselves.
but the self build issue is rather academic if we can't detect nightlies
anyway (I assume the UA given by a self build does actually have the right
version number...)
so - given that we'd have to drop the test for nightlies and self builds,
we're down to using only the version. question there is should we offer
the latest milestone always, or should we offer stable releases to people
using previous stable releases? or both?
>> 4) Remove the explicit test based on build id for the (way) old security
>> bug. Users of that version will be nagged to upgrade via 2 or 3 anyhow.
>> If there is a continuing _requirement_ to specifically advise of the
>> security problem then leave it in.
>
> This can go.
cool - well that's one point cleared up :)
--
Michael
Geoff Leach
> Gervase Markham wrote:
>
>>> 1) Remove the explicit test for nightlies, which does not work now as
>>> the "+" suffix is not being used, and also remove the test for self
>>> builds which, from what I can tell, never worked.
>>
>>
>>
>> The test for self builds should work, and if it doesn't, it can be
>> made to. Self builds have a Gecko date of 00000000.
>
>
> only in the titlebar. In the userAgent (which is the only thing the JS
> can get at), the date is when the tree was first built.
Right. See bug 184770 for some more details.
I've dug pretty deep on the self-build gecko build date, including
following the path by which it winds up in the UA string through the
build mechanism (although I dont know it that well), why it isnt
"0000000" and why self-builders, who enthuse about their shiny new
mozillas with the latest patches and features, one day get nagged just
after updating and building and wonder why.
By default, self-builders will have a gecko build date of the day they
first build their tree after pulling from cvs or unpacking tarball.
Thereafter, their gecko build date remains unchanged unless they clobber
build, touch gbdate.pl or setenv MOZ_BUILD_DATE. Some other suggestions
in bug 184770.
When I was tracking down why, as a dedicated self builder (necessity -
MathML originally, then SVG), I was getting nagged, I looked in the cvs
repository all the way back to when the JS test for self-builds was
first included in start/index.html, and at various old bugs and
discussions, whereby I was led to think the test for self-builds
probably never worked. I'm not trying to be critical, and would be happy
to be wrong.
Simon Paquet
> so - given that we'd have to drop the test for nightlies and
> self builds, we're down to using only the version. question
> there is should we offer the latest milestone always, or should
> we offer stable releases to people using previous stable
> releases? or both?
A combined effort would be good.
Something like
"Hi, you're using Mozilla version x.x which is quite old. Please
get the stable version y.y. if you want the newest functionality
combined with stability or get the latest bleeding-edge-release
z.z. to help test the Mozilla product."
--
Simon Paquet
http://sipaq.blogspot.com - Mein Mozilla Blog
Geoff Leach
>>2) Nag users of an old _release_, i.e., not alpha, beta or release
>>candidate, about upgrading to the most recent release, but _not_ to
>>upgrade to latest alpha, beta, release candidate. For example, nag users
>>of 1.[1-3] release about upgrading to 1.4 release (assuming it is out by
>>the time the nagger script is updated) but not 1.5a.
>
>
> This sounds to me like we didn't want people to "really help us
> testing". What use would it be if we were just before a, say, 1.5 final
> release and nagged people to upgrading to 1.4?
>
Just that I thought we should divide the user base into those who are
stable, release users and those racy, {alpha,beta,nightly,release
candidate} users. Stable, release users probably dont (yet) have the
right profile for living more unstably; that more is probably gained by
having them move up to as recent a release as is available. When they
upgrade, and find they like it, they may or may not make the move to
more incremental progression. Users of alphas, betas, nightlies or
release candidates are already there.
From what I've seen, as soon as a release is out and trunk is open, the
gecko version is incremented to alpha->beta[->rc] of the next point
release, and that is also in the nightlies and self-builds.
So I thought the two sets of users to be distinguishable from the UA
string and that different nags appropriate.
There is a point about nagging to update from say 1.2->1.3 just as 1.4
as about to land. But taking 1.4 as an example, when should say a
1.2->1.3 nag stop due to imminent 1.4? Today, tommorrow, a few more
days, rc3? I guess I dont think that the nag to the most recent release
is so bad, although hours long downloads are a thing of the past for me.
Even with long download times I think probably better to nag people and
have people upgrade twice, than waiting for sometimes uncertain release
timeframes. And the 2-monthly release cycle does mitigate against double
upgrades.
Geoff Leach
Just that I hesitate in prompting stable release users into
bleeding-edge versions with their worst-case downside - lose your
bookmarks/email/passwords type scenarios. Nope, never happened to me,
dont know if it happened at all, and even betas now are solid, but
worst-case is still possible. Overall, I think potentially more to be
lost than gained.
As an example, I'm thinking of an MD friend of mine who is now using
Mozilla for his medical practice after I simply suggested he have a
look. Dont want him losing stuff, crashing etc. Better he just keeps
having a good user experience and telling others, than getting
adventurous. That is, until he reaches the point where something more
adventurous in a sandboxed environment is appropriate.
Michael Lefevre
hrm... I think we're getting to the tricky issue of whether or not Mozilla
is supposed to be aiming at end-users.
in theory, Mozilla isn't for the benefit of a doctor in a medical
practice. the doctor's use of Mozilla is supposed to be for the benefit
of Mozilla, in having him test it. If he can lose all his stuff in a
reproducible way and report it, then that's good, from Mozilla's point of
view. :)
But I can see the point - so maybe offering both a stable version and the
latest alpha/beta/release candidate is an acceptable compromise?
--
Michael
Jack Tanner
> A combined effort would be good.
>
> Something like
>
> "Hi, you're using Mozilla version x.x which is quite old. Please
> get the stable version y.y. if you want the newest functionality
> combined with stability or get the latest bleeding-edge-release
> z.z. to help test the Mozilla product."
This is good. Even better would be use a visual cue to emphasize the
potential instability of a development release. (Only using a visual cue
may have accessibility implications, but I'll leave it to an
accessibility expert to chime in.) This would also address Michael's
comment about the inappropriateness of encouraging inexperienced users
to shift to unstable releases.
For example:
if (UA version older than latest stable release), then
We Suggest an Upgrade
Mozilla.org has released a new browser, version Y.Y. You're using
version X.X. The new browser offers exciting new features, including ...
[something grabbed automatically from the release notes].
If you'd like to help to create the next generation of the Mozilla
browser, please consider taking a more active part: use a development
version and send us your feedback via Bugzilla and Talkback [link B. and
T. to pages that explain what they are]. Note that development versions
may be *unstable*, and may crash or even adversely affect your files and
programs. The latest development version is Z.Z. Some of the features we
are working on for our next release include ...
-JT
Michael Lefevre
> Simon Paquet wrote:
>> A combined effort would be good.
>>
>> Something like
>>
>> "Hi, you're using Mozilla version x.x which is quite old. Please
>> get the stable version y.y. if you want the newest functionality
>> combined with stability or get the latest bleeding-edge-release
>> z.z. to help test the Mozilla product."
>
> This is good. Even better would be use a visual cue to emphasize the
> potential instability of a development release. (Only using a visual cue
> may have accessibility implications, but I'll leave it to an
> accessibility expert to chime in.)
no problem with visual cues as long as there is an accessible alternative
(e.g. adding a visual cue to text like the above would be fine, having the
visual cue instead would not be... and of course you don't have to display
the alternative when the visual cue is displayed). of course, this whole
thing is javascript and therefore probably inaccessible to many anyway. :)
> This would also address Michael's
> comment about the inappropriateness of encouraging inexperienced users
> to shift to unstable releases.
I'm not sure it is inappropriate - I was raising concerns expressed by
others...
> For example:
>
> if (UA version older than latest stable release), then
>
> We Suggest an Upgrade
>
> Mozilla.org has released a new browser, version Y.Y. You're using
> version X.X. The new browser offers exciting new features, including ...
> [something grabbed automatically from the release notes].
>
> If you'd like to help to create the next generation of the Mozilla
> browser, please consider taking a more active part: use a development
> version
[...]
ok, I think this is good.
So, we dump the separate nightly and self-build stuff that doesn't work
anyway, and the security bug stuff. Then, imagining we're at a point
between 1.5alpha and 1.5beta... if the user has something labelled 1.4b or
earlier, we recommend 1.4 & 1.5alpha. if they have 1.4, then I guess we
only suggest 1.5alpha. and when the latest milestone is a final release,
we only recommend that.
That sounds like it could be coded without too much problem (although my
javascript skills are rather lacking...), and would be sane and
maintainable. (with the possible exception of grabbing things
automatically from the release notes which is probably a little more than
one can reasonable take on with javascript!)
Remaining question, supposing someone actually wrote the script to do
that, is would something like that be ok with mozilla.org? Gerv?
--
Michael
Gervase Markham
I think we need to nail down exactly what it is we _can_ determine
(without creating ourselves a maintanance headache like a big table of
user agents), and then decide what the message is. There appear to be a
couple of implementations in the bug already; when I get a minute, I'm
going to look at them :-)
Gerv
Gervase Markham
> get the stable version y.y. if you want the newest functionality
> combined with stability or get the latest bleeding-edge-release
> z.z. to help test the Mozilla product."
I think that, given the technical limitations of the information we have
to go on, something like this is probably the best solution - with
appropriate warnings about nightly builds.
Gerv
Simon Paquet
The best would be a tripartite approach:
- user wants broadly tested new features and much stability
-> final release
- user wants more (but only partially tested) new features and some
stability -> alphas, betas or release candidates
- user wants all new features, doesn't especially care for stability
and wants to help out with testing -> nightly builds
--
Simon Paquet
http://sipaq.blogspot.com - Simon's Mozilla Blog
Michael Lefevre
> Michael Lefevre wrote:
>> In article <bd7frq$2u...@ripley.netscape.com>, Jack Tanner wrote:
>> Remaining question, supposing someone actually wrote the script to do
>> that, is would something like that be ok with mozilla.org? Gerv?
>
> I think we need to nail down exactly what it is we _can_ determine
I thought that was nailed down months ago... what we have is the UA string
which looks like this:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:x.xa) Gecko/xxxxxxxx
the xxxxxxxx is the buildid, which, without a huge lookup table, doesn't
tell you anything about release/nightly status (and may not even get in
the right ballpark for self-builds).
in terms of how up to date something is, that leaves us with with the
rv:x.xa bit (we might also want to do something different, like nothing,
for Netscape/Firebird users who will have an extra bit on the end of the
UA). The revision tells you that this is build somewhere between the
milestone before the one given, and the release given, but nothing more.
I think this answer has been given in several places already... can you
expand on which bits of it you feel we need to nail down?
--
Michael
Gervase Markham
> The best would be a tripartite approach:
>
> - user wants ...
How do you detect what the user wants by sniffing the user agent string?
;-) Or do you mean offer all three possibilities?
Gerv
Simon Paquet
By sniffing the UA-string we only determine, whether the user has
an old build or not. If we detect an old build we would offer
these three possibilities.