2012/3/26 Jürgen Schmidt <jogischm...@googlemail.com>: > I created and used an ant script (main/solenv/bin/srcrelease.xml) to create > the src release files as part of the normal build if required. I decided to > use ant because it allows me some flexibility... > > Our trunk contains 4 directories where trunk/ext_sources shouldn't be > included in a src release because it contains external library packages for > convenient purposes only. We have to patch some external libs for example > where an upstreaming is not possible or where the versions we use are too > old. That is something we would like to improve in the future and over time. > But they will be downloaded on demand.
OK, I think that sounds right. > trunk/main > trunk/ext_libraries > trunk/ext_sources > trunk/extras > > That means I include main, ext_libraries and extras only. ext_libraries is a > new module where we started to collect build projects for external libs in > our own office specific build env etc. Main purpose is to have a cleaner > separation over time. > > trunk/main/NOTICE and trunk/main/LICENSE and trunk/main/README are moved in > the destination root directory of our src release to simply have it in the > root as expected. > > We kept trunk clean so far or better we don't put any files in trunk > directly and used main as the main source directory. extras contains > translation files only to keep them somewhat separated as well. I had a brief glance at srcrelease.xml, and between that and your description of how the system has been set up, I'm content that you understand the requirements and are making a good-faith effort to uphold them. >> Canonical ASF source releases are supposed to be assembled using a >> repeatable build process. > > > I think it is very repeatable and the script used is part of the source as > well. Excellent. > see my description above, anybody can build the src release no local setup > necessary. > > It is more or less a pure svn dump. Right -- just with a few files moved around and a bunch filtered out. > We run RAT on our build bots (at least on one) and use the exclude list that > you can find in trunk/main/rat-excludes > > You can find the nightly output under > http://ci.apache.org/projects/openoffice/rat-output.html > > Right now we have still 1471 files with unknown license but they are more or > less all part of the SGA or should be. > > We are working right now on these files and analyze if it's possible to > include a license header or not. OR put in in the exclude file with a proper > comment to document everything. Nice workflow, +1. I had a look at the rat-excludes file. The individual files which are listed and documented in the lower half -- that all looks great. The top half, though, has an awful lot of wildcards: **/*.add **/*.all **/*.am **/*.applications **/*.attr **/*.btm **/*.cgm **/*.chd **/*.cl **/*.cls **/*.cmn **/*.common **/*.component **/*.components [...] # binary media formats **/*.bmp **/*.emf **/*.eps **/*.gif **/*.giff **/*.icns **/*.ico **/*.img **/*.jpeg **/*.jpg **/*.mov [...] # binary document formats **/*.doc **/*.docx **/*.odb **/*.odf **/*.odg **/*.odl [...] I understand that a lot of those filetypes can't have embedded licenses. Ideally, each such file would be listed together with a comment explaining its licensing situation. Less desirable but still acceptable to list wildcards within directories, explaining where e.g. all the images in this/folder/full/of/*.jpeg files came from. Having wildcards which exclude a file type for the whole source tree, though, weakens the RAT check, both now and in the future. Are you confident that all the files which match those wildcards were part of the Oracle SGA or are otherwise properly licensed for ASF usage? Thanks, Marvin Humphrey --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
