Closed Bug 419949 Opened 16 years ago Closed 14 years ago

Give tinderbox the ability to read "guilty" from a feed

Categories

(Webtools Graveyard :: Tinderbox, enhancement)

Product:
Webtools Graveyard
Component:
Tinderbox
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: benjamin, Unassigned)

References

Details

The Mozilla2 tinderbox is building from mercurial and so doesn't have any "guilty" information from bonsai (and won't).

I would like instead for it to take the guilty information from a feed. For the moment, http://hg.mozilla.org/mozilla-central/?rss-log

The relevant information is pubDate and author, I presume.

The guilty list is built by this file: http://mxr.mozilla.org/mozilla/source/webtools/tinderbox/buildwho.pl
Is there a sample output file somewhere? I'm not conversant in Perl and not sure what I would have to setup to run buildwho.pl myself, but if Python would be okay as well, I could probably whip up a script to do this.
Sample output file, or sample input file?
The input is http://hg.mozilla.org/mozilla-central/index.cgi/pushlog

From reading buildwho.pl, I think the output is very simple:

print WHOLOG "$ci->[$::CI_DATE]|$ci->[$::CI_WHO]\n";

But I don't know what date format they're using (or what timezone it's in)... timeless do you know?
We're not going to add python as a requirement for tinderbox1.  If you write the script in python, someone will probably convert it to perl for you.

The date format is the standard unix timestamp.  Timezones aren't accounted for since bonsai & tinderbox are required to live on the same machine and all clients have historically been in the same building. (yay legacy code)

Out of curiosity, do we still need this now that changesets are printed out for each build?
perhaps not... I wonder if we could remove the guilty column entirely.
I think we do need the guilty column.  It's useful to be able to see at a glance who made commits, without having to changeset-dive.
I think it might actually be more important to have an at-a-glance measure of how much was pushed than by whom; the guilty column has served both purposes in the past.  But I think both are important.  (And I don't think the current changeset UI is sufficient, at least not without a good Web interface for getting the complete log of changesets between two changesets (exclusive of the start, and inclusive of the end, preferably).)
Just want to note that right now none of the mozilla2 machines (including unittests) pull by date. I know we can get them to update the 'mozilla' checkout to a certain date, I don't think we can do the same for nss, nspr, or tamarin as easily. I'm not sure how big of a deal that is (I wonder, should we be printing the revision/date for those in the log, to have as something definitive? I think this would be solved as part of bug 433390.)
bhearsum, no: they are pulled by tag, and so there's no variability to worry about.
I'd just like to say that it's much more difficult and time consuming to figure out which patches could be responsible for a regression without the guilty column. Can we get this bug prioritized?
I too am having problems today figuring out which patches went into a particular build.  It'd be much easier with a guilty column and even easier with a link to the list of checkins (a la the "C" link that build reports used to have).

I love this bug enough to own/work on it, if someone can point me to a suitable environment?  How/where does tinderbox development usually happen?  Where can I get the datasets that need to be merged?
It seems that what comment #1 wants is a sample who.dat to compare against.  Who has access to one of these?  morgamic?
One thing we should watch out for is that a build immediately following an entry in the guilty column don't necessarily contain that changeset. That's a fairly subtle change from CVS development.

It all depends on how buildbot merges several changesets - IIRC if there is a slow flow of them you might get a build for each change (and therefore a non-trivial delay), but once they come faster they tend to get combined. Does that make sense BenH ?
justdave can probably paste a sample who.dat from the production box, for comment #1.
(In reply to comment #13)
> I love this bug enough to own/work on it, if someone can point me to a suitable
> environment?  How/where does tinderbox development usually happen?  Where can I
> get the datasets that need to be merged?

There is a staging box on landfill (tinderbox-stage.mozilla.org), and setting up tinderbox locally isn't too hard. Source code is in CVS at mozilla/webtools/tinderbox. #mozwebtools in irc might be helpful if you can't get it going. 

You could probably just focus on adding hgweb support to buildwho.pl though (see comment #0), RSS from hgweb in and who.dat out..
Assignee: morgamic → nobody
(In reply to comment #15)
> One thing we should watch out for is that a build immediately following an
> entry in the guilty column don't necessarily contain that changeset. That's a
> fairly subtle change from CVS development.
> 
> It all depends on how buildbot merges several changesets - IIRC if there is a
> slow flow of them you might get a build for each change (and therefore a
> non-trivial delay), but once they come faster they tend to get combined. Does
> that make sense BenH ?
> 

Hrm. I don't _think_ this is true. When we get a trickle of checkins over time it will cause many builds to start, or be queued. If the builds all start right away this certainly couldn't cause the behaviour you describe. I think you assume that if we have multiple builds queued, that we will get a Build for each one queued -- this is not the case. If multiple builds are queued they will get merged into one build when a slave becomes free. When this happens, and a change comes in *right* after that build starts it might be close, but I don't think this could happen....

To be quite honest though, I'm not 100% confident that it cannot happen.
Example of what SeaMonkey/... should want: (These are ideas...)

The basic feature is the "C" link (as for Firefox): see comment 8.

But, as SM now builds from 3 Hg repositories (Mozilla-C + Comm-C + DomI),
the basic feature may need to be extended to report for all the repositories (one under the other, not merged).
So, extend the basic feature to take an input list of Hg repos to check.

(additionally) we might want the still-cvs "repositories" too:
Not Ldap-Sdk (pulled by tag), but calendar and extensions (cz, venkman, taf, wallet).
So, either extend the "Hg" feature further to take an input list of cvs paths to check,
or extend the current cvs "C" link to do it...
and maybe have a "C-Hg" and a "C-cvs" links, or merge the results if possible.
(In reply to comment #19)
> Example of what SeaMonkey/... should want: (These are ideas...)
> 
> The basic feature is the "C" link (as for Firefox): see comment 8.
> 
> But, as SM now builds from 3 Hg repositories (Mozilla-C + Comm-C + DomI),
> the basic feature may need to be extended to report for all the repositories
> (one under the other, not merged).
> So, extend the basic feature to take an input list of Hg repos to check.
> 

To simplify things on the Tinderbox side this could be done by aggregating all the needs you care about into one, and having Tinderbox watch that. This could be beneficial to anyone else that wants to watch commits too.

(In reply to comment #20)

You mean doing the watching+merging into a feed that Tinderbox would take as input ?
(with a format to tell which update comes from which "repo", etc.)
Sure, sounds good to me !
(Should I file another bug about that ? In which component ?)
If you want to...sure. I'm just brainstorming...
Severity: normal → enhancement
OS: Linux → All
Hardware: x86 → All
This would probably be easiest if we moved to Tinderbox 2, as T2's columns are modular.  E.g., you can write a perl module for an hgweb-driven guilty column, without affecting anyone else's cvs-style guilty columns.  Bug 48679.

I doubt there will be enough momentum to do that, but that's my 2 cents.
Tinderbox is dead, long live tbpl, I say.  I argue WONTFIX.
WONTFIX due to TBPL.  Reopen if you disagree.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.