On Wed, Sep 28, 2011 at 9:23 AM, Mathias Bauer <mathias_ba...@gmx.net>wrote:
> What might be the best way to handle 3rd party code in AOOo probably will > depend on the needs of the developers as well as on legal requirements. > > We had these tarballs plus patches IIRC because Sun Legal required that all > used 3rd party stuff should be preserved in our repos in its original form. > > As a developer I always had preferred to have 3rd party code treated in the > *build* like the internal source code. > > So if there wasn't a requirement to have unpatched sources in the > repository, the most natural way to keep 3rd party stuff would be to have a > third sub-repo "3rdparty" next to "main" and "extras" with the 3rd party > stuff checked in. Not the tarballs, just the unpacked content. > > I wouldn't give up the patches, as they allow to handle updates better. > This would cause a problem, as direct changes to the 3rd party stuff without > additional authorization (means: changing the source code must not happen > accidently, only when the 3rd party code gets an update from upstream) must > be prevented, while still patch files must be allowed to added, removed, or > changed, not the original source code. If that wasn't possible or too > cumbersome, checking in the tarballs in "3rdparty" would be better. > i also wouldn't give up the patches and for that reason i would like to move forward for now with keeping the tarballs as proposed. But i like the name "3rdparty" for the directory and we can later on change it from the tarballs to the unpacked code it we see demand for it. At the moment it's just easier to keep the tarballs and focus on other work. > > As svn users never download the complete history as DSCM users do, the pain > of binary files in the repo isn't that hard. In case AOOo moved to a DSCM > again later, the tarballs could be moved out again easily. > agree, we don't really loose anything, can change if necessary and can continue with our work Juergen
