I was afraid this would turn out to be difficult. Is there any way we might be able to diff what parts of the code get compiled in the different builds and auto generate a list? #defines might make this list rather long, but we may be able to go through the list once and identify "known" differences and document them, then any changes in this list will show up when we do another diff and we only need to update the documentation for the changes... ideally we could track the changes back to the CL that caused them and ask the author what s/he changed?
Berend-Jan Wever ([email protected]) | Security Software Engineer Google Netherlands B.V. | Reg: Claude Debussylaan 34, 15th floor 1082 MD Amsterdam 34198589 | NETHERLANDS | VAT / Tax ID:- 812788515 B01 On Mon, Jun 15, 2009 at 20:16, Adam Langley <[email protected]> wrote: > On Mon, Jun 15, 2009 at 6:16 AM, Berend-Jan Wever<[email protected]> > wrote: > > Before we start creating a list, we should think of a procedure that will > > make sure it is kept up-to-date. It makes no sense if we create the list > now > > only to find that a year from now, when we need it, it's outdated. > > The two most important questions to me at this point are: > > - Were should we keep this information? > > - How do we keep this information up-to-date when code changes? > > That's very tough to do. The "shared document" approach generally > falls apart pretty quickly. One could imagine using a "SECURITY=" line > in commit messages like the "TEST=" line. But someone would need to > run `git log` every so often and check them out. > > I'm not sure that there is a good solution to this. > > > AGL > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
