On 2012-10-11 3:16 PM, Randell Jesup wrote:
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).
I think owners of imported code should be responsible for updating it,
and it is nice of them if they include update scripts (it makes it
easier for them to do future updates, and it decreases the bus factor),
but I don't know how much we can enforce that. Other projects such as
WebRTC which have more complicated workflows can pick whatever works
best for them.
However, keeping the history of the changes over upstream code is
another issue. Really, we should not need to do anything special there
since the history of modifications is already recorded in the revision
control systems, but some people like to store them as patches etc,
probably because of CVS-nostalgia (you didn't use to have the entire
history of the repo on your hard disk!).
What I really don't want us to do is to prohibit people from fixing
things in the imported code. That is the absolute worst situation we
can face with a given piece of code, as we already have learned painfully.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
