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
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.
Some examples, IME support, something that likely you don't have much
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).
When pasting a URL is broken due to a buffer overrun cross-platform but
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).
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.
Dave
> _______________________________________________
> dev-ports-os2 mailing list
>
dev-po...@lists.mozilla.org
>
https://lists.mozilla.org/listinfo/dev-ports-os2