345948 - Want facility for downloading multiple nightlies for pinpointing bug manifestation dates

Status: RESOLVED WORKSFORME

(mozilla.org :: Miscellaneous, task, P3)

Description

[Eyal Rozenberg]

Often when I find some bug I need to locate the exact day in which it began to manifest. What I do now is perform a binary search using the directory listing:

http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/

plus, I need to guess which of the directories for any given day contains the build for my platform. And I have to make sure and name all the files according to dates.

What I'd like is for a nice web form into which I enter my platform, the relevant branch/product/whatever, my upper limit build and lower limit build, and a parameter N, and what I get would be 
download links to N builds starting from my lower limit and ending in my upper limit, with almost-equal date intervals.

Comment 1

[J. Paul Reed [:preed]]

Not currently working on this; sounds interesting, though.

I'll reassign to myself if I have some extra time to play with it.

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

db48x wrote a script that does a bunch of this, see
  http://db48x.net/regression-search/

Closing out in favor of that.

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

CC'ing the author.

Comment 4

[Eyal Rozenberg]

Hey, the fact that someone wrote a script that downloads builds (which, by the way, is not that portable/robust, I tried getting it to run and got various error messages at the time which I don't recall exactly; website says: "Currently it assumes you want tarballs, but this is incorrect on windows and mac") doesn't mean there official servers shouldn't offer this facility.

Plus, it's impolite to close unconfirmed bugs after two years without even the appreance of some discussion. I ask that this be reopened.

Comment 5

[[e-mail] (:bhearsum)]

I understand your concerns Eyal, but nobody cc'ed or otherwise looking at this bug is planning to do anything about this (unless they have not yet spoken up). Given that this bug was filed, and after nearly two years (with the 'helpwanted' keyword) nothing has been done on it I agree that it's time to close it out. All it's doing is distracting us from bugs that are being worked on, or will be worked on.

Comment 6

[Eyal Rozenberg]

(In reply to comment #5)

As you well know, there are many important, even critically important bugs which wait years without anyone planning to work on them (to give an example from my own experience - a libmime rewrite; or maybe even the famous bug 915). That's never been a reason to close them. 

> Given that this bug was filed, and after nearly two years (with the
> 'helpwanted' keyword) nothing has been done on it I agree that it's time to
> close it out. 

So you're deciding noone should ever resolve this because for two years the existing developers have not gotten around to working on it? If you were to argue that it is not necessary/worth the effort to have this feature, that's something else, but an argument from inertia is not valid IMO.

> All it's doing is distracting us from bugs that are being worked
> on, or will be worked on.

From my experience as a Mozilla (mostly extension) developer and the experience of others it has never been the case that the existence of certain open bugs is distracting from working on others. Remember the Mozilla project has tens of thousands of open bugs, most of which nobody is working on. I believe this excuse is somewhat flimsy.

So, again, I request that this be reopened.

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

We're just saying that we (the Release Engineering team) aren't going to fix this. If you can find somewhere else in Bugzilla for this to live then feel free to reopen it.

Comment 8

[Eyal Rozenberg]

It's in 'Future' - isn't that where things you aren't fixing for the time being are supposed to live?

You know what a WONTFIX means, and you're marking this WONTFIX without making a valid argument for doing that. Why can't you just leave it as NEW?

Comment 9

[[e-mail] (:bhearsum)]

'Future' is for things that we _will_ be fixing in the future.

Comment 10

[Chris Cooper [:coop] (he/him)]

This has nothing at all to do with our release engineering process. If you are going to reopen, please assign it to QA or similar.

I might also point out that the Moz QA still searches for regression ranges by hand because they're luddites (j/k) and because they end up throwing away fewer downloads.

Comment 11

[Daniel Brooks [:db48x]]

Eyal, I feel your pain. If they don't want this bug we can take it somewhere else.

The script I wrote solves the problem fairly well for me (and if the QA team doesn't use it that's their problem - it caches all the builds it downloads so that it doesn't have to download anything twice) but it has a number of areas that need improvement, such as windows support. However, it's not the only game in town. Ted Meilczarek created a buildbot that uses this script to provide a pure web service that does regression finding. All the user has to do is upload a testcase and it does the rest. I think that would be the best way to solve this particular bug. All that needs to happen is for the script to work on windows and mac and then we can set up windows and mac buildbots. I don't know how much traffic Ted is willing to support, but at least that would be a good start.

Reopening, but not moving it yet until I find a better component for it.

Comment 12

[Eyal Rozenberg]

Changing QA contact as per Chris' suggestion.

Comment 13

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

hi Eyal, Daniel;

After 21 months of inaction, its interesting to see all the activity since our triage a couple of days ago!


I am sorry that it took us so long to triage through all our bugs and find this languishing bug. In recent months, we're triaging our bugs more regularly. This includes making sure that bugs we are supposed to work on are correctly prioritized and making sure that any misfiled/invalid bugs are reassigned/closed. 

While you may not like the status of WONTFIX, it does at least accurately reflect our triage assessment of this bug:
- we have not worked on this
- we have no plans to work on this
- we believe this bug is misfiled, and is not in our scope of work
- no-one else has provided patches, in 21 months of inaction. (The script that Daniel provided in July2007 was not linked to this bug until during our triage a few days ago, and its unclear to me if Daniel knew of this bug until we cc'd him, again as part of our triage.)

I note this bug was just reopened, and is back in our triage queue again. For now I'm moving this reopened bug to mozilla.org/Miscellaneous, which seems more appropriate. Obviously feel free to reassign further if/when you find an even more appropriate component for this bug.

Comment 14

[:Gavin Sharp [email: [e-mail]]]

http://mozilla.github.com/mozregression/ exists now too.