lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <>
Subject Re: [lucy-dev] Grant plan
Date Sat, 11 Sep 2010 17:02:35 GMT
Hi Marvin,

> I asked about examples we might reference on general@incubator.a.o a few days
> ago, but nobody replied (<>), so
> we'll just have to follow the instructions as best we can.


> I have assembled a list of individuals who have made significant contributions
> to KinoSearch and thus must participate in the software grant.  All of them
> have been contacted privately and expressed their preliminary approval.


> I have also been accumulating a list of people who have made small
> contributions, which while welcome, may not be significant for the purposes of
> the grant.  For these individuals, I think we should have them write to
> lucy-dev indicating whether they agree with that assessment and whether they
> think they need to participate formally.  This is what I see that mod_fcgid
> did:


> There are also people in the KinoSearch svn logs who are credited for having
> identified bugs or provided ideas, but who did not supply patches or whose
> patches were not incorporated into the code base.  I don't think we need to
> contact these individuals, but we should clarify the status of these commit
> messages.

To be honest -- I think that's pushing it and not necessary. We don't need
to contact every person that's ever posted a JIRA comment or provided an

> To track all of these issues, I think we should open a JIRA issue entitled
> "Software Grant Participants".

+1, done, here [1]. I also cleaned up JIRA a bit, changing the Lucy URL to
[2], and adding components for documentation, the website and a few other
things so that we could classify issues better. One thing I did was remove
"Core -" in front of all of the comps -- I think it's pretty clear that they
are core.

> Another task that needs to be completed before the code drop is the excising
> of materials which cannot be relicensed.  For example, the standalone utility
> script trunk/devel/bin/dump_index was adapted by Brian Phillips from an
> original which was published in the Plucene distribution; it will simply not
> be included in the grant.

Great, so let's just not include it.

> Lastly, all references to the current GPL/Artistic licensing need to be
> excised.  My current thought is to remove the licensing information but leave
> the copyright notices with my name in place as sort of a "todo" tag.

You can do an SVN import with the GPL license header in the source code and
in the license files, it's fine. This should *not* prevent us from doing
that. We just can't release software with these tags in them at Apache. So,
before making an Incubation release, the tags need to be removed. My

1. svn drop as is
2. create JIRA issue (similar to OODT-3 [3]) to fix license headers/etc.
3. work on JIRA issue and resolve it before releasing.

> The result of this process will be a clean tarball that can be unpacked and
> committed to an "import" directory in one fell swoop.  Then we can proceed by
> through the codebase file by file, removing my copyright, moving other
> copyright and license notifications to LICENCE and NOTICE, and adding the ASF
> headers.


Just import as-is, or we'll never get anywhere. Like I said the license
stuff can be done post import, with a JIRA issue.

> I am currently reviewing the KinoSearch commit history commit by commit
> looking for IP issues and assembling an authoritative list of contributors.
> This is laborious, but it is important work; the audit has yielded one
> additional name for the software grant participant list (see LUCENE-675,
> <>).  I think it will take me another week or two to
> complete my review.  Once that's done, I'll branch and tag the KinoSearch
> repository and prepare the grant tarball and checksum.

OK, when you are ready let me know. I think having someone besides you do
the import is critical (remember: single point of failure?) :) I'll throw my
name into the hat to svn import it, since I worked with Joe S. to get it
done on OODT. Any other mentors want to do it, just let me know and I'll
stand down.

> I'm thinking that I should send a private mail to each of the small
> contributors like the following.
>     Greetings [name of valued contributor],
> [...]

My honest assessment of this step: *overkill*. You know who the significant
contributors to Lucy are, I would imagine by now. Just get them to sign the
SGA and we're fine.

I think going through the tedious process of sending these emails over the
fence, then waiting for them to throw one back over will only continue to
delay, and the risk of a contributor getting angry over not being part of an
SGA when her major contribution was a comment on a JIRA issue, or an email
RE: design sent to an ML, is little to none.

OTOH, if you feel the person has contributed more than a comment or two, or
a design email or two, then by all means, include them in the SGA.



Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

View raw message