<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 5/11/2010 12:37 PM, Mark Banner wrote:
<blockquote cite="mid:4BE987C3.6050601@mozillamessaging.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 11/05/2010 05:55, Andrew Sutherland wrote:
<blockquote cite="mid:4BE8E34C.4090108@asutherland.org" type="cite"> Now
that active development is starting to happen on comm-central and it's
not just a canary for 'future problems', perhaps we should consider
actually having two sets of Thunderbird comm-central builders:<br>
</blockquote>
I think you're right that we need to consider both alternate methods of
allowing development to continue.<br>
<blockquote cite="mid:4BE8E34C.4090108@asutherland.org" type="cite">1)
Thunderbird-canary. Always builds latest mozilla-central. <br>
2) Thunderbird. Always builds the most recent revision of
mozilla-central that got greens on all platforms in a
Thunderbird-canary build. <br>
</blockquote>
...<br>
<blockquote cite="mid:4BE8E34C.4090108@asutherland.org" type="cite">a)
have to run around doing heroic things to un-break the build when they
do cause comm-central-only breakage, or worse yet, request that they
back things out because of our problems. <br>
</blockquote>
Ok, so first and foremost, we should *never* be requesting that they
back-out because of our problems. The only time I think they should
consider backing out because of problems raised by our tree is when
we've clearly picked up an issue in one of our test cases that they
haven't covered, i.e. its a true bustage that could affect Firefox as
well (for instance, I know we've picked up js faults in the past).<br>
<br>
<blockquote cite="mid:4BE8E34C.4090108@asutherland.org" type="cite">b)
have the comm-central tree in a questionable state where we cannot tell
mozilla-central breakage from our own breakage and hence need to close
the tree. <br>
</blockquote>
Indeed, that is the most difficult issue.<br>
<br>
So before we go into the specifics of your proposal, I'd like to just
go through some of the most frequent bustage areas that we've been
seeing:<br>
<ul>
<li>Build Config</li>
<ul>
<li>m-c has been doing a lot of rework on build config areas and
have been either breaking non-libxul builds, or changing things such
that we need to port them across to comm-central build config.</li>
<li>These are two things that I think we can consider improving:</li>
<ul>
<li>Ted is currently working on a way to include app specific
components within the libxul library [1]. This is for non-xulrunner
builds, but would mean that we could be built like Firefox, as mailnews
could be linked into libxul *and* use internal linkage. I probably need
to cover this in more detail elsewhere, but this would certainly help
to match us closer to FF and reduce bustage.</li>
<ul>
<li>This would also mean we could go onto using packaged
tests, which would further help with matching FF.<br>
</li>
</ul>
<li>Reworking how comm-central works. I've had on my plate for
a while (and unfortunately I've just not got round to it yet) to start
a conversation on how to improve how we do comm-central. Basically
looking at the ways of reducing the need to port bugs from
mozilla-central all the time.</li>
</ul>
</ul>
</ul>
</blockquote>
<br>
I have to say, that Reworking on comm-central works I've also had on my
plate for a while, perhaps we (me, you, KaiRo, and Gozer; maybe even
ted) should try to sketch out a block of time to discuss/brainstorm. I
have some ideas myself on this front, that would reduce/eliminate the
need for 99% of the build-config ports! [If it all works according to
plan]<br>
<br>
-- <br>
~Justin Wood (Callek)<br>
<br>
</body>
</html>