Closed Bug 774631 Opened 9 years ago Closed 9 years ago

Stop doing nightly builds on mozilla-inbound

Categories

(Release Engineering :: General, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ehsan.akhgari, Assigned: coop)

References

Details

Attachments

(2 files)

I don't think those builds are useful to anybody, so perhaps we should stop doing them.
Assignee: nobody → coop
Status: NEW → ASSIGNED
Attachment #642925 - Flags: review?(kmoir)
OS: Mac OS X → All
Priority: -- → P2
Hardware: x86 → All
Doesn't mozregression use the inbound builds when doing:
mozregression --repo=mozilla-inbound ?

If we can get mozregression using the tinderbox builds, then that mitigates this slighty, but I know from when doing regressionrange-needed work ages ago, that having both a 24 hour m-c range & also a 24hour range for inbound, sometimes made things easier.
Attachment #642925 - Flags: review?(kmoir) → review+
(In reply to comment #2)
> Doesn't mozregression use the inbound builds when doing:
> mozregression --repo=mozilla-inbound ?
> 
> If we can get mozregression using the tinderbox builds, then that mitigates
> this slighty, but I know from when doing regressionrange-needed work ages ago,
> that having both a 24 hour m-c range & also a 24hour range for inbound,
> sometimes made things easier.

Wouldn't they both give you a big range which should then be bisected manually?
Yes, but the m-c range typically includes the daily large inbound merge, and the inbound range then allows for partial narrowing just due to the time offset.

Don't mind too much either way, just thought I should mention the use-case. Not sure who I could CC who triages regularly now (other than Alice0775 White, who I believe keeps cached tinderbox builds anyway).
(In reply to comment #4)
> Yes, but the m-c range typically includes the daily large inbound merge, and
> the inbound range then allows for partial narrowing just due to the time
> offset.
> 
> Don't mind too much either way, just thought I should mention the use-case. Not
> sure who I could CC who triages regularly now (other than Alice0775 White, who
> I believe keeps cached tinderbox builds anyway).

I think any precise bisection requires the tinderbox builds.  Otherwise one will have to do manual bisection, in which case the bisection range doesn't really matter that much.
Blocks: 774646
Blocks: 774647
In production.
This is finished now yeah?
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Depends on: 775911
Looks like we need to shut off b2g nightlies too: https://github.com/mozilla/buildbot-configs/blob/master/mozilla/b2g_project_branches.py#L25
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #644567 - Flags: review?(bhearsum)
Duplicate of this bug: 775911
Attachment #644567 - Flags: review?(bhearsum) → review+
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Ed, does the same apply to the debug 'nightlies' ? That's really just a script which copies the latest debug build out tinderbox-builds.
(In reply to Nick Thomas [:nthomas] from comment #13)
> Ed, does the same apply to the debug 'nightlies' ? That's really just a
> script which copies the latest debug build out tinderbox-builds.

Yes same applies, we do not need Nightlies on any platform on inbound :-)
Can we please reverse this decision ?
Using inbound build for regression searches helps a lot for bug triage.
Guessing a component and changeset based on a regression range that includes 30 changeset is much better than 170 changesets.
(In reply to comment #15)
> Can we please reverse this decision ?
> Using inbound build for regression searches helps a lot for bug triage.
> Guessing a component and changeset based on a regression range that includes 30
> changeset is much better than 170 changesets.

We still have the tinderbox-builds, right?  Can't we use those for regression detection?
We could if mozregression would support tinderbox builds.
I currently use "hg bisect" before trying to deal manually with tinderbox builds.
(In reply to comment #17)
> We could if mozregression would support tinderbox builds.
> I currently use "hg bisect" before trying to deal manually with tinderbox
> builds.

Oh, I see.  Is it hard to teach mozregression about tinderbox-builds?
>Oh, I see.  Is it hard to teach mozregression about tinderbox-builds?
Dunno, i run if i see a python and don't try to teach a python script something :-)

Without joke: I as bug triager have to use the tools that we have. It should be possible to teach mozregression to use tinderbox builds but i may be a bit complicated.

- currently the directory name is used for the branch and date detection (AFAIK).
The tinderbox builds are in directories without (for me) unknown name scheme.

- In case you have to regression range for comm-central and want a better regression range you have to switch from comm-commercial builds to tinderbox builds.
There is of course a time/date shift that mozregression has to handle. A manual commandline switch in mozregression would be of course also ok.

- The oldest mozilla-inbound tinderbox build is currently from 27.10.2012.
That is useless for regressions that are filed after a release (e.g. bug 814811)
(In reply to Ehsan Akhgari [:ehsan] from comment #18)
> Oh, I see.  Is it hard to teach mozregression about tinderbox-builds?

https://github.com/mozilla/mozregression/issues/39
FWIW, I am in full support of bringing these builds back if they're useful to people.
(In reply to Ehsan Akhgari [:ehsan] from comment #21)
> FWIW, I am in full support of bringing these builds back if they're useful
> to people.

It seems like the right course of action is to fix MozRegression rather than doing unnecessary builds....
(In reply to comment #22)
> (In reply to Ehsan Akhgari [:ehsan] from comment #21)
> > FWIW, I am in full support of bringing these builds back if they're useful
> > to people.
> 
> It seems like the right course of action is to fix MozRegression rather than
> doing unnecessary builds....

True, but not having those builds blocks people who want to find regression ranges, and that is extremely valuable, so unless we find someone who can fix mozregression, we should temporarily re-enable these builds, I think.
Product: mozilla.org → Release Engineering
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #23)
> (In reply to comment #22)
> > (In reply to Ehsan Akhgari [:ehsan] from comment #21)
> > > FWIW, I am in full support of bringing these builds back if they're useful
> > > to people.
> > 
> > It seems like the right course of action is to fix MozRegression rather than
> > doing unnecessary builds....
> 
> True, but not having those builds blocks people who want to find regression
> ranges, and that is extremely valuable, so unless we find someone who can
> fix mozregression, we should temporarily re-enable these builds, I think.

mozregression now bisects inbound after it's down to a one-day granularity (bug 935183). Can we close this?
Flags: needinfo?(ehsan)
(In reply to William Lachance (:wlach) from comment #24)
> (In reply to :Ehsan Akhgari (needinfo? me!) from comment #23)
> > (In reply to comment #22)
> > > (In reply to Ehsan Akhgari [:ehsan] from comment #21)
> > > > FWIW, I am in full support of bringing these builds back if they're useful
> > > > to people.
> > > 
> > > It seems like the right course of action is to fix MozRegression rather than
> > > doing unnecessary builds....
> > 
> > True, but not having those builds blocks people who want to find regression
> > ranges, and that is extremely valuable, so unless we find someone who can
> > fix mozregression, we should temporarily re-enable these builds, I think.
> 
> mozregression now bisects inbound after it's down to a one-day granularity
> (bug 935183). Can we close this?

Sure, but I'm not sure what you mean.  This bug was closed and the builds were never brought back as far as I can tell.
Flags: needinfo?(ehsan)
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #25)

> Sure, but I'm not sure what you mean.  This bug was closed and the builds
> were never brought back as far as I can tell.

Sorry, I missed that and just saw the last comment which hinted that something might still need to be done here. Carry on. :)
You need to log in before you can comment on or make changes to this bug.