453433 - Allow tree status to be controlled via a flag on non-bonsai controlled trees (and fix quickparse.txt)

Status: RESOLVED INVALID

(Webtools Graveyard :: Tinderbox, enhancement)

Description

[Mark Banner (:standard8)]

Since moving to hg and having the tinderbox trees disassociated from bonsai, Tinderstatus hasn't been able to determine the open/closed state of the tree. This is because quickparse.txt no longer shows the open/closed state e.g. compare the output of following two urls:

http://tinderbox.mozilla.org/Firefox/quickparse.txt
http://tinderbox.mozilla.org/Firefox3.0/quickparse.txt

The latter has a "State" line, but the former doesn't.

My proposal would be (on non-bonsai controlled trees) to provide a field on the adminster tinderbox page (http://tinderbox.mozilla.org/admintree.cgi?tree=Firefox) to tell the server if the tree is open or not.

The field can then be reproduced in an appropriate manner for the main tinderbox UI page, and can also be reproduced onto quickparse.txt so that extensions such as tinderstatus and bots such as firebot can pick up the open/closed state.

Comment 1

[cls]

The logistical problem is that tinderbox doesn't control the open/closed state of the repository.  That state means nothing to tinderbox.  It just happens to display the value provided by bonsai.  Ideally, any other system that is hooked into tinderbox (e.g. viewvc or hg) should provide that information so that tinderbox remains a pass-thru. 

In bug 419949, there is discussion on how to display hg commits via tinderbox.  How is hg told whether a tree is open or closed?  Is there a bonsai-like wrapper to get all of this information out of hg?  Or are we just cobbling things together hoping that they will work somehow?

Comment 2

[Benjamin Smedberg]

hg doesn't know whether the tree is open. We don't track tree open/closed state any more except on the tinderbox itself as part of the status message.

Comment 3

[Mark Banner (:standard8)]

(In reply to comment #1)
> In bug 419949, there is discussion on how to display hg commits via tinderbox. 
> How is hg told whether a tree is open or closed?  Is there a bonsai-like
> wrapper to get all of this information out of hg?  Or are we just cobbling
> things together hoping that they will work somehow?

Like Benjamin said, afaik there isn't a way for hg to know if the tree is open or not (though I'm sure someone will correct me if I am wrong) - exactly the same that we've had for cvs for however many years that has been in use.

For all those years we have been telling committers to check the tree first, both for red/orange/green status and open/closed. We're still doing that.

The only difference we had with cvs was bonsai. That's now gone, so I think tinderbox should be able to control its own tree state.

I'm saying that we should a) make it easy for folks to open and close individual trees, b) allow the status to be reported via quickparse.txt (for tinderstatus + others to use so that developers can get a quick idea of the tree state without having to go to the page).

Comment 4

[cls]

I understand the request.  I'm just not convinced that it's the best design.

With bonsai (which isn't gone, just doesn't support hg), you could close one repository and have that change automatically propogated to N tinderbox trees.  With the request as stated, you would have to manually close N tinderbox trees anytime you wanted to freeze a hg repository assuming that you still have multiple trees using a single repository.  That seems highly inefficient in the long run.

I think that you really do want a bonsai-like replacement to handle this. Or...and though I really shouldn't be encouraging people to build upon it for the reasons listed in the bug....you could enhance tinderbox to truly manage repositories/query sources using reed's work in bug 398050 as a basis.  It would allow you to efficient handle multiple tree closures while keeping tinderbox as a standalone entity.

Comment 5

[Mark Banner (:standard8)]

With the current method of closing the tree and an hg hook picking it up, this seems to be "working". I don't see this going anywhere so closing it as it probably needs a better overall design to make these things easy.