my comments below . Please recall that I'm not an expert neither in the art of licensing nor in ASF best practices and standards .
On 8/2/12, Greg Stein <[email protected]> wrote: > On Wed, Jul 25, 2012 at 1:18 PM, Gary Martin <[email protected]> > wrote: >>... >> Please vote: >> [ ] +1 Release this package as Apache Bloodhound 0.1.0 >> [ ] +0 Don't care >> [ ] -1 Do not release this package (please explain) > > +1 to release. > > Changes that I'd suggest for the next release: > [...] > > * remove LICENSE/NOTICE from bloodhound_* subdirs. just the top-level > dir is proper. (and maybe generally simplify; eg. why CHANGES in > bloodhound_dashboard?) Even if Bloodhound is distributed in a single file (tarball) it is developed in the form of a set of plugins . bloodhound_* folders contain source code for each one of them . License files are in there because it makes sense to checkout only that particular subset of the code in svn repos , build the corresponding plugin, install it and use it . Indeed it's also possible to build packages for each plugin and distribute them . Is this a reason good enough to keep license files in bloodhound_* folders ? > * found another NOTICE in doc/html-templates/ (?!) +1 for removing it . > * is doc/wireframes supposed to be shipped in the release? I don't think so [...] > * would also be nice to indicate what release/revision of Trac is > incorporated into this release, for Release 2 (... or maybe later) we have to work on this direction. We need to know that information in code as well . Right now it turns out that the revision number in the footer represents changeset ID corresponding to ASF repos rather than Trac's . My initial suggestion is to update footer with something like {{{ Powered by <a href="http://www.apache.org/";>Apache<sup>TM</sup></a> <a href="http://issues.apache.org/bloodhound";>Bloodhound</a>. Standing on the shoulders of <a href="http://trac.edgewall.org/";>Trac ${correct_trac_version}</a> (<a href="http://issues.apache.org/bloodhound/wiki/Patches";>modified</a>) }}} ... notice that we can use another URL instead of http://issues.apache.org/bloodhound My second suggestion is to include in trunk a file named TRAC_VERSION containing the version, changeset ID, ... of Trac code committed in vendor branch . NOTICE , LICENSE and other files will only need to mention that file (<= I'm hoping we can do that). File format is TBD .. and TBH I really don't care much about it as long as it will be readable for users interested to know after reading NOTICE , ... At the same time it also has to be easy to parse in order to use that value to provide correct Trac version in about page , footer , ... i.e. everywhere Trac version will be displayed . > along with a notice that local patches > have been applied. +1 ... and if current modifications need to be mentioned then maybe a link to (or a copy of) aforementioned (non-existent) wiki page (i.e. http://issues.apache.org/bloodhound/wiki/Patches) may be included as well > (on that note: has anybody worked to push the local > changes upstream?) > this is homework for trac-dev ML , I guess . Nonetheless I wanted to know something in advance . If trac-dev decides not to incorporate Bloodhound patches : 1. may we keep them in trunk ? 2. should we refresh and apply every time Trac source code is updated in vendor branch ? 3. is there an easy (recommended ?) procedure to do (2) using subversion ? PS: refresh and apply means the equivalent of executing the following steps with Hg MQ - hg pull <trac_repository> <vendor_branch> - hg update tip - hg qpush - <modify source code by paying attention to rejected hunks> - hg qrefresh - hg cp <vendor branch with patches> <trunk/trac> - hg qpop ... well something like that . I hope you get the idea ;) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:
