bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Date Fri, 03 Aug 2012 08:15:15 GMT
On 8/3/12, Greg Stein <> wrote:
> On Fri, Aug 3, 2012 at 12:27 AM, Olemis Lang <> wrote:
>> my comments below . Please recall that I'm not an expert neither in
>> the art of licensing nor in ASF best practices and standards .
> No worries. You've got myself as the first stop, and then the rest of
> Foundation as the second stop :-)


>> On 8/2/12, Greg Stein <> wrote:
>>> * 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
>> ?
> Nope.
> The LICENSE/NOTICE files are for releases, not for checkouts from our
> repository. By your logic, there would be a LICENSE/NOTICE in *every*
> subdirectory because people could check out anything.

I understand your point , but according to my reasoning that's not the
case but ...

> It is important to make a distinction here. If somebody checks out
> files from our repository, that is NOT a release. The ASF is not
> standing behind it as a release. The important work of the Foundation
> is when we make a release. And the *only* release that this project
> will make is the entire bundle (unless I'm horribly mistaken on the
> community goals here). Since the plugins will not be released
> individually, they exist merely as an architectural convenience. The
> *release* is trunk/ and that is where the LICENSE/NOTICE files should
> reside, and then be delivered in the resulting tarball to the users.

... after reading this I see there's no point in following the
discussion . It's clear to me now .

>>> * 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
> Sounds good!


>> 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 .
> This would be great. Details TBD, and I don't really have any input
> for the dev community.

ok . that's to be continued in a separate thread

>> NOTICE , LICENSE and other files will only need to
>> mention that file (<= I'm hoping we can do that).
> There is no need for these files to refer to a proposed TRAC_VERSION
> file. It is sufficient to state "portions developed by..." (as they do
> now).

I said so in order to say something like this in e.g. NOTICE file .

"A modified copy of Trac is included in this source release package.
Exact version of Trac may be found in TRAC_VERSION file" ... etc , etc

>>> 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.
>> may be included as
>> well
> Trac's BSD license does NOT require any mention of changes. We do it
> because we're nice :-) ... not to mention that users may need/want to
> know that information (like I wondered when reviewing the tarball).

Exactly !




Blog ES:
Blog EN:

Featured article:

View raw message