Re: Merging comm-central into mozilla-central (summary v1)
From my points of view, merging thunderbird back into mozilla source tree is not a good idea. And I think we need to html-ize the Thunderbird source tree, and remove the C/C++ dependencies to gecko as much as possible. And merging the comm back into mozilla-central is getting comm to be to BIG to maintain. I suggest to getting comm into github, and moving all the related issues into github but not mozilla bugzilla, that's too hard to creating a pull request and contributing codes. Indeed, I think the best way is to reactive the gecko xulrunner, and getting Thunderbird only dependence to XULRunner, And the thunderbird only need to compitable with the most ESR released version of XULRunner, and doesn't need to tracing the mozilla gecko patches in such a fast way. They are running in totally different patching speed. On Fri, Nov 6, 2015 at 11:32 PM, ISHIKAWA,chiaki wrote: > On 2015/10/27 9:06, Philipp Kewisch wrote: > >> Hi all, >> >> I'd love to see if we can move towards an agreement. For those of you >> that would prefer not to merge, I'd love to hear what your absolute >> minimum requirements would be that you'd accept a merge with. Changes to >> hg? Changes to dxr? A policy chanage? If we can establish clear >> requirements, maybe we can see they are not so hard to fulfill and we >> can come to an agreement quickly. Ideally, I'd like to find a middle >> ground here that is acceptable to everyone. >> >> Let me summarize requirements I have read: >> >> * Thunderbird bustages should not close Firefox trees >> * A version of dxr that does not show comm projects >> * A version of dxr that shows all projects >> * Treeherder remains separate >> * Normal m-c try pushes don't automatically build Thunderbird >> * There should be a commitment that comm projects will be regularly >> maintained at least in the foreseeable future >> >> * Thunderbird builds should not run on every m-c/m-i commit >> * The default checkout should not contain comm projects >> * It does not make sense if Thunderbird will be separate short term >> * There should be least amount of pressure to fix Thunderbird things for >> Firefox contributors >> >> >> If these are the requirements, with the exception of narrow clones which >> as I've understood are not stable yet, I believe they are all fairly >> easy to fulfill. >> >> Are there any other requirements I've missed? >> >> Philipp >> >> > I think the above summarizes the discussions and counter-points raised > rather well. > > Although I don't hear from many volunteers who send in TB patches > occasionally > in this thread, I believe many of them would work hard to make the > following a reality: > > > There should be a commitment that comm projects will be regularly > > maintained at least in the foreseeable future > > [Of course, there is NO contract by the user community, so "commitment" is > a rather > vague term here. I can't speak for others.] > > I, for one, use TB for regular work at the office and at home regularly, > and > have come to depend on it. So any serious bugs that I find (and there are > many > unfortunately) *HAVE* to be fixed eventually and so I try to send patches. > Some may send in patches to fix these bugs, and others may send in patches > to bring in new features. But if there are a million users out there, > I bet there are a couple hundred volunteers who can program. (I think > there was a statistics > compiled by someone to show the user community contribution in terms of > patches sent in > by individuals in the last few years after Mozilla foundation put TB at > the mercy of > user community.) > > And to make this maintenance easier (less breakage of tree herder > compilation, less duplication of slightly different similar documents > etc.), the merge is preferable from the standpoint of developers IMHO. > > TIA > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Merging comm-central into mozilla-central (summary v1)
On 2015/10/27 9:06, Philipp Kewisch wrote: Hi all, I'd love to see if we can move towards an agreement. For those of you that would prefer not to merge, I'd love to hear what your absolute minimum requirements would be that you'd accept a merge with. Changes to hg? Changes to dxr? A policy chanage? If we can establish clear requirements, maybe we can see they are not so hard to fulfill and we can come to an agreement quickly. Ideally, I'd like to find a middle ground here that is acceptable to everyone. Let me summarize requirements I have read: * Thunderbird bustages should not close Firefox trees * A version of dxr that does not show comm projects * A version of dxr that shows all projects * Treeherder remains separate * Normal m-c try pushes don't automatically build Thunderbird * There should be a commitment that comm projects will be regularly maintained at least in the foreseeable future * Thunderbird builds should not run on every m-c/m-i commit * The default checkout should not contain comm projects * It does not make sense if Thunderbird will be separate short term * There should be least amount of pressure to fix Thunderbird things for Firefox contributors If these are the requirements, with the exception of narrow clones which as I've understood are not stable yet, I believe they are all fairly easy to fulfill. Are there any other requirements I've missed? Philipp I think the above summarizes the discussions and counter-points raised rather well. Although I don't hear from many volunteers who send in TB patches occasionally in this thread, I believe many of them would work hard to make the following a reality: > There should be a commitment that comm projects will be regularly > maintained at least in the foreseeable future [Of course, there is NO contract by the user community, so "commitment" is a rather vague term here. I can't speak for others.] I, for one, use TB for regular work at the office and at home regularly, and have come to depend on it. So any serious bugs that I find (and there are many unfortunately) *HAVE* to be fixed eventually and so I try to send patches. Some may send in patches to fix these bugs, and others may send in patches to bring in new features. But if there are a million users out there, I bet there are a couple hundred volunteers who can program. (I think there was a statistics compiled by someone to show the user community contribution in terms of patches sent in by individuals in the last few years after Mozilla foundation put TB at the mercy of user community.) And to make this maintenance easier (less breakage of tree herder compilation, less duplication of slightly different similar documents etc.), the merge is preferable from the standpoint of developers IMHO. TIA ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Merging comm-central into mozilla-central (summary v1)
Hi all, I'd love to see if we can move towards an agreement. For those of you that would prefer not to merge, I'd love to hear what your absolute minimum requirements would be that you'd accept a merge with. Changes to hg? Changes to dxr? A policy chanage? If we can establish clear requirements, maybe we can see they are not so hard to fulfill and we can come to an agreement quickly. Ideally, I'd like to find a middle ground here that is acceptable to everyone. Let me summarize requirements I have read: * Thunderbird bustages should not close Firefox trees * A version of dxr that does not show comm projects * A version of dxr that shows all projects * Treeherder remains separate * Normal m-c try pushes don't automatically build Thunderbird * There should be a commitment that comm projects will be regularly maintained at least in the foreseeable future * Thunderbird builds should not run on every m-c/m-i commit * The default checkout should not contain comm projects * It does not make sense if Thunderbird will be separate short term * There should be least amount of pressure to fix Thunderbird things for Firefox contributors If these are the requirements, with the exception of narrow clones which as I've understood are not stable yet, I believe they are all fairly easy to fulfill. Are there any other requirements I've missed? Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
