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