Re: Leaving hg.mozilla bug.mozilla to github for the leaving complicated infrastructure of mozilla.

[Yonggang Luo]

On Fri, Dec 4, 2015 at 3:55 PM, R Kent James  wrote:

> Yonggang Luo, I've been trying to figure out how to understand what you
> are doing for over a year now without success. You've been doing some
> amazing work, and I get the vague impression that you are working on a
> Chinese fork of Thunderbird. Now you are proposing some specific changes to
> Thunderbird infrastructure, but you are really not a Thunderbird
> contributor. Could you give some sort of public statement of how your
> technical work fits into the broader picture of products?
>
Indeed, I've been trying to do contribute back to the Thunderbird
community, but that's too hard for me, the Thunderbird is always pursuing
the mozilla-central, and we (our company) need a stable version of
mozilla-central to release our product, and that's makes me hard to
contribute back things, and we are using git but hg to do the
version control, and that's also complicated our contribution progress.



> I've been trying to get people working on open-source email clients to
> talk to teach other and figure out ways to work together better. In my
> dreams, we all work together to make an amazing product rather than have
> small teams each duplicating each other's work. We'd love to be able to
> work with you, even if you are not specifically contributing to
> Thunderbird. But I have no context now to understand how.
>
When I trying to ease the development burden of Thunderbird, I didn't two
things,
1、Building Xulrunner independently,  So the xulrunner is a stable version.
2、Building our customized Thunderbird without mozilla source, and only
depends on Xulrunner.

When I trying submit a patch to thunderbird community, that's always need
to create a
bug in bug.mozilla.org, and that's very hard to use and slow.
The merging progress are very slow. That's why I am hesitate to
contributing things back.

>
> R. Kent James
> Chair, Thunderbird Council
>
>
> On 12/3/2015 8:52 PM, 罗勇刚(Yonggang Luo)  wrote:
>
>> I think the relationship between Thunderbird/SeaMonkey and
>> gecko-dev should be like the relation ship between Atom editor vs
>> Electron.
>> So there is no need that Thunderbird/SeaMonkey chasing the
>> mozilla-central.
>> And considerate the hard for contributing code in mozilla infrastructure
>> for thunderbird,
>> I suggest to completely to leave the mozilla infrastructure.
>> To reach this target, we need to do the following things.
>> 1、All the repos are git based and hosted on github
>> I've already writing scripts to mirror all branches/tags of comm &
>> gecko-dev,
>> They are now placed at
>> https://github.com/mail-apps/comm
>> https://github.com/mail-apps/gecko-dev
>> I have the scripts to do that.
>> After the migration, we only need to maintain the gecko-dev mirror
>> 2、Thunderbird/SeaMonkey bugs moved to github.
>>  I didn't write the scripts yet,
>> 3、The leaving Makefile.in should be clear up,
>> 4、Removing all the #if #endif in
>>   xul/js/mozilla files. This is not a must be procedure
>>   We may hack the mozbuild system that
>>   generate install_manifests for those files.
>> 5、Leaving the C/C++ building system from moz.build
>>  This is very important, cause the current moz.build for building
>>  are to tight with the lowering mozilla building infrastructure, and
>> if
>> we want to leaving the mozilla source tree, this would be a
>> unavoidable step.
>>  For building C/C++, we may choose gyp/cmake/qbs or other means
>>  that's was a self-contained echo-system and that's doesn't depends on
>>  the complicated mozbuild eco-system.
>> For example: LLVM are leaving autoconf to CMake.
>> We may choose, cause Thunderbird/SeaMonkey is much
>>  smaller than gecko-dev, so that's won't be a big deal.
>>
>> 6、 Building the All Thunderbird C/C++ compoents as a single
>>  thunderbird.dll or other things. I've already implement that, and
>> doesn't
>>  need to modify much of the source code.
>> 7、Getting all the locales install to be build with pure python.
>>  This is necessary, and because of this, we may also need to convert
>> all
>> the locales
>>   repo from hg to git.
>>  Or we may using a much simpler method. place all the locales files
>> into
>> the comm source-tree.
>>
>> 8、Building xulrunner distribution for Thunderbird/Gecko like
>> https://github.com/atom/electron/releases, so we only need to downloading
>> those binaries.
>>
>> 9、Packaging the mozbuild building system into the xulrunner, so that we
>> won't need
>>   the whole mozilla source-tree.
>> 10、 The xulrunner only chasing for stable version of firefox, unless there
>> is much need of new functional, then the xulrunner only based on ESR
>> version of firefox.
>>
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 
 此致
礼
罗勇刚
Yours
  

Re: Leaving hg.mozilla bug.mozilla to github for the leaving complicated infrastructure of mozilla.

[R Kent James]

Yonggang Luo, I've been trying to figure out how to understand what you 
are doing for over a year now without success. You've been doing some 
amazing work, and I get the vague impression that you are working on a 
Chinese fork of Thunderbird. Now you are proposing some specific changes 
to Thunderbird infrastructure, but you are really not a Thunderbird 
contributor. Could you give some sort of public statement of how your 
technical work fits into the broader picture of products?


I've been trying to get people working on open-source email clients to 
talk to teach other and figure out ways to work together better. In my 
dreams, we all work together to make an amazing product rather than have 
small teams each duplicating each other's work. We'd love to be able to 
work with you, even if you are not specifically contributing to 
Thunderbird. But I have no context now to understand how.


R. Kent James
Chair, Thunderbird Council

On 12/3/2015 8:52 PM, 罗勇刚(Yonggang Luo)  wrote:

I think the relationship between Thunderbird/SeaMonkey and
gecko-dev should be like the relation ship between Atom editor vs Electron.
So there is no need that Thunderbird/SeaMonkey chasing the mozilla-central.
And considerate the hard for contributing code in mozilla infrastructure
for thunderbird,
I suggest to completely to leave the mozilla infrastructure.
To reach this target, we need to do the following things.
1、All the repos are git based and hosted on github
I've already writing scripts to mirror all branches/tags of comm &
gecko-dev,
They are now placed at
https://github.com/mail-apps/comm
https://github.com/mail-apps/gecko-dev
I have the scripts to do that.
After the migration, we only need to maintain the gecko-dev mirror
2、Thunderbird/SeaMonkey bugs moved to github.
 I didn't write the scripts yet,
3、The leaving Makefile.in should be clear up,
4、Removing all the #if #endif in
  xul/js/mozilla files. This is not a must be procedure
  We may hack the mozbuild system that
  generate install_manifests for those files.
5、Leaving the C/C++ building system from moz.build
 This is very important, cause the current moz.build for building
 are to tight with the lowering mozilla building infrastructure, and if
we want to leaving the mozilla source tree, this would be a
unavoidable step.
 For building C/C++, we may choose gyp/cmake/qbs or other means
 that's was a self-contained echo-system and that's doesn't depends on
 the complicated mozbuild eco-system.
For example: LLVM are leaving autoconf to CMake.
We may choose, cause Thunderbird/SeaMonkey is much
 smaller than gecko-dev, so that's won't be a big deal.

6、 Building the All Thunderbird C/C++ compoents as a single
 thunderbird.dll or other things. I've already implement that, and
doesn't
 need to modify much of the source code.
7、Getting all the locales install to be build with pure python.
 This is necessary, and because of this, we may also need to convert all
the locales
  repo from hg to git.
 Or we may using a much simpler method. place all the locales files into
the comm source-tree.

8、Building xulrunner distribution for Thunderbird/Gecko like
https://github.com/atom/electron/releases, so we only need to downloading
those binaries.

9、Packaging the mozbuild building system into the xulrunner, so that we
won't need
  the whole mozilla source-tree.
10、 The xulrunner only chasing for stable version of firefox, unless there
is much need of new functional, then the xulrunner only based on ESR
version of firefox.



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Leaving hg.mozilla bug.mozilla to github for the leaving complicated infrastructure of mozilla.

[Wayne]

On 12/4/2015 3:06 AM, 罗勇刚(Yonggang Luo)  wrote:

When I trying submit a patch to thunderbird community, that's always need
to create a
bug in bug.mozilla.org, and that's very hard to use and slow.
The merging progress are very slow. That's why I am hesitate to
contributing things back.


Do you a guess of _why_ they are slow?
How serious is the slowness?
How much faster would it need to be to be acceptable?


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Leaving hg.mozilla bug.mozilla to github for the leaving complicated infrastructure of mozilla.

[luoyonggang]

<<< text/html; charset=utf-8: Unrecognized >>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Leaving hg.mozilla bug.mozilla to github for the leaving complicated infrastructure of mozilla.

[Yonggang Luo]

On Saturday, December 5, 2015 at 12:33:56 AM UTC+8, Nathan Froyd wrote:
> On Fri, Dec 4, 2015 at 8:52 AM, luoyonggang  wrote:
> 
> > Do you a guess of _why_ they are slow?
> > How serious is the slowness?
> > How much faster would it need to be to be acceptable?
> >
> > Under win32, the llinkage time of xul.dll is 5minutes on ssd machine,
> > that's not acceptable.
> >
> 
> How much RAM do you have?  And is this a debug build or an optimized build?
> 
> -Nathan
16GB RAM with i7, debug build is a bit faster, release build is much slower.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Leaving hg.mozilla bug.mozilla to github for the leaving complicated infrastructure of mozilla.

[Nathan Froyd]

On Fri, Dec 4, 2015 at 8:52 AM, luoyonggang  wrote:

> Do you a guess of _why_ they are slow?
> How serious is the slowness?
> How much faster would it need to be to be acceptable?
>
> Under win32, the llinkage time of xul.dll is 5minutes on ssd machine,
> that's not acceptable.
>

How much RAM do you have?  And is this a debug build or an optimized build?

-Nathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform