On Fri, Aug 3, 2012 at 12:27 AM, Olemis Lang <[email protected]> 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 <[email protected]> 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. 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 now). >... >> 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 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: http://svnbook.red-bean.com/en/1.1/ch07s05.html 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) Cheers, -g
