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 <gstein@gmail.com> wrote:
> On Wed, Jul 25, 2012 at 1:18 PM, Gary Martin <gary.martin@wandisco.com>
> 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:
|