<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 11/05/2010 18:10, Ben Bucksch wrote:
<blockquote cite="mid:4BE98F9C.80906@beonex.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 11.05.2010 18:51, Ben Bucksch wrote:
<blockquote cite="mid:4BE98B18.2030001@beonex.com" type="cite"> I
think these are all great ideas. Thanks for moving forward on
this. <br>
<br>
One point, though: <br>
<br>
On 11.05.2010 06:55, Andrew Sutherland wrote: <br>
<blockquote type="cite">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. <br>
</blockquote>
<br>
Nice idea, but I think it is better to commit to repo somehow.
Maybe at slower intervals.<br>
</blockquote>
</blockquote>
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.<br>
<br>
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.<br>
<br>
<blockquote cite="mid:4BE98F9C.80906@beonex.com" type="cite">
Actually, let me refine that. My proposal earlier was:<br>
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.<br>
</blockquote>
<blockquote cite="mid:4BE98F9C.80906@beonex.com" type="cite"> 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.<br>
</blockquote>
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).<br>
<br>
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.<br>
<br>
<blockquote cite="mid:4BE98F9C.80906@beonex.com" type="cite"> It's
not much work to implement this:<br>
<ul>
<li>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.</li>
</ul>
</blockquote>
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.<br>
<br>
Standard8<br>
</body>
</html>