create second set of mozilla-central based builders that latch on 'full green'?
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning