On 3/24/12 5:28 PM, Marvin Humphrey wrote:
2012/3/13 Jürgen Schmidt<jogischm...@googlemail.com>:
we have prepared a new developer snapshot on the way to our first release.
Hello again... I have a couple more questions.
sorry for the late response, I haven't noticed it before
It looks like the dev snapshot src tarball is an export of svn trunk, but with
LICENSE and NOTICE hoisted out of trunk/main/ into the top level. Is that
right? If not, can you describe the process by which the src release was
created?
ok, let me explain what I did.
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.
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.
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.
You can run it during a normal build
cd main/instsetoo_native/util
dmake aoo_srcrelease
The resulting files can be found in the output directory besides the
normal office builds.
The simple ideal is to capture a bare "svn export" to an
archive so that the source release matches a tag in version control; many
projects also capture a handful of generated files (because they use Maven or
whatever to prepare their releases), but in such cases it must be clear what
those files are and where they came from, and having a large number of
generated files is discouraged. What we want to avoid is having a src release
dependent on the release manager's local setup, in a worst case vacuuming up
local files which are not present in version control. So... if you could let
us know how the src archive was created, that would be helpful.
see my description above, anybody can build the src release no local
setup necessary.
It is more or less a pure svn dump.
What would also be helpful is if you could describe how you are using RAT.
Incubator PMC members typically run raw RAT when vetting releases and review
any files it flags individually, but that's not realistic for AOO -- I
just turned RAT loose on the snapshot and it reported "10793 Unknown
Licenses". :) My local copy of RAT is a little old, but even if I bring it
up to date I'm sure I'm going to need to use your exclusion lists.
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.
Lastly, for the record I tried to build from the source archive on my MacBook
Pro running Snow Leopard but ran into problems. That would ordinarily be a
concern for an incubating release, but for AOO I don't think having IPMC
members run a build-and-test check is particularly useful. Not a blocker.
well this beast of software needs some preparation before. We have
longer list of build requirements document in the wiki. In the end it is
a one time preparation for our volunteers.
I hope we can improve this in the future as well but it's indeed not
comparable with a Java library project. Sometimes I wish I would work on
something smaller without such a long history and old code ;-)
I hope this helps to answer your questions, let me know if you need more
info.
Juergen
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
