create second set of mozilla-central based builders that latch on 'full green'?

Mark Banner mbanner at mozillamessaging.com
Tue May 11 11:13:05 PDT 2010


  On 11/05/2010 18:10, Ben Bucksch wrote:
> On 11.05.2010 18:51, Ben Bucksch wrote:
>>  I think these are all great ideas. Thanks for moving forward on this.
>>
>> One point, though:
>>
>> On 11.05.2010 06:55, Andrew Sutherland wrote:
>>> I would suggest that we do not keep the 'good' revision in revision 
>>> control, but do publish it at a public URL and that we do point 
>>> client.py at it so that random people who want to build Thunderbird 
>>> do not need to deal with breakage.
>>
>> Nice idea, but I think it is better to commit to repo somehow. Maybe 
>> at slower intervals.
I disagree with that. Firstly, it is more non-code noise in the repo 
(and more changesets to pick up), secondly we should be able to do 
anything from client.py with a public URL/web based app that we can do 
from a revision in the repo. In fact, we can do more - e.g. if we'd 
incorrectly marked a revision as "good", we could later go back and mark 
it as bad.

I would support being able to have an offline copy of the file (again 
not in source control) that could be referenced if you're wanting to do 
a set of builds and regression tests whilst offline.

> Actually, let me refine that. My proposal earlier was:
> We commit the *first* (not the last known) revision of m-c that this 
> version of c-c works with, let me call it "GECKO_VERSION_MIN". In 
> other words, whenever we make a m-c bustage/compatibility fix, we also 
> change the "known good" m-c revision. All subsequent checkouts and 
> revisions of c-c then take that this m-c version. Newer versions of 
> m-c can be used on your own risk (that is what tinderbox-canary would 
> track). But you'll always have a good, compatible version of m-c 
> matching this version of c-c.
> You could also add a second version "also known to work with", let's 
> say "GECKO_VERSION_GOOD", which is updated in the repo every week or 
> so, and published on a webserver (SSL, please!). That's the version 
> you talked about.
I think that we should be updating the good version every time we get a 
green build. If a developer is going to run client.py to update, they 
will expect to get the latest good updates to the source, not a several 
day old version (unless, of course, there's bustage).

For instance, if I want to safely pick up the latest m-c changes, e.g. 
because I'm working on something that wants them; then I don't want to 
have to wait 3 days for the automation (or whatever) to decide that its 
time to pick it up, I want to get using that set as soon as I can, i.e. 
as soon as there's a green tree.

> It's not much work to implement this:
>
>     * whenever you make a m-c bustage or compatibility fix, you update
>       GECKO_VERSION_MIN and GECKO_VERSION_GOOD in
>       build/gecko-version.txt in the same commit.
>
That is a step I bet will be forgotten/messed up and why I think this 
should be all automated based on Thunderbird-canary output which can 
feed into the public info.

Standard8
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20100511/0d121a43/attachment.html>


More information about the tb-planning mailing list