450927 - SeaMonkey Buildbots should poll for domi changes as well

Status: RESOLVED WONTFIX

(SeaMonkey :: Release Engineering, defect)

Description

[Justin Wood (:Callek)]

Attachment: poll domi

Following the change in Bug 437064 SeaMonkey buildbots should also poll the DOMI changesets for building.

Comment 1

[Robert Kaiser]

I'm not too sure about this because of two reasons:
1) The hidden magic the HgPoller is doing has caused enough problems with polling both mozilla-central and comm-central and the hacky workaround we're using is nothing I really like to extend to additional cases. We should have a HgPoller that cleanly allows us to deal with this, either through not setting "branch" and "revision" at all or setting them in a way that they don't conflict with the main one (the latter would perhaps enable us to make client.py pull exact revisions if different modules).
2) I don't like hardcoding repo names in master.cfg, this should be set in a var in config.py.
3) we don't poll for venkman or chatzilla changes either currently - either we should poll all of those or none, IMHO.

Comment 2

[Justin Wood (:Callek)]

Comment on attachment 334141 [details] [diff] [review]
poll domi

This will go on the back burner, per IRC convo with KaiRo; when we have a buildbot poller that works for our different Hg Branches we can revisit this idea.

Comment 3

[Serge Gautherie (:sgautherie)]

KaiRo,
Has HgPoller improved since then? Otherwise, is there a bug filed about that?
DOMi and JSD are in hg, CZ and Directory are in cvs: does that make a difference?

Comment 4

[Robert Kaiser]

I have no time right now to look into this, it's a very very very low priority issue for me - none of the extensions change often enough that it actually matters.

Comment 5

[Serge Gautherie (:sgautherie)]

CZ is eventually moving to hg too :-)
And LDAP is planned too, probably after TB 3.0 is released :-)

Comment 6

[Justin Wood (:Callek)]

(In reply to comment #4)
> I have no time right now to look into this, it's a very very very low priority
> issue for me - none of the extensions change often enough that it actually
> matters.

Thinking on this, I actually am reversing my initial thoughts on this bug, I'm marking WONTFIX for now. We can revisit when and if the extension(s) change more frequently than c-c or m-c, which is where we _really_ need to care about.