bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Date Fri, 03 Aug 2012 06:27:08 GMT
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 ?


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.

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.

>> * 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.

> 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

>> 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).

>> (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 ?

Yes. There is precedent within the Foundation, which is why I told
Ethan this is not a problem.

We *do* want to avoid forking Trac, so we'll just do what work is
possible to get necessary changes ported upstream.

>   2. should we refresh and apply every time Trac source
>       code is updated in vendor branch ?

I believe you have a misunderstanding of vendor branches. The vendor
branch tracks upstream. Each time we pull from upstream, the vendor
branch(es) area is updated with those changes. Thus,
incubator/bloodhound/vendor/trac/* precisely mirrors the upstream.

Next, we have a copy of that in trunk/trac/. Local changes have been
made to that directory.

When the vendor branch area is updated to a newer revision from
upstream, those changes are then *merged* into trunk/trac/. Thus,
trunk/trac/ is always some copy of upstream + local changes.

(the individual steps are slightly different semantically, but suffice
it to say that the end result is that we get new copies of upstream
and we reapply the changes)

>   3. is there an easy (recommended ?) procedure to
>       do (2) using subversion ?

Please read up on "vendor branches" in the svnbook:

Short is: we're already doing Best Practices for maintaining local
patches, with a goal of producing them for pushing upstream. (and
maintaining them locally as upstream continues development)


View raw message