Can we change try-comm-central to build using mozilla-2.0 by default?

2 views
Skip to first unread message

Andrew Sutherland

unread,
Mar 24, 2011, 9:17:45 PM3/24/11
to tb-pl...@mozilla.org
While I see us wanting to be able to use the try-server to build against
both mozilla-2.0 and mozilla-central, I expect that:
- the people who will want to build against mozilla-central will know
how to force it to use mozilla-central, namely Standard8
- most patches will be targeting TB 3.3 until we lock it down, so the
friendliest thing is to build for TB 3.3 (mozilla-2.0)

As such, I propose we do something that makes the try-server use
mozilla-2.0 by default. This is especially relevant because our mozmill
tests already seem broken on mozilla-central. (Maybe because of
extension compatibility/something trivial, maybe because of something
weird and complex.)

Andrew

_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

Mark Banner

unread,
Mar 25, 2011, 6:05:10 AM3/25/11
to tb-pl...@mozilla.org
On 25/03/2011 01:17, Andrew Sutherland wrote:
> While I see us wanting to be able to use the try-server to build
> against both mozilla-2.0 and mozilla-central, I expect that:
> - the people who will want to build against mozilla-central will know
> how to force it to use mozilla-central, namely Standard8
(add a client.py patch into the patch tree that you're pushing to change
the location of MOZILLA_REPO).

> - most patches will be targeting TB 3.3 until we lock it down, so the
> friendliest thing is to build for TB 3.3 (mozilla-2.0)
>
> As such, I propose we do something that makes the try-server use
> mozilla-2.0 by default. This is especially relevant because our
> mozmill tests already seem broken on mozilla-central. (Maybe because
> of extension compatibility/something trivial, maybe because of
> something weird and complex.)
We can do this quite easily by getting try server to add the
--mozilla-repo argument. The only disadvantage of this is that its then
harder to push for other repos, including 1.9.2, (we'd need to adjust
client.py a bit more to ignore that argument), but we can at least stick
that on a wiki page.

I think I'm in agreement with this idea, it seems the right thing to do
at the moment.

(btw the new trunk will hopefully be set up later today)

Mark.

Reply all
Reply to author
Forward
0 new messages