info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Latest Firefox/Thunderbird
237 views
Skip to first unread message
Curtis
Apr 13, 2013, 9:18:31 PM4/13/13
to
Who's working on the latest Firefox/Thunderbird? What's the statue?
Thnx,
Thnx,
Dave Yeo
Apr 13, 2013, 11:05:19 PM4/13/13
to
Curtis wrote:
> Who's working on the latest Firefox/Thunderbird? What's the statue?
>
> Thnx,
https://github.com/bitwiseworks/mozilla-os2
> Who's working on the latest Firefox/Thunderbird? What's the statue?
>
> Thnx,
Dave
Steve Wendt
Apr 14, 2013, 2:51:33 PM4/14/13
to
On 04/13/13 08:05 pm, Dave Yeo wrote:
>> Who's working on the latest Firefox/Thunderbird? What's the statue?
>
> https://github.com/bitwiseworks/mozilla-os2
>> Who's working on the latest Firefox/Thunderbird? What's the statue?
>
No commits, other than a readme - not even an import of existing code.
Looks like it will be at least Gecko 24 before we see anything.
Herwig Bauernfeind
Apr 18, 2013, 1:59:57 AM4/18/13
to
Am 14.04.13 20:51, schrieb Steve Wendt:
The import of the existing code is there now. Some work on the toolchain
had to be done first.
Kind regards
Herwig Bauernfeind
CFO bww bitwiseworks
had to be done first.
Kind regards
Herwig Bauernfeind
CFO bww bitwiseworks
Dave Yeo
Apr 18, 2013, 2:58:06 AM4/18/13
to dev-po...@lists.mozilla.org
On 04/17/13 10:59 pm, Herwig Bauernfeind wrote:
> Am 14.04.13 20:51, schrieb Steve Wendt:
>> On 04/13/13 08:05 pm, Dave Yeo wrote:
>>
>>>> Who's working on the latest Firefox/Thunderbird? What's the statue?
>>>
>>> https://github.com/bitwiseworks/mozilla-os2
>>
>> No commits, other than a readme - not even an import of existing code.
>> Looks like it will be at least Gecko 24 before we see anything.
>
> The import of the existing code is there now. Some work on the toolchain
> had to be done first.
>
Patching for kbuild is going to take time and create a maintenance issue
> Am 14.04.13 20:51, schrieb Steve Wendt:
>> On 04/13/13 08:05 pm, Dave Yeo wrote:
>>
>>>> Who's working on the latest Firefox/Thunderbird? What's the statue?
>>>
>>> https://github.com/bitwiseworks/mozilla-os2
>>
>> No commits, other than a readme - not even an import of existing code.
>> Looks like it will be at least Gecko 24 before we see anything.
>
> The import of the existing code is there now. Some work on the toolchain
> had to be done first.
>
going forward, build system is moving to more Python stuff, comm-central
is being moved to under mozilla-central and creating patches for
upstream will be more difficult. Autoconf system currently works for 17esr.
Dave
Steve Wendt
Apr 21, 2013, 1:44:06 AM4/21/13
to
On 04/17/13 11:58 pm, Dave Yeo wrote:
>>>> https://github.com/bitwiseworks/mozilla-os2
done with Qt or OpenJDK. Which means it will quickly be irrelevant.
>>>> https://github.com/bitwiseworks/mozilla-os2
>
> Patching for kbuild is going to take time and create a maintenance issue
> going forward, build system is moving to more Python stuff, comm-central
> is being moved to under mozilla-central and creating patches for
> upstream will be more difficult. Autoconf system currently works for 17esr.
I fear this will be a one-time port, not committed upstream, like is
> Patching for kbuild is going to take time and create a maintenance issue
> going forward, build system is moving to more Python stuff, comm-central
> is being moved to under mozilla-central and creating patches for
> upstream will be more difficult. Autoconf system currently works for 17esr.
done with Qt or OpenJDK. Which means it will quickly be irrelevant.
dm...@dmik.org
Apr 21, 2013, 8:29:27 PM4/21/13
to
Steve, you are not a software developer, are you? You sound like you have no idea what you're talking about. The fact that our changes don't go upstream doesn't influence the future of the OS/2 port given that we maintain our own repository with all OS/2 patches applied. Technically, there is no difference between keeping the patches upstream and tailoring them as the project develops right there or merging upstream down to our own repository from time to time and tailoring them here.
Keeping the OS/2 code patches upstream in projects like Mozilla would obviously require a dedicated Mozilla team member who would look after them (like it was in the past). Given that there is no such a person and we are short on resources, it's simpler for us to just maintain our own repo.
воскресенье, 21 апреля 2013 г., 9:44:06 UTC+4 пользователь Steve Wendt написал:
Keeping the OS/2 code patches upstream in projects like Mozilla would obviously require a dedicated Mozilla team member who would look after them (like it was in the past). Given that there is no such a person and we are short on resources, it's simpler for us to just maintain our own repo.
воскресенье, 21 апреля 2013 г., 9:44:06 UTC+4 пользователь Steve Wendt написал:
dm...@dmik.org
Apr 21, 2013, 8:45:47 PM4/21/13
to
четверг, 18 апреля 2013 г., 10:58:06 UTC+4 пользователь Dave Yeo написал:
> Patching for kbuild is going to take time and create a maintenance issue
> going forward, build system is moving to more Python stuff, comm-central
> is being moved to under mozilla-central and creating patches for
> upstream will be more difficult. Autoconf system currently works for 17esr.
Dave, keeping things work after moving to kbuild is generally as simple as adding/removing items to the list of files to compile according to "normal" makefile changes. This doesn't happen often and requires little effort, really. On the other hand, we get rid of the Autoconf HELL which a) saves us from the need to run a damn slow configure procedure each time some file added / option changed; b) makes it damn easy to control and fine-tune every aspect the build process as kbuild makefiles are very straightforward and clean; c) no need to spend life on groking super-complex-for-more-fun things like libtool; d) allows to nicely break the build to subparts and build each part individually if we wish so (normally we do).
Remember that autoconf was invented to sort out numerous differences between various *nix platforms. This is absolutely irrelevant for OS/2 where things are constant. Autoconf is an overdoze here.
> Patching for kbuild is going to take time and create a maintenance issue
> going forward, build system is moving to more Python stuff, comm-central
> is being moved to under mozilla-central and creating patches for
> upstream will be more difficult. Autoconf system currently works for 17esr.
Remember that autoconf was invented to sort out numerous differences between various *nix platforms. This is absolutely irrelevant for OS/2 where things are constant. Autoconf is an overdoze here.
Dave Yeo
Apr 22, 2013, 12:40:20 AM4/22/13
to
dm...@dmik.org wrote:
> четверг, 18 апреля 2013 г., 10:58:06 UTC+4 пользователь Dave Yeo написал:
>
>> Patching for kbuild is going to take time and create a maintenance issue
>> going forward, build system is moving to more Python stuff, comm-central
>> is being moved to under mozilla-central and creating patches for
>> upstream will be more difficult. Autoconf system currently works for 17esr.
>
> Dave, keeping things work after moving to kbuild is generally as simple as adding/removing items to the list of files to compile according to "normal" makefile changes. This doesn't happen often and requires little effort, really. On the other hand, we get rid of the Autoconf HELL which a) saves us from the need to run a damn slow configure procedure each time some file added / option changed; b) makes it damn easy to control and fine-tune every aspect the build process as kbuild makefiles are very straightforward and clean; c) no need to spend life on groking super-complex-for-more-fun things like libtool; d) allows to nicely break the build to subparts and build each part individually if we wish so (normally we do).
I admit I have no experience with kbuild besides failing every time I've
> четверг, 18 апреля 2013 г., 10:58:06 UTC+4 пользователь Dave Yeo написал:
>
>> Patching for kbuild is going to take time and create a maintenance issue
>> going forward, build system is moving to more Python stuff, comm-central
>> is being moved to under mozilla-central and creating patches for
>> upstream will be more difficult. Autoconf system currently works for 17esr.
>
> Dave, keeping things work after moving to kbuild is generally as simple as adding/removing items to the list of files to compile according to "normal" makefile changes. This doesn't happen often and requires little effort, really. On the other hand, we get rid of the Autoconf HELL which a) saves us from the need to run a damn slow configure procedure each time some file added / option changed; b) makes it damn easy to control and fine-tune every aspect the build process as kbuild makefiles are very straightforward and clean; c) no need to spend life on groking super-complex-for-more-fun things like libtool; d) allows to nicely break the build to subparts and build each part individually if we wish so (normally we do).
tried to build something with it which hasn't been often and is related
to the lack of a good tutorial.
Autoconf doesn't have to be run that often, if adding a file, edit both
makefile.in and $OBJ/makefile and run make to build the subpart though
due to all the idl files and such the parent make will have to be run at
least once. We have also inherited a lot of fixes as by products of
Mozilla fixing issues on other platforms. Emxomfld was starting to fail
due to limited page size and the fake libs worked as a work around as
one example. Libtool is only used by ctypes and just works for static
aout libraries.
Anyways it will be interesting to see how the kbuild system works.
>
> Remember that autoconf was invented to sort out numerous differences between various *nix platforms. This is absolutely irrelevant for OS/2 where things are constant. Autoconf is an overdoze here.
dm...@dmik.org
Apr 22, 2013, 5:28:28 AM4/22/13
to
понедельник, 22 апреля 2013 г., 8:40:20 UTC+4 пользователь Dave Yeo написал:
> I admit I have no experience with kbuild besides failing every time I've
> tried to build something with it which hasn't been often and is related
> to the lack of a good tutorial.
There is a small tutorial in /doc AFAIR.
> Autoconf doesn't have to be run that often, if adding a file, edit both
> makefile.in and $OBJ/makefile and run make to build the subpart though
> due to all the idl files and such the parent make will have to be run at
> least once. We have also inherited a lot of fixes as by products of
> Mozilla fixing issues on other platforms. Emxomfld was starting to fail
> due to limited page size and the fake libs worked as a work around as
> one example. Libtool is only used by ctypes and just works for static
Well for sure you can teach yourself various hacks to work around things in autoconf. But it takes too much time and every project is different and you forget these hacks after a while if you work on a number of different projects at the same time. With kbuild, there is no such a problem - once you have performed the initial project setup, things are really easy. This is why we want to switch.
> I admit I have no experience with kbuild besides failing every time I've
> tried to build something with it which hasn't been often and is related
> to the lack of a good tutorial.
> Autoconf doesn't have to be run that often, if adding a file, edit both
> makefile.in and $OBJ/makefile and run make to build the subpart though
> due to all the idl files and such the parent make will have to be run at
> least once. We have also inherited a lot of fixes as by products of
> Mozilla fixing issues on other platforms. Emxomfld was starting to fail
> due to limited page size and the fake libs worked as a work around as
> one example. Libtool is only used by ctypes and just works for static
Steve Wendt
Apr 22, 2013, 2:25:22 PM4/22/13
to
Happy to see you contributing in this newsgroup, at last.
On 4/21/2013 5:29 PM, dm...@dmik.org wrote:
> The fact that our changes don't go upstream doesn't influence the
> future of the OS/2 port
I disagree; you do realize that you are not allowed to call it "Firefox"
in this case?
> we maintain our own repository with all OS/2 patches applied.
Which is great for the 17.0.x ESR line, but what about when that one
becomes obsolete? Gecko 24esr is not too far away. You plan to port
each version separately, I take it?
> Technically, there is no difference between keeping the patches
> upstream and tailoring them as the project develops right there or
> merging upstream down to our own repository from time to time and
> tailoring them here.
Yes, this is true to some extent. However, patches in mainline gain the
benefit of eyeballs from the entire Mozilla community, which often
yields a better result. Similarly, there have been bugs which were more
obvious on OS/2, which actually needed to be fixed on all platforms.
> Keeping the OS/2 code patches upstream in projects like Mozilla would
> obviously require a dedicated Mozilla team member who would look
> after them (like it was in the past). Given that there is no such a
> person and we are short on resources, it's simpler for us to just
> maintain our own repo.
Which you are certainly free to do, and it's well within the license
(other than the naming). I was happy to contribute funding to the Qt4
and Java porting efforts, but in my opinion a similar approach is wrong
for a project that has had a long history of OS/2 support in the main
codebase. This is just an invitation for OS/2 support to be ripped out
of mainline, which makes things harder in the long run.
On 4/21/2013 5:29 PM, dm...@dmik.org wrote:
> The fact that our changes don't go upstream doesn't influence the
> future of the OS/2 port
in this case?
> we maintain our own repository with all OS/2 patches applied.
becomes obsolete? Gecko 24esr is not too far away. You plan to port
each version separately, I take it?
> Technically, there is no difference between keeping the patches
> upstream and tailoring them as the project develops right there or
> merging upstream down to our own repository from time to time and
> tailoring them here.
benefit of eyeballs from the entire Mozilla community, which often
yields a better result. Similarly, there have been bugs which were more
obvious on OS/2, which actually needed to be fixed on all platforms.
> Keeping the OS/2 code patches upstream in projects like Mozilla would
> obviously require a dedicated Mozilla team member who would look
> after them (like it was in the past). Given that there is no such a
> person and we are short on resources, it's simpler for us to just
> maintain our own repo.
(other than the naming). I was happy to contribute funding to the Qt4
and Java porting efforts, but in my opinion a similar approach is wrong
for a project that has had a long history of OS/2 support in the main
codebase. This is just an invitation for OS/2 support to be ripped out
of mainline, which makes things harder in the long run.
dm...@dmik.org
Apr 22, 2013, 7:55:58 PM4/22/13
to
понедельник, 22 апреля 2013 г., 22:25:22 UTC+4 пользователь Steve Wendt написал:
> Happy to see you contributing in this newsgroup, at last.
Ok, but frankly, I prefer coding than flaming here. The matter you raised is a common (= important) question though so it makes sense to clarify our position on this.
> I disagree; you do realize that you are not allowed to call it "Firefox"
> in this case?
I do but I don't think anybody from Mozilla really cares about this OS/2 at all (for many reasons). If they ever do, we'll rename it.
> Which is great for the 17.0.x ESR line, but what about when that one
> becomes obsolete? Gecko 24esr is not too far away. You plan to port
> each version separately, I take it?
No, we never port each version separately. We always reuse our previous work as much as possible — just like the original developers do. This is true for Qt and will be true for Firefox. There will be a single repository for it, for all development lines. The first thing I've been doing now is applying 10x (and earlier) patches to the 17x branch. It's not a new port; I just check which patches are still relevant (and can be reused 100%) and which need fixing etc. I also disover new places that need to be ported. The OS/2 code maintainer would basically have to do exactly the same if the patches were upstream (just the workflow would be a bit different — it *could* be faster in this case but remember: the price for this is a dedicated Mozilla dev which we can't afford).
> Yes, this is true to some extent. However, patches in mainline gain the
> benefit of eyeballs from the entire Mozilla community, which often
> yields a better result.
Not in this case — the eyeballs you are talking about are not familiar with OS/2 so they have little to no use for us. The OS/2 devs interested in this can just follow our repo to obtain the same effect.
> Similarly, there have been bugs which were more
> obvious on OS/2, which actually needed to be fixed on all platforms.
We don't care about the latter a lot (again — no resources for that ATM).
> Which you are certainly free to do, and it's well within the license
> (other than the naming). I was happy to contribute funding to the Qt4
> and Java porting efforts, but in my opinion a similar approach is wrong
> for a project that has had a long history of OS/2 support in the main
> codebase. This is just an invitation for OS/2 support to be ripped out
> of mainline, which makes things harder in the long run.
OS/2 support which is still there (is it still there in 17esr? I'm not yet sure) is not supported by Mozilla itself and hence will be cut out sooner or later and we can't do anything about that (other than pay a lot of money to somebody to become a Mozilla team member etc — and I'm still not sure they will be interested in that as it would influence their dev cycles anyway).
> Happy to see you contributing in this newsgroup, at last.
> I disagree; you do realize that you are not allowed to call it "Firefox"
> in this case?
> Which is great for the 17.0.x ESR line, but what about when that one
> becomes obsolete? Gecko 24esr is not too far away. You plan to port
> each version separately, I take it?
> Yes, this is true to some extent. However, patches in mainline gain the
> benefit of eyeballs from the entire Mozilla community, which often
> yields a better result.
> Similarly, there have been bugs which were more
> obvious on OS/2, which actually needed to be fixed on all platforms.
> Which you are certainly free to do, and it's well within the license
> (other than the naming). I was happy to contribute funding to the Qt4
> and Java porting efforts, but in my opinion a similar approach is wrong
> for a project that has had a long history of OS/2 support in the main
> codebase. This is just an invitation for OS/2 support to be ripped out
> of mainline, which makes things harder in the long run.
Dave Yeo
Apr 23, 2013, 2:27:53 AM4/23/13
to dev-po...@lists.mozilla.org
On 04/22/13 04:55 pm, dm...@dmik.org wrote:
> понедельник, 22 апреля 2013 г., 22:25:22 UTC+4 пользователь Steve Wendt написал:
>
>> Happy to see you contributing in this newsgroup, at last.
>
> Ok, but frankly, I prefer coding than flaming here. The matter you raised is a common (= important) question though so it makes sense to clarify our position on this.
Not trying to create a flamewar or any such thing so I'll make a few
> понедельник, 22 апреля 2013 г., 22:25:22 UTC+4 пользователь Steve Wendt написал:
>
>> Happy to see you contributing in this newsgroup, at last.
>
> Ok, but frankly, I prefer coding than flaming here. The matter you raised is a common (= important) question though so it makes sense to clarify our position on this.
comments then leave you to do it how you like.
First I agree with Steve that it is best to get changes in upstream.
This causes much less maintenance, things like mass changes, eg the
header changes, the move away from NS specific types to system types and
such happen automatically instead of time being spent rebasing projects.
>
>> I disagree; you do realize that you are not allowed to call it "Firefox"
>> in this case?
>
> I do but I don't think anybody from Mozilla really cares about this OS/2 at all (for many reasons). If they ever do, we'll rename it.
>
>> Which is great for the 17.0.x ESR line, but what about when that one
>> becomes obsolete? Gecko 24esr is not too far away. You plan to port
>> each version separately, I take it?
>
> No, we never port each version separately. We always reuse our previous work as much as possible — just like the original developers do. This is true for Qt and will be true for Firefox. There will be a single repository for it, for all development lines. The first thing I've been doing now is applying 10x (and earlier) patches to the 17x branch. It's not a new port; I just check which patches are still relevant (and can be reused 100%) and which need fixing etc. I also disover new places that need to be ported. The OS/2 code maintainer would basically have to do exactly the same if the patches were upstream (just the workflow would be a bit different — it *could* be faster in this case but remember: the price for this is a dedicated Mozilla dev which we can't afford).
>
>> Yes, this is true to some extent. However, patches in mainline gain the
>> benefit of eyeballs from the entire Mozilla community, which often
>> yields a better result.
>
> Not in this case — the eyeballs you are talking about are not familiar with OS/2 so they have little to no use for us. The OS/2 devs interested in this can just follow our repo to obtain the same effect.
experience with and even KOMH ran into problems, especially with
Japanese support, https://bugzilla.mozilla.org/show_bug.cgi?id=768742
Heads up on changes, eg
https://bugzilla.mozilla.org/show_bug.cgi?id=701760. Note that Mike
Kapley is slightly involved in that bug and quite involved in the ESR
releases. Mike wrote much of the OS/2 code as well as porting NS4.62 and
is still the official OS/2 widget maintainer and is happy to help.
There is also a much better bug reporting setup then github where I
can't even see any way to post patches, guess the git way is to maintain
branches and get them merged.
>
>> Similarly, there have been bugs which were more
>> obvious on OS/2, which actually needed to be fixed on all platforms.
>
> We don't care about the latter a lot (again — no resources for that ATM).
only obvious on OS/2, why not share?
>
>> Which you are certainly free to do, and it's well within the license
>> (other than the naming). I was happy to contribute funding to the Qt4
>> and Java porting efforts, but in my opinion a similar approach is wrong
>> for a project that has had a long history of OS/2 support in the main
>> codebase. This is just an invitation for OS/2 support to be ripped out
>> of mainline, which makes things harder in the long run.
>
> OS/2 support which is still there (is it still there in 17esr? I'm not yet sure) is not supported by Mozilla itself and hence will be cut out sooner or later and we can't do anything about that (other than pay a lot of money to somebody to become a Mozilla team member etc — and I'm still not sure they will be interested in that as it would influence their dev cycles anyway).
support, I'll probably answer but not sure how to answer, do I say that
we've forked? Do I post your fixes, with attribution of course?
And even the forks such as tenfour (Mac PPC fork) gets lots of help from
the knowledgeable people involved in Mozilla.
There are other projects where being merged into upstream helps us a
lot. Libav/FFmpeg where for example they are supporting NASM due to OS/2
not having a useful YASM port. A few patches a year and giving as much
feedback as possible by regularly running the test script and sending
the results upstream helps us have multimedia support in MPlayer, VLC,
etc. http://fate.libav.org has the results from my machine.
Dave
> _______________________________________________
> dev-ports-os2 mailing list
> dev-po...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-ports-os2
dm...@dmik.org
Apr 23, 2013, 6:34:57 AM4/23/13
to
вторник, 23 апреля 2013 г., 10:27:53 UTC+4 пользователь Dave Yeo написал:
> First I agree with Steve that it is best to get changes in upstream.
Nobody said the opposite. Only that everything has its price.
> This causes much less maintenance, things like mass changes, eg the
> header changes, the move away from NS specific types to system types and
> such happen automatically instead of time being spent rebasing projects.
For such cases a simple merge works great. We only have to deal with the code we create or change. But these bits are tiny compared to the overall project size and somebody would have to deal with them on the Mozilla side anyway — at least it would look for us as "much less" only in this case.
> https://bugzilla.mozilla.org/show_bug.cgi?id=701760. Note that Mike
> Kapley is slightly involved in that bug and quite involved in the ESR
> releases. Mike wrote much of the OS/2 code as well as porting NS4.62 and
> is still the official OS/2 widget maintainer and is happy to help.
That's good. But still, he can just contribute to our repo. This will be way faster btw.
> There is also a much better bug reporting setup then github where I
> can't even see any way to post patches, guess the git way is to maintain
> branches and get them merged.
There are pull requests. Once you learn it you will realize that it's much more powerful than dumb .patch attachments used everywhere else.
> When pasting a URL is broken due to a buffer overrun cross-platform but
> only obvious on OS/2, why not share?
I didn't say "not share". I said this isn't our top priority ATM. E.g. if you want to take this small task over and deal with pushing our patches upstream (OS/2-specific or generic or both) — we would be really happy!
> It's still there in trunk and someone has just asked Walter about IPC
> support, I'll probably answer but not sure how to answer, do I say that
> we've forked? Do I post your fixes, with attribution of course?
Yes, I think this is the most optimal way to go right now.
> And even the forks such as tenfour (Mac PPC fork) gets lots of help from
> the knowledgeable people involved in Mozilla.
I guess the amount of people having the need of PPC is bigger than the ones having the need of OS/2...
> There are other projects where being merged into upstream helps us a
> lot. Libav/FFmpeg where for example they are supporting NASM due to OS/2
> not having a useful YASM port. A few patches a year and giving as much
> feedback as possible by regularly running the test script and sending
> the results upstream helps us have multimedia support in MPlayer, VLC,
> etc. http://fate.libav.org has the results from my machine.
You do understand the difference between Libav/Ffmpeg and Qt/Mozilla, do you? -) Silvan normally pushes his OS/2 patches to Qt Apps to the authors too and they are generally accepted. The problem with Mozilla and Qt is that they are TOO big and it takes a lot of time to maintain the platform (make sure our patches don't break other builds, make sure the opposite, and so on).
Again, everybody will be happy if what we do ends up landed upstream. So if you wish to help we will help you to help in turn.
> First I agree with Steve that it is best to get changes in upstream.
> This causes much less maintenance, things like mass changes, eg the
> header changes, the move away from NS specific types to system types and
> such happen automatically instead of time being spent rebasing projects.
> https://bugzilla.mozilla.org/show_bug.cgi?id=701760. Note that Mike
> Kapley is slightly involved in that bug and quite involved in the ESR
> releases. Mike wrote much of the OS/2 code as well as porting NS4.62 and
> is still the official OS/2 widget maintainer and is happy to help.
> There is also a much better bug reporting setup then github where I
> can't even see any way to post patches, guess the git way is to maintain
> branches and get them merged.
> When pasting a URL is broken due to a buffer overrun cross-platform but
> only obvious on OS/2, why not share?
> It's still there in trunk and someone has just asked Walter about IPC
> support, I'll probably answer but not sure how to answer, do I say that
> we've forked? Do I post your fixes, with attribution of course?
> And even the forks such as tenfour (Mac PPC fork) gets lots of help from
> the knowledgeable people involved in Mozilla.
> There are other projects where being merged into upstream helps us a
> lot. Libav/FFmpeg where for example they are supporting NASM due to OS/2
> not having a useful YASM port. A few patches a year and giving as much
> feedback as possible by regularly running the test script and sending
> the results upstream helps us have multimedia support in MPlayer, VLC,
> etc. http://fate.libav.org has the results from my machine.
Again, everybody will be happy if what we do ends up landed upstream. So if you wish to help we will help you to help in turn.
Steve Wendt
Apr 23, 2013, 1:37:05 PM4/23/13
to
On 4/23/2013 3:34 AM, dm...@dmik.org wrote:
>> Mike wrote much of the OS/2 code as well as porting NS4.62 and
>> is still the official OS/2 widget maintainer and is happy to help.
>
> That's good. But still, he can just contribute to our repo.
I expect the majority of Mozilla contributors will have zero interest in
>> Mike wrote much of the OS/2 code as well as porting NS4.62 and
>> is still the official OS/2 widget maintainer and is happy to help.
>
> That's good. But still, he can just contribute to our repo.
contributing to a third party repo. To start with, you haven't stated
whether you are going to maintain usage of the MPL for all of the code
contributed to it.
> E.g. if you want to take this small task over and deal with pushing
> our patches upstream (OS/2-specific or generic or both) — we would be
> really happy!
contribute funding. It's often not a "small task" as it can require
doing rewrites to accommodate reviews, but generally this results in
better code.
> I guess the amount of people having the need of PPC is bigger than
> the ones having the need of OS/2...
Weilbacher has shown, one highly motivated person can do a lot, at least
until "real life" intervenes.
Dave Yeo
Apr 24, 2013, 12:30:05 AM4/24/13
to dev-po...@lists.mozilla.org
On 04/23/13 03:34 am, dm...@dmik.org wrote:
>> There is also a much better bug reporting setup then github where I
>> > can't even see any way to post patches, guess the git way is to maintain
>> > branches and get them merged.
> There are pull requests. Once you learn it you will realize that it's much more powerful than dumb .patch attachments used everywhere else.
>
Sounds bandwidth intensive, your repositry must be over half a gigabyte
>> There is also a much better bug reporting setup then github where I
>> > can't even see any way to post patches, guess the git way is to maintain
>> > branches and get them merged.
> There are pull requests. Once you learn it you will realize that it's much more powerful than dumb .patch attachments used everywhere else.
>
so I'd need a local copy then there's the question of how code review
works and in the case of a simple fix it seems easier to suggest a
simple patch, eg
diff --git a/xpcom/io/nsLocalFileOS2.cpp b/xpcom/io/nsLocalFileOS2.cpp
--- a/xpcom/io/nsLocalFileOS2.cpp
+++ b/xpcom/io/nsLocalFileOS2.cpp
@@ -17,16 +17,18 @@
#include "nsIComponentManager.h"
#include "prtypes.h"
#include "prio.h"
#include "nsReadableUtils.h"
#include "nsISupportsPrimitives.h"
#include "nsIMutableArray.h"
#include "nsTraceRefcntImpl.h"
+#include "nsHashKeys.h"
using namespace mozilla;
#define CHECK_mWorkingPath()
...
Or the patch I have restoring the generic timestamp implementation,
easier then implementing clock monotonic especially since it doesn't
need to be that accurate with our file systems only having 2 second
accuracy and we're not reporting statistics to Mozilla.
I'm willing to learn but for many things patches seem to work fine and I
note that most projects using git are happy with a patch created with
git format-patch.
Dave
dm...@dmik.org
Apr 24, 2013, 3:44:49 AM4/24/13
to
вторник, 23 апреля 2013 г., 21:37:05 UTC+4 пользователь Steve Wendt написал:
> I expect the majority of Mozilla contributors will have zero interest in
> contributing to a third party repo. To start with, you haven't stated
> whether you are going to maintain usage of the MPL for all of the code
> contributed to it.
I talk about Mike Kaply only.
> If this part were certain, I personally would be far more likely to
> contribute funding. It's often not a "small task" as it can require
> doing rewrites to accommodate reviews, but generally this results in
> better code.
You seem to still miss the point. We have no resources for that. If you wish and really believe it's so important, you can sponsor e.g. Dave for doing this. And I must state once again — we want our work to go upstream but it's a low priority task for us as that requires a lot of effort and doesn't give a lot in return.
You may not know, but I was trying to push my numerous IPC patches I did for VirtualBox back to Mozilla. I failed because the person responsible for this component wasn't interested too much. The only way to develop Mozilla ATM is have our own repo, nothing to discuss here. When we have 17esr working, we may consider taking our patches and sending them to the Mozilla team. We will see.
> I expect the majority of Mozilla contributors will have zero interest in
> contributing to a third party repo. To start with, you haven't stated
> whether you are going to maintain usage of the MPL for all of the code
> contributed to it.
> If this part were certain, I personally would be far more likely to
> contribute funding. It's often not a "small task" as it can require
> doing rewrites to accommodate reviews, but generally this results in
> better code.
You may not know, but I was trying to push my numerous IPC patches I did for VirtualBox back to Mozilla. I failed because the person responsible for this component wasn't interested too much. The only way to develop Mozilla ATM is have our own repo, nothing to discuss here. When we have 17esr working, we may consider taking our patches and sending them to the Mozilla team. We will see.
dm...@dmik.org
Apr 24, 2013, 9:53:10 AM4/24/13
to
среда, 24 апреля 2013 г., 8:30:05 UTC+4 пользователь Dave Yeo написал:
> Sounds bandwidth intensive, your repositry must be over half a gigabyte
> so I'd need a local copy then there's the question of how code review
> works and in the case of a simple fix it seems easier to suggest a
> simple patch, eg
I don't quite follow you here. You need to get the Mozilla source anyway (which is 200M excluding comm). If ou get a git repo instead of a bare source tarball (which is 0.5G indeed with the history stripped out), you have everything for your local offline work (including the ability to create and maintan any number of your local branches with patches) — and git is really good at that. This is basically what it was made for.
If you want to use pull requests, you will have to fork mozilla-os2 and commit to your fork which I will then be able to use to pull your changes into the main repo. This doesn't require a lot of bandwidth, really.
> I'm willing to learn but for many things patches seem to work fine and I
> note that most projects using git are happy with a patch created with
> git format-patch.
Or if you prefer you can use git format-patch and put patches right to ticket's comments. If you put it between ```diff and ``` lines you will even get syntax highlighting.
> Sounds bandwidth intensive, your repositry must be over half a gigabyte
> so I'd need a local copy then there's the question of how code review
> works and in the case of a simple fix it seems easier to suggest a
> simple patch, eg
If you want to use pull requests, you will have to fork mozilla-os2 and commit to your fork which I will then be able to use to pull your changes into the main repo. This doesn't require a lot of bandwidth, really.
> I'm willing to learn but for many things patches seem to work fine and I
> note that most projects using git are happy with a patch created with
> git format-patch.
Steve Wendt
Apr 24, 2013, 2:06:49 PM4/24/13
to
On 4/24/2013 12:44 AM, dm...@dmik.org wrote:
> You may not know, but I was trying to push my numerous IPC patches I
> did for VirtualBox back to Mozilla.
Excellent.
> You may not know, but I was trying to push my numerous IPC patches I
> did for VirtualBox back to Mozilla.
> I failed because the person responsible for this component wasn't
> interested too much.
Some of them are very receptive, and others are not. It's unfortunate,
but worth at least attempting.
> When we have 17esr working, we may consider taking our patches
> and sending them to the Mozilla team. We will see.
is really old already.
Steve Wendt
Apr 24, 2013, 10:06:38 PM4/24/13
to
On 4/24/2013 11:06 AM, Steve Wendt wrote:
>> When we have 17esr working, we may consider taking our patches
>> and sending them to the Mozilla team. We will see.
>
> I suspect they will tell you to re-base against trunk first. Gecko 17
> is really old already.
I suppose I should clarify here; I absolutely agree that starting with
>> When we have 17esr working, we may consider taking our patches
>> and sending them to the Mozilla team. We will see.
>
> I suspect they will tell you to re-base against trunk first. Gecko 17
> is really old already.
Gecko 17esr is the right choice for this fork. However, I hope that
work can also commence ASAP on Gecko 24, which will be in trunk in only
3 weeks time. You will never get patches approved for 17esr, and it is
very difficult to get anything landed for anything other than trunk.
In other words - patches for upstream will be rejected if they don't
apply to trunk.
Dave Yeo
Apr 25, 2013, 1:37:49 AM4/25/13
to
dm...@dmik.org wrote:
> You may not know, but I was trying to push my numerous IPC patches I did for VirtualBox back to Mozilla. I failed because the person responsible for this component wasn't interested too much. The only way to develop Mozilla ATM is have our own repo, nothing to discuss here. When we have 17esr working, we may consider taking our patches and sending them to the Mozilla team. We will see.
They'll only consider patches against trunk and whether your IPC patches
> You may not know, but I was trying to push my numerous IPC patches I did for VirtualBox back to Mozilla. I failed because the person responsible for this component wasn't interested too much. The only way to develop Mozilla ATM is have our own repo, nothing to discuss here. When we have 17esr working, we may consider taking our patches and sending them to the Mozilla team. We will see.
for VB are useful I don't know besides obviously giving you experience.
For Mozilla IPC support I think it'll mean basically porting Chrome or
at least the IPC part and probably updating the wide char support in
libc, I know when I looked at it the first problem was that we're
missing vswprintf() and after watching some developers put together an
implementation of vsprintf() in a secure manner I realized it was beyond
my capacities.
Dave
Dave Yeo
Apr 25, 2013, 1:40:58 AM4/25/13
to
fixes backported to ESR and generally only bug fixes backported to the
alpha and beta branches.
Dave
Dave Yeo
Apr 25, 2013, 1:46:08 AM4/25/13
to
dm...@dmik.org wrote:
> среда, 24 апреля 2013 г., 8:30:05 UTC+4 пользователь Dave Yeo написал:
>
>> > Sounds bandwidth intensive, your repositry must be over half a gigabyte
>> > so I'd need a local copy then there's the question of how code review
>> > works and in the case of a simple fix it seems easier to suggest a
>> > simple patch, eg
> I don't quite follow you here. You need to get the Mozilla source anyway (which is 200M excluding comm). If ou get a git repo instead of a bare source tarball (which is 0.5G indeed with the history stripped out), you have everything for your local offline work (including the ability to create and maintan any number of your local branches with patches) — and git is really good at that. This is basically what it was made for.
I have the Gecko 17 source already and have had it since it branched
> среда, 24 апреля 2013 г., 8:30:05 UTC+4 пользователь Dave Yeo написал:
>
>> > Sounds bandwidth intensive, your repositry must be over half a gigabyte
>> > so I'd need a local copy then there's the question of how code review
>> > works and in the case of a simple fix it seems easier to suggest a
>> > simple patch, eg
> I don't quite follow you here. You need to get the Mozilla source anyway (which is 200M excluding comm). If ou get a git repo instead of a bare source tarball (which is 0.5G indeed with the history stripped out), you have everything for your local offline work (including the ability to create and maintan any number of your local branches with patches) — and git is really good at that. This is basically what it was made for.
from trunk. There aren't many commits after branching and even less to
the ESR branch. Generally with 10ESR patches applied fairly cleanly to
all the point releases so you shouldn't have any problems rebasing on
future 17ESR point releases.
>
> If you want to use pull requests, you will have to fork mozilla-os2 and commit to your fork which I will then be able to use to pull your changes into the main repo. This doesn't require a lot of bandwidth, really.
repository, otherwise mirror it in mercurial.
>
>> > I'm willing to learn but for many things patches seem to work fine and I
>> > note that most projects using git are happy with a patch created with
>> > git format-patch.
> Or if you prefer you can use git format-patch and put patches right to ticket's comments. If you put it between ```diff and ``` lines you will even get syntax highlighting.
Dave
dm...@dmik.org
Apr 25, 2013, 4:04:21 AM4/25/13
to
Steve, Dave, sure — applying our patches to trunk is obvious if we want them upstream. I see no big problems here.
Is Gecko 24 so different from 17 that they are not very much compatible source wise? That would surprise me (no time to look now). Anyway, we did that Qt3 to Qt4 transition where Qt4 was basically a completely different product and we still reused many parts of our previous port which saved us a lot of time.
четверг, 25 апреля 2013 г., 9:40:58 UTC+4 пользователь Dave Yeo написал:
Is Gecko 24 so different from 17 that they are not very much compatible source wise? That would surprise me (no time to look now). Anyway, we did that Qt3 to Qt4 transition where Qt4 was basically a completely different product and we still reused many parts of our previous port which saved us a lot of time.
четверг, 25 апреля 2013 г., 9:40:58 UTC+4 пользователь Dave Yeo написал:
Steve Wendt
Apr 25, 2013, 1:11:54 PM4/25/13
to
On 4/25/2013 1:04 AM, dm...@dmik.org wrote:
> Is Gecko 24 so different from 17 that they are not very much
> compatible source wise?
Probably not very different for what you would want to patch, I just
> Is Gecko 24 so different from 17 that they are not very much
> compatible source wise?
wanted to make the point that patches have to apply cleanly against
trunk to have any chance.
Dave Yeo
Apr 26, 2013, 1:06:48 AM4/26/13
to dev-po...@lists.mozilla.org
On 04/25/13 01:04 am, dm...@dmik.org wrote:
> Steve, Dave, sure � applying our patches to trunk is obvious if we want them upstream. I see no big problems here.
At some point you should get a Mozilla bugzilla account then I can CC
you on any bugs. Also make attribution easier and complicated patches
you may need to comment on. Good review is always good as well.
Dave
> Steve, Dave, sure � applying our patches to trunk is obvious if we want them upstream. I see no big problems here.
At some point you should get a Mozilla bugzilla account then I can CC
you on any bugs. Also make attribution easier and complicated patches
you may need to comment on. Good review is always good as well.
Dave
0 new messages