Proposal: Move Thunderbird and SeaMonkey to mozilla-central

classic Classic list List threaded Threaded
143 messages Options
1 ... 5678
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Jeremy Morton-2
On 03/04/2014 11:15, Mark Banner wrote:

> [Forwarding to correct newsgroups for TB & SM, please follow-up to
> mozilla.dev.planning]
>
> -------- Forwarded Message --------
> Subject: Proposal: Move Thunderbird and SeaMonkey to mozilla-central
> Date: Thu, 03 Apr 2014 11:13:00 +0100
> From: Mark Banner <[hidden email]>
> CC:
> Newsgroups:
> mozilla.dev.platform,mozilla.dev.planning,mozilla.dev.thunderbird,mozilla.dev.seamonkey,mozilla.dev.apps.calendar
>
> Followup-To: mozilla.dev.planning
>
> [follow-ups to mozilla.dev.planning]
>
> tl;dr We're proposing to move Thunderbird and SeaMonkey into
> mozilla-central to reduce maintenance complexities for build systems,
> and for releng. Multiple-app handling in the same repository has
> improved greatly, and the general rules would remain the same.
>
> Feedback and discussion is most welcome - we have generally discussed
> this within some individuals, but not widely.

Wouldn't this make it harder to fully fork SeaMonkey if Mozilla really
screw things up and make it hard to maintain the SM interface, come
Australis?

Wouldn't this make it harder for SM devs to check things in?  With its
own repo, SM's repo retains more of a degree of independence.

--
Best regards,
Jeremy Morton (Jez)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Robert Kaiser
Jeremy Morton schrieb:
> Wouldn't this make it harder to fully fork SeaMonkey if Mozilla really
> screw things up and make it hard to maintain the SM interface, come
> Australis?

No. It doesn't mean that more *code* would be shared.

> Wouldn't this make it harder for SM devs to check things in?  With its
> own repo, SM's repo retains more of a degree of independence.

No, not likely.

KaiRo
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Gregory Szorc-3
In reply to this post by Benjamin Smedberg
On 4/11/14 10:20 AM, Benjamin Smedberg wrote:

> On 4/9/2014 12:58 PM, Gervase Markham wrote:
>> I am not going to dispute bsmedberg's assertion that, absent Brendan,
>> he's the primary decision maker. But it would be awesome if he could
>> outline what steps might be taken to "get to yes" on this issue. Do
>> you need a DXR patch so it has a checkbox for "include Thunderbird"?
>> Something else? Gerv
>
> I still believe that the best and fastest solution here is to merge m-c
> into comm-central so that there is a single tree with all the sources
> but don't push that merge to mozilla-central. In terms of local
> development with MQ at least, it is pretty trivial to split patches into
> two pieces, the part that touches comm/ and the part which doesn't. I
> know jcranmer still has concerns about this, but it doesn't seem to me
> any more complicated than the existing two-repo structure.  And as a
> bonus, we could still decide to merge the repos in the future. The only
> technical issue I can think of is you probably want a server hook to
> prevent people committing gecko changes only into comm-central.
>
> In the other case, we would need the following things:
>
> * exclude the comm/ tree in the local checkout by default
> * make DXR/MXR index the Firefox-only sources by default
> * make sure that comm-only commits don't trigger Firefox builds (on
> mozilla-central)
> * make sure that local bisection tools ignore comm-only commits

There are forces at work to add partial clones and partial checkouts as
core features in Mercurial. Those features shift the burden of
completion of the above list of "blockers" into purely Mozilla's hands.
I don't know what the timetable of this support will be.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
1 ... 5678