414675 - Want mechanism for warning about dataloss or other super-critical bugs in nightlies

Status: RESOLVED INCOMPLETE

(Release Engineering :: General, enhancement, P3)

Description

[Eyal Rozenberg]

Some (many?) people use nightly builds of Seamonkey, Firefox and/or Thunderbird for their daily work intermixed with debugging/development work. It would be nice if, when downloading a nightly, I could be informed of whether someone has filed a bug suggesting it might cause data loss, a security compromise, etc. - in which case I would not run it with my 'main' profile.

This can be done via the Web/FTP server with the nightlies, or in the actual code, by a preffed-disabled option to check some URL to determine whether the currently running nightly build is considered minimally 'safe'.

Comment 1

[Robert Helmer [:rhelmer]]

Maybe something the QA extension could be used for?

Comment 2

[Eyal Rozenberg]

'The' QA extension?

Comment 3

[Robert Helmer [:rhelmer]]

(In reply to comment #2)
> 'The' QA extension?

http://quality.mozilla.org/en/mozqa-extension

Comment 4

[Eyal Rozenberg]

Ok, saw the extension, and my answer to comment #1 is - maybe... I dunno.

Comment 5

[Robert Helmer [:rhelmer]]

(In reply to comment #4)
> Ok, saw the extension, and my answer to comment #1 is - maybe... I dunno.

It's a good idea, but I don't know what mechanism we can provide from the build&release side. Do you have any more specific suggestions?

This seems like it would require humans to mark bugs so they could be automatically searched for, and the 24h affordance between each nightly doesn't seem like quite enough time to do this very accurately.. did you have something automatic in mind?

Comment 6

[Eyal Rozenberg]

Yes. A possible scheme: A flag could be added to bug reports which is true if the bug is expected to manifest widely in current nightlies. If there are trunk bugs marked with this flag and with, say, dataloss and/or critical, a list of them will be shown to the user before updating to a new nightly.

Comment 7

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Unclear what is to be done here or who should do it. 

Timing for nightly builds is tight, and bugs would have to be marked this way *before* the nightly build completed. Also, its unclear to me that humans marking bugs, even 100% timely and accurately, would be sufficient solution. And we have no manual testing possible for nightlies. And we'd need to change the updater code to ask this extra "potential data loss - are you sure" question.

Personally, imho, if we know a nightly has a data loss problem before we making available to nightly testers, we should probably be generating a new fixed nightly. However, its tough to detect data loss problems in advance, in a speedy automated manner. Its possible that additional automated unittests might help reduce risk here, but even then...

(side thought: Timing on beta builds allows more room for testing, and better chances of catching problems before handing out to developers/testers/users. Still not bulletproof, but an improvement. If you've been hit with dataloss problems with nightly channel, maybe you'd be better served by the beta channel instead?)

Comment 8

[Reed Loden [:reed]]

Bug 413572 could take care of this, possibly...

Comment 9

[Eyal Rozenberg]

(In reply to comment #7)
I'm not asking for something perfect. But if someone marks a bug 'dataloss', we
can assume by default that it manifests widely enough to merit warning nightly
users in some way. I would like something heuristic which covers big and
visible catastrophe bugs, not esoteric stuff.

> beta channel instead?
SM 1.x code was forked more than a year ago IIRC
(two years? I'm getting senile), and no SM 2.0 beta yet, so that's not very
relevant.

Also, I haven't been hit with dataloss, but rather with won't-startup's and
crash-all-over-the-place'ers.

> Unclear what is to be done here or who should do it. 
The fact that I don't have a single specific solution does not mean
that this is an invalid issue. Please unresolve.

(In reply to comment #8)
> Bug 413572 could take care of this, possibly...

Well, I think it's an orthogonal issue. I mean, certainly, if you're recreating the nightly release mechanism, or part of it, you might introduce something meeting my request - but nothing in Bug 413572 suggests this is considered.