In Bug 794510, ehsan said in response to me:
>> Isaac makes a good point; we should clearly mark imported code, both for our
>> own purposes and for scripts. Biesi and I were commiserating about the lack
>> of
>> a standard for this ("third_party/blah" such as netwerk/third_party/sctp
>> instead of netwerk/sctp/src might be one way to do it, or put them ALL in a
>> top-level third-party directory, or add a file in the root of a third-party
>> directory (IMPORTED, with info on where/how/etc), ...)
>
>Well, marking imported code is definitely helpful, but really we should
>have a clear process on how to modify the imported code. It is entirely
>unreasonable to render ourselves unable to modify our imported code
>(just look at the current situation with NSPR which causes developers to
>go through huge pain in order to work around things which would be very
>simply dealt with if only we had the option of fixing NSPR...). We
>currently do a very good job in some of the projects (see angle for
>example: http://mxr.mozilla.org/mozilla-central/source/gfx/angle/) and
>in some other cases we do an extremely poor job (case in point:
>nsprpub/!). Really, whoever maintains a given imported code should come
>up with a clear process on how to take patches to that code and either
>try to upstream it if it makes sense or maintain a local patch to assist
>updates to the imported code in the future.
Right. I've tried to create automatic import scripts for all the
libraries I've imported as part of webrtc; some more complex
(webrtc/trunk, where we expect to be upstreaming a lot of stuff and
editing out a lot from the import) and others that basically import
updates from the source repo and require reapplying local updates (which
I maintained as independent patches when we need them); this is mostly
for libraries that we don't expect/want to modify, and if there are
changes needed we ask for updates upstream (netwerk/sctp/src for
example, and netwerk/srtp/src; see netwerk/srtp/update_srtp.sh).
Standardizing how patches are applied on top of imports would be good,
and also how to handle patches slated for upstreaming (that will
hopefully be backed out when upstream updates).
A tarball of patches in the directory is one way I believe is used
(though very un-source-control-management style). Most do updates
entirely by hand, which makes updates extrodinarily painful and
infrequent (or never).
We could also keep a list of bugs to apply patches from (somewhat
better), but still a very manual process.
I built a more complex process for media/webrtc/trunk, which I've had to
only partly use on alder and not m-c, because of the size of the
resultant imported changeset history. I plan to revise this process to
resolve that issue, but the fundamental way it works (in
media/webrtc/webrtc_update.sh) is to:
1) import a complete update (using hg addremove --similarity XX to catch
renames)
2) merge it to another head which has pending upstream patches
3) merge *that* to another head which has deletions not intended for
upstream to winnow it down to what we want in our tree. In webrtc,
this involves removing large number of third-party modules, remove
40MB video YUV test files, etc.
4) take that, and merge it to a mozilla repo (alder) which merges any local
(non-upstream) mods to our tree with the imported update.
I've used this to produce what I want on alder, and have released stuff
to m-c by copying the code over and running hg addremove, instead of
using hg pull from alder to m-c, because the imported patch history
would enormously expand the repo size. For smaller projects this would
not be an issue. This may also be overkill for smaller projects, however.
This itself may be overly complex, especially in the separation of
patches-for-upstream from our normal dev tree. When I designed it, I
didn't know how many upstream patches I'd be producing.
--
Randell Jesup, Mozilla Corp
remove ".news" for personal email
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
