You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2011/10/28 00:31:35 UTC
[lucy-dev] All dependency licensing issues resolved
Greets,
A few hours ago, the existing implementation of the Clownfish parser was
swapped out for one based on Flex and the Lemon parser generator, eliminating
Lucy's dependency on the CPAN module Parse::RecDescent.
As of today, the Lucy mainline no longer has any non-core Perl dependencies,
and all of the licensing and legal issues that needed to be resolved during
Lucy's incubation have been resolved.
The Flex/Lemon-based parser has an additional benefit: it is much faster than
the Parse::RecDescent based version. The Clownfish compiler now parses all of
those .cfh files in core/ in under a second -- a task that used to take
approximately 15-20 seconds. Between that and several other other changes
from the last few months, the build time for Lucy has improved dramatically
since release 0.1.0, dropping from just over three minutes to just over a
minute and a half.
Marvin Humphrey
Re: [lucy-dev] [DISCUSS] Graduation (was Re: [lucy-dev] All
dependency licensing issues resolved)
Posted by "David E. Wheeler" <da...@kineticode.com>.
On Nov 1, 2011, at 6:39 PM, Nathan Kurz wrote:
> I love your analogy, but it conveniently forgets the five years that
> Lucy dropped out of school, ran away from home, lived under an
> assumed name, and pretended to be a consenting adult. Lucy is glad to
> be back in a warm, loving home instead of busking on the streets and
> shacking up with long-haired men of dubious musical talent
> (http://www.rectangular.com/about.html), but she views her time back
> as just as much for her parents' benefit as for hers. If they want to
> persist in their squabbling, and if they really want to rent her
> bedroom to some stranger for some pittance of a rent, she reminds them
> that she's perfectly able to take care of herself and that Creamy G
> promised he'd always be "froopy" for her.
>
> Is he the kind of "nice guy" you were picturing? Do you really want
> to drive her back to that? :)
Now I'm worried.
:-)
D
Re: [lucy-dev] [DISCUSS] Graduation (was Re: [lucy-dev] All
dependency licensing issues resolved)
Posted by "Henry C." <he...@cityweb.co.za>.
On Wed, November 2, 2011 03:39, Nathan Kurz wrote:
> long-haired men of dubious musical talent
> (http://www.rectangular.com/about.html), but she views her time back
I'm afraid it's far, far worse than that. Dig down deep enough into the
unkempt hair and the frightening truth may just reach out and drag you in,
screaming, gurgling.
Some say he's the premature reincarnation of Jeff Minter (of Llamasoft fame) -
http://en.wikipedia.org/wiki/Jeff_Minter. This is only a rumour, though, so
don't take the hushed, furtive whispers at the water-cooler too seriously.
When I confronted him (years ago) with this very question, he just smiled
enigmatically.
Minter is still alive, so perhaps CreamyG is an e-fork :)
Either way, he's not coming close to my pure blue-eyed blonde beautiful
daughters...
Not until he shaves, at least.
...or procures a less pretentious guitar.
h
Re: [lucy-dev] [DISCUSS] Graduation (was Re: [lucy-dev] All
dependency licensing issues resolved)
Posted by Nathan Kurz <na...@verse.com>.
On Fri, Oct 28, 2011 at 2:57 PM, Chris Hostetter <ho...@fucit.org> wrote:
> Mattman is like Lucy's mom: "Now that you've finished high school, you
> should think about getting a part time job, so you can move into your own
> apartment while you go to college at night, so you can save up money to
> start a family when you meet a nice guy to settle down with."
I love your analogy, but it conveniently forgets the five years that
Lucy dropped out of school, ran away from home, lived under an
assumed name, and pretended to be a consenting adult. Lucy is glad to
be back in a warm, loving home instead of busking on the streets and
shacking up with long-haired men of dubious musical talent
(http://www.rectangular.com/about.html), but she views her time back
as just as much for her parents' benefit as for hers. If they want to
persist in their squabbling, and if they really want to rent her
bedroom to some stranger for some pittance of a rent, she reminds them
that she's perfectly able to take care of herself and that Creamy G
promised he'd always be "froopy" for her.
Is he the kind of "nice guy" you were picturing? Do you really want
to drive her back to that? :)
--nate
> This type of encouragement is good -- it's healthy to remind the project
> that it shouldn't hide out in the basement as a podling forever.
>
> we're all entitled to our opinions about the status of the project --
> you're certainly free to play the part of the Uncle who thinks Lucy hasn't
> made enough of herself yet and needs to date more before she's ready to
> move out into the big city on her own -- but ultimately it's up to the
> community (the whole community) to decide when it is "ready" to vote
> for it's own graduation, and it's up to the IPMC to vote to approve that
> graduation and propose it to the board as a resolution, and it's up to the
> board to accept that proposal and create a new PMC.
>
> Everyone is free to voice their opinions during these discussions, and
> cast their votes however they see fit -- but ultimatley if you care enough
> about Lucy to subscribe to these mailing lists, and participate in this
> discussions, then it seems like there probably a lot more productive ways
> to contribute then getting into a pissing match over wether Lucy is ready
> for graduation.
>
> if you think there aren't enough contributors, then contribute. if you
> think there aren't enough committers, then nominate someone. if you think
> the overall activity level is too low to be self sustaining, then
> encourage more people to get involved. etc....
>
>
> (For the record: I consider myself Lucy's slightly senile grandfather. a
> dirty old man with a weak hip who doesn't spend much time with Lucy on a
> regular basis, and frequently spouts non-sense, but occaionally spouts
> inspiring wisdon in between attempts to get Lucy to "pull my finger".)
>
>
>
> -Hoss
>
>
Re: [lucy-dev] [DISCUSS] Graduation (was Re: [lucy-dev] All dependency
licensing issues resolved)
Posted by Chris Hostetter <ho...@fucit.org>.
: You are pushing for it - and I don't get why.
Mattman is being the voice of progress, encouranging the project to think
about it's future, and about moving forward and leaving the nest.
Mattman is like Lucy's mom: "Now that you've finished high school, you
should think about getting a part time job, so you can move into your own
apartment while you go to college at night, so you can save up money to
start a family when you meet a nice guy to settle down with."
This type of encouragement is good -- it's healthy to remind the project
that it shouldn't hide out in the basement as a podling forever.
we're all entitled to our opinions about the status of the project --
you're certainly free to play the part of the Uncle who thinks Lucy hasn't
made enough of herself yet and needs to date more before she's ready to
move out into the big city on her own -- but ultimately it's up to the
community (the whole community) to decide when it is "ready" to vote
for it's own graduation, and it's up to the IPMC to vote to approve that
graduation and propose it to the board as a resolution, and it's up to the
board to accept that proposal and create a new PMC.
Everyone is free to voice their opinions during these discussions, and
cast their votes however they see fit -- but ultimatley if you care enough
about Lucy to subscribe to these mailing lists, and participate in this
discussions, then it seems like there probably a lot more productive ways
to contribute then getting into a pissing match over wether Lucy is ready
for graduation.
if you think there aren't enough contributors, then contribute. if you
think there aren't enough committers, then nominate someone. if you think
the overall activity level is too low to be self sustaining, then
encourage more people to get involved. etc....
(For the record: I consider myself Lucy's slightly senile grandfather. a
dirty old man with a weak hip who doesn't spend much time with Lucy on a
regular basis, and frequently spouts non-sense, but occaionally spouts
inspiring wisdon in between attempts to get Lucy to "pull my finger".)
-Hoss
Re: [lucy-dev] [DISCUSS] Graduation (was Re: [lucy-dev] All
dependency licensing issues resolved)
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Oct 27, 2011 at 09:51:26PM -0700, Nathan Kurz wrote:
> I have no particular opinion on this matter, but please take the rest
> of this conversation to private email. The tone is poor, and I don't
> think it reflects well on Lucy.
Thanks, Nate, for stepping in and noting something I had thought as well, and
thanks to the participants for bringing us back on track so swiftly, because
the content of this exchange has been welcome and productive.
Mattmann's JFDI bulldozer spirit prods an awful lot of progress in the
Incubator and around the ASF. In this case, it has elicited a useful critique
from Torsten.
Regardless of whether Lucy's graduation needs to be gated on increasing the
diversity of commits, it's true that it would be in the project's best
interest if we improved in that area as much as we have in others. I think it
is wise for us to stay on top of this issue, and that we shouldn't relax the
pressure until it is truly behind us.
I'm going to continue to work on tearing down barriers to participation. A
few months ago, someone contemplating a C host binding would have had to
address JSON parsing and UTF-8 validation by figuring out how to integrate
external libraries; those are both solved problems now. And since
Parse::RecDescent, the last of our CPAN dependencies, is history as of
yesterday, all you needs is a machine with Perl 5.10 and a C compiler on it to
build Lucy -- no CPAN expertise or configuration required.
This work will pay off sooner or later. I know Peter is pretty
time-constrained, but we have the advantage that since he is already expert on
many areas of Lucy, less bootstrapping is required than for a fresh face like
Brad or Torsten. Fun times ahead!
Marvin Humphrey
Re: [lucy-dev] [DISCUSS] Graduation (was Re: [lucy-dev] All
dependency licensing issues resolved)
Posted by Nathan Kurz <na...@verse.com>.
I have no particular opinion on this matter, but please take the rest
of this conversation to private email. The tone is poor, and I don't
think it reflects well on Lucy.
Nathan Kurz
nate@verse.com
Re: [lucy-dev] [DISCUSS] Graduation (was Re: [lucy-dev] All
dependency licensing issues resolved)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Torsten,
On Oct 28, 2011, at 12:34 AM, Torsten Curdt wrote:
>>> Right. So then there would be just no one committing?
>>> Please explain how that should work from your POV.
>>
>> Committing isn't the only contribution.
>
> That doesn't answer the question and you know it.
Let me try and better explain then. What question are you asking?
Are you saying that if a community only has 1 major person writing
code then it won't be a success? If so, then I'd disagree with you
and my statement above holds, and I believe answers the question.
The Apache mantra is "community over code", and 3 +1s is what it
is all about. On a project where one of those +1s is a coder/hacker,
another is a release manager, and another is someone that writes
documentation, then no I don't see a problem with that. If the project
can muster 3 +1s for new committers, for releases, for etc., then
it's absolutely fine.
>
>>> Exactly. So let's give it the time it needs. What's so bad if it takes 3 years?
>>
>> That's not a sustainable model for the incubator.
>
> So far we have been OK. We had other podlings that also took their time needed.
There have been several discussions over the past 9 months about Incubator
projects that have been alive for years and in all of those cases the projects
are either being encouraged to graduate (e.g., RAT [1]), or to be retired (Alios [2], etc.).
Growing projects that live in the Incubator for years is not a sustainable model.
Projects should have goals of graduating as soon as they are ready. That's why we
have monthly Incubator reporting for the first 3 months, and quarterly after that. Think
about what quarterly means. And think about what reporting means. It means that
at worst, every 3 months, the IPMC chair reports to the board on the _current status
of the podling towards *graduation*_. That's what reporting is about. And, that's
what mentoring is about. Mentors should actively check with their podlings during
those 3 month reporting cycles to make sure they are on path to meet their goals
for graduating.
>
>>> Quoting from the incubator guide at
>>> Snip...
>>> That's just not the case yet.
>>
>> Says you with absolutely 0 merit in this community besides lurking.
>
> As a member of the ASF and a member of the incubator PMC I am voicing
> my concerns.
> You just call me troll and don't adress my concerns at all.
You are welcome to your concerns. I am also welcome to my statement that
I think Lucy is graduating. Both of us are Incubator PMC members, and
have a single VOTE towards Lucy's graduation when the time that the VOTE
is cast, at which point it's at least 3 +1s from the PMC, and then simply more +1s
than -1s at that point after that.
I have a few real concerns right now too, which led me to start this thread:
1. Those doing the work in Lucy (and yes, it's more than Marvin, and to reduce it
to just Marvin is a joke) don't have binding VOTEs on the work they are doing right
now. Joe Schaefer stepped up and rewrote the build system
with Marvin's help. Peter just RM'ed the frickin' project (NICE Peter!). We've had
new committers (e.g., David, Brad). We've had releases, multiple of them. Heck,
even I RM'ed one of them. I want to get the people doing the work to have
binding VOTEs, and the best way to do that is to make them a committee, that is
self-directing and managing, make them a PMC. Have they met the criteria for
that?
2. In my mind, anyone that goes back, reads the Lucy proposal [3], and
reads out monthly reports for the last 1 year and 3 months will see that
the checklist has been checked off from what we originally set out to do.
3. Not gating or tying graduation to a set of development goals, and thinking
that we are still X development goals away from graduation. Guess what,
development can still occur while you are graduating! In fact, I'd encourage it.
In Tika and OODT, we didn't shut down SVN when we started graduating.
We didn't shut down the mailing lists. We just kept working. Same in Nutch.
Same in all the projects I've watched graduate, and mentor over the years,
including some pretty huge ones at Apache.
4. A TLP allows the Lucy community to continue doing what they are doing.
It's not TLP and then everything is stopped, we pat ourselves on the make,
and we're 1.0. TLP != 1.0. TLP simply says that the commumity has shown
that it can: (a) self-govern; (b) elect new committers; (c) make releases of
ALv2 licensed software, with proper license vetting, etc.; (d) show diversity
in terms of organizations, etc. Lucy has shown all that. There is no requirement
that you need to be at 1.0, or have met N development goals before you
can graduate.
I hope that clarifies my position.
Cheers,
Chris
[1] http://s.apache.org/lx
[2] http://s.apache.org/7gf
[3] http://wiki.apache.org/lucy/LucyIncubatorProposal
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [lucy-dev] [DISCUSS] Graduation (was Re: [lucy-dev] All
dependency licensing issues resolved)
Posted by Torsten Curdt <tc...@vafer.org>.
>> Right. So then there would be just no one committing?
>> Please explain how that should work from your POV.
>
> Committing isn't the only contribution.
That doesn't answer the question and you know it.
>> Unfortunately in terms of diversity not that much seems to have changed since.
>>
>>> http://s.apache.org/a08
>>
>> ...even with the new committer on board.
>
> Says you. You were trolling then and you are again.
Just calling me a troll does not make this go away.
>> You are pushing for it - and I don't get why.
>
> You probably don't.
No, and you don't help by not giving a reason.
>> Exactly. So let's give it the time it needs. What's so bad if it takes 3 years?
>
> That's not a sustainable model for the incubator.
So far we have been OK. We had other podlings that also took their time needed.
>> Quoting from the incubator guide at
>> Snip...
>> That's just not the case yet.
>
> Says you with absolutely 0 merit in this community besides lurking.
As a member of the ASF and a member of the incubator PMC I am voicing
my concerns.
You just call me troll and don't adress my concerns at all.
> Sorry but we can agree to disagree and leave it at that.
Maybe we should take this offline.
cheers,
Torsten
Re: [lucy-dev] [DISCUSS] Graduation (was Re: [lucy-dev] All
dependency licensing issues resolved)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Sent from my iPhone
On Oct 27, 2011, at 6:28 PM, "Torsten Curdt" <tc...@vafer.org> wrote:
>>> That's all and great but this falls down as soon as Marvin (for
>>> whatever reason) would be gone.
>>
>> I wholly disagree with you.
>
> Right. So then there would be just no one committing?
> Please explain how that should work from your POV.
Committing isn't the only contribution.
>
>>> Frankly - I don't understand the rush.
>>
>> What rush? I raised this issue months ago, and we actually had some discussions
>> about it. Most folks in the community agreed that the remaining item to check off
>> was the licensing issues.
>
> Unfortunately in terms of diversity not that much seems to have changed since.
>
>> http://s.apache.org/a08
>
> ...even with the new committer on board.
Says you. You were trolling then and you are again.
>
>> Months is not a rush.
>
> You are pushing for it - and I don't get why.
>
You probably don't.
Every mentor should be asking the question periodically if their podlings are ready to graduate.
>> Go read the Lucy reports: the project has been in Incubation
>> since July 2010: so it's been about 1 year, 3 months. Every project has a different
>> amount of time in Incubation
>
> Exactly. So let's give it the time it needs. What's so bad if it takes 3 years?
That's not a sustainable model for the incubator.
> Just bringing this up every other month does not bring it any closer
> to a successful graduation.
Try 3 months.
>
>> and every project has a checklist of things to get done
>> before graduating. I think we've met that checklist.
>
> Quoting from the incubator guide at
> Snip...
> That's just not the case yet.
Says you with absolutely 0 merit in this community besides lurking.
Sorry but we can agree to disagree and leave it at that.
>
Re: [lucy-dev] [DISCUSS] Graduation (was Re: [lucy-dev] All
dependency licensing issues resolved)
Posted by Torsten Curdt <tc...@vafer.org>.
>> That's all and great but this falls down as soon as Marvin (for
>> whatever reason) would be gone.
>
> I wholly disagree with you.
Right. So then there would be just no one committing?
Please explain how that should work from your POV.
>> Frankly - I don't understand the rush.
>
> What rush? I raised this issue months ago, and we actually had some discussions
> about it. Most folks in the community agreed that the remaining item to check off
> was the licensing issues.
Unfortunately in terms of diversity not that much seems to have changed since.
> http://s.apache.org/a08
...even with the new committer on board.
> Months is not a rush.
You are pushing for it - and I don't get why.
> Go read the Lucy reports: the project has been in Incubation
> since July 2010: so it's been about 1 year, 3 months. Every project has a different
> amount of time in Incubation
Exactly. So let's give it the time it needs. What's so bad if it takes 3 years?
Just bringing this up every other month does not bring it any closer
to a successful graduation.
> and every project has a checklist of things to get done
> before graduating. I think we've met that checklist.
Quoting from the incubator guide at
http://incubator.apache.org/guides/graduation.html
"The project is considered to have a diverse community when it is not
highly dependent on any single contributor (there are at least 3
legally independent committers and there is no single company or
entity that is vital to the success of the project)"
That's just not the case yet.
cheers,
Torsten
Re: [lucy-dev] [DISCUSS] Graduation (was Re: [lucy-dev] All
dependency licensing issues resolved)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
On Oct 27, 2011, at 5:18 PM, Torsten Curdt wrote:
>>> Commit mails on markmail.org still show mostly "just" Marvin.
>>> Or what am I missing?
>>
>> Commits aren't the only sign of community. They also aren't the only
>> sustaining thing you need. You need:
>>
>> * VOTEs
>> * discussion emails
>> * JIRA threads
>> * release managers
>> * documentation writers, etc.
>
> That's all and great but this falls down as soon as Marvin (for
> whatever reason) would be gone.
I wholly disagree with you.
[...]
> As much as I would love to see lucy graduate I still think it's not ready.
>
> Well, and I am saying this is not a diverse community - which also one
> of the goals of incubation. A single person committing on a TLP is not
> quite the Apache way I know.
>
> Frankly - I don't understand the rush.
What rush? I raised this issue months ago, and we actually had some discussions
about it. Most folks in the community agreed that the remaining item to check off
was the licensing issues.
http://s.apache.org/a08
Months is not a rush.
Go read the Lucy reports: the project has been in Incubation
since July 2010: so it's been about 1 year, 3 months. Every project has a different
amount of time in Incubation and every project has a checklist of things to get done
before graduating. I think we've met that checklist.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [lucy-dev] [DISCUSS] Graduation (was Re: [lucy-dev] All
dependency licensing issues resolved)
Posted by Torsten Curdt <tc...@vafer.org>.
>> Commit mails on markmail.org still show mostly "just" Marvin.
>> Or what am I missing?
>
> Commits aren't the only sign of community. They also aren't the only
> sustaining thing you need. You need:
>
> * VOTEs
> * discussion emails
> * JIRA threads
> * release managers
> * documentation writers, etc.
These things you need on top, indeed :)
> I've seen Peter, David, Nathan, Joe (S.) and a host of other folks
> contribute.
That's all and great but this falls down as soon as Marvin (for
whatever reason) would be gone.
Graduation is also about build a sustainable community - not a single
person doing the coding.
And frankly speaking I am lurking on the dev list and didn't see that
many discussion emails.
As much as I would love to see lucy graduate I still think it's not ready.
> And committers != PMC != community.
nitpicking: whether committers != PMC depends on the project, it's the
same for some projects
> The VOTE is to decide on whether or not Lucy has:
>
> * elected new (P)PMC members
> * shown that it can govern itself
> * made releases
> * vetted its licenses
> * operated in the Apache way
>
> I'd say it has.
Well, and I am saying this is not a diverse community - which also one
of the goals of incubation. A single person committing on a TLP is not
quite the Apache way I know.
Frankly - I don't understand the rush.
cheers,
Torsten
Re: [lucy-dev] [DISCUSS] Graduation (was Re: [lucy-dev] All
dependency licensing issues resolved)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
On Oct 27, 2011, at 4:18 PM, Torsten Curdt wrote:
>> As soon as I VOTE on the latest RC, I'm going to recommend that the Lucy
>> community over the next month seriously consider graduating from the Incubator.
>>
>> You've fulfilled pretty much the mantra that you set out in the Incubator:
>>
>> - elected new committers
>> - had > 1 release manager (nice job Peter!)
>> - made releases
>> - cleaned up licensing issues
>
> Commit mails on markmail.org still show mostly "just" Marvin.
> Or what am I missing?
Commits aren't the only sign of community. They also aren't the only
sustaining thing you need. You need:
* VOTEs
* discussion emails
* JIRA threads
* release managers
* documentation writers, etc.
For the above:
I've seen Peter, David, Nathan, Joe (S.) and a host of other folks
contribute.
>
>> You guys are ready for prime time. What do others think? I raised this
>> issue a few months ago and the major thing I remember that was raised
>> was this licensing issue.
>
> That and not enough active committers.
> Doesn't look like the latter has changed yet.
And committers != PMC != community.
The VOTE is to decide on whether or not Lucy has:
* elected new (P)PMC members
* shown that it can govern itself
* made releases
* vetted its licenses
* operated in the Apache way
I'd say it has.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [lucy-dev] [DISCUSS] Graduation (was Re: [lucy-dev] All
dependency licensing issues resolved)
Posted by Torsten Curdt <tc...@vafer.org>.
> As soon as I VOTE on the latest RC, I'm going to recommend that the Lucy
> community over the next month seriously consider graduating from the Incubator.
>
> You've fulfilled pretty much the mantra that you set out in the Incubator:
>
> - elected new committers
> - had > 1 release manager (nice job Peter!)
> - made releases
> - cleaned up licensing issues
Commit mails on markmail.org still show mostly "just" Marvin.
Or what am I missing?
> You guys are ready for prime time. What do others think? I raised this
> issue a few months ago and the major thing I remember that was raised
> was this licensing issue.
That and not enough active committers.
Doesn't look like the latter has changed yet.
cheers,
Torsten
[lucy-dev] [DISCUSS] Graduation (was Re: [lucy-dev] All dependency licensing
issues resolved)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Marvin,
That's amazing!
As soon as I VOTE on the latest RC, I'm going to recommend that the Lucy
community over the next month seriously consider graduating from the Incubator.
You've fulfilled pretty much the mantra that you set out in the Incubator:
- elected new committers
- had > 1 release manager (nice job Peter!)
- made releases
- cleaned up licensing issues
You guys are ready for prime time. What do others think? I raised this
issue a few months ago and the major thing I remember that was raised
was this licensing issue.
Cheers,
Chris
On Oct 27, 2011, at 3:31 PM, Marvin Humphrey wrote:
> Greets,
>
> A few hours ago, the existing implementation of the Clownfish parser was
> swapped out for one based on Flex and the Lemon parser generator, eliminating
> Lucy's dependency on the CPAN module Parse::RecDescent.
>
> As of today, the Lucy mainline no longer has any non-core Perl dependencies,
> and all of the licensing and legal issues that needed to be resolved during
> Lucy's incubation have been resolved.
>
> The Flex/Lemon-based parser has an additional benefit: it is much faster than
> the Parse::RecDescent based version. The Clownfish compiler now parses all of
> those .cfh files in core/ in under a second -- a task that used to take
> approximately 15-20 seconds. Between that and several other other changes
> from the last few months, the build time for Lucy has improved dramatically
> since release 0.1.0, dropping from just over three minutes to just over a
> minute and a half.
>
> Marvin Humphrey
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [lucy-dev] C implementation [was Re: [lucy-dev] All dependency
licensing issues resolved]
Posted by "David E. Wheeler" <da...@kineticode.com>.
On Nov 6, 2011, at 8:29 PM, Marvin Humphrey wrote:
> Since the C API is going to be Unix only, the only objection I have to using
> Autoconf is that... it's Autoconf. ;) Have at it!
Why Unix only?
D
Re: [lucy-dev] C implementation [was Re: [lucy-dev] All dependency
licensing issues resolved]
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 11/6/11 10:29 PM:
> On Sun, Nov 06, 2011 at 08:42:33PM -0600, Peter Karman wrote:
>> Is there anything to be gained by using autoconf and friends?
>>
>> Or asked another way, why would we *not* want to use autoconf and friends?
>
> Since the C API is going to be Unix only, the only objection I have to using
> Autoconf is that... it's Autoconf. ;) Have at it!
>
> So long as you aren't suggesting *replacing* Charmonizer with Autoconf, we
> have consensus and we can move forward. (If OTOH you want to replace
> Charmonizer with Autoconf, prepare for a long, bloody, morale-sucking battle.)
>
no plan to replace Charmonizer on my part. long, bloody battle averted. :)
ok, based on this and Nate's good observations, I'm hearing consensus and I'll
move forward with autotools.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] C implementation [was Re: [lucy-dev] All dependency
licensing issues resolved]
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Sun, Nov 06, 2011 at 08:42:33PM -0600, Peter Karman wrote:
> Is there anything to be gained by using autoconf and friends?
>
> Or asked another way, why would we *not* want to use autoconf and friends?
Since the C API is going to be Unix only, the only objection I have to using
Autoconf is that... it's Autoconf. ;) Have at it!
So long as you aren't suggesting *replacing* Charmonizer with Autoconf, we
have consensus and we can move forward. (If OTOH you want to replace
Charmonizer with Autoconf, prepare for a long, bloody, morale-sucking battle.)
> I realize that it duplicates a lot of what charmonizer does.
Doesn't matter so long as we don't rely on it for that. In particular, it
doesn't matter so long as we don't introduce Autoconf into the build process
for Lucy's other host bindings.
> OTOH, automake can generate a fully-featured Makefile like Module::Build
> does for Perl (I know M::B doesn't create a file called 'Makefile' but the
> concept is the same).
I understand what you're getting at. If you're most comfortable using
Autotools for the Unix C bindings, cool by me -- other Unix C devs are also
going to feel comfortable with them.
Marvin Humphrey
Re: [lucy-dev] C implementation [was Re: [lucy-dev] All dependency licensing issues resolved]
Posted by "Andrew S. Townley" <as...@atownley.org>.
On 7 Nov 2011, at 4:13 AM, Nathan Kurz wrote:
> On Sun, Nov 6, 2011 at 6:42 PM, Peter Karman <pe...@peknet.com> wrote:
>> Marvin Humphrey wrote on 10/28/11 1:09 AM:
>>> It may be hard/awkward/impossible to do everything we need with Make. We
>>> still have to run the Clownfish compiler from Perl right now, so when we get
>>> to that, we'll need a Perl script that we can run from Make.
>>
>> Is there anything to be gained by using autoconf and friends?
>>
>> Or asked another way, why would we *not* want to use autoconf and friends?
[snip]
> In the comments, there are a few couple good arguments for CMake as a
> more palatable and portable alternative, but I think the authors are
> right that we will viewed with considerable suspicion and initial
> prejudice by Linux developers if we don't use autoconf for a C
> library.
>
> Strangely, I think it's actually permissible if the actual Makefile
> calls out to Perl and Charmonizer (and to build Charmonizer), but for
> acceptance this should be hidden behind a layer of "configure && make
> && make install".
>
> I'm not sure what the Windows perspective looks like, but I fear it
> might not be compatible with this view. Can any of the new additions
> to this list offer that perspective? And what works well for OSX?
>
> --nate
The only thing I can add is that I've been going through the same questions for a different project and still failed to come up with an answer that I liked. While it's a bit of a mutant, an advantage on OSX is that it will generate an Xcode project (along with MSVC projects), but there are still some issues. I haven't yet made the decision, but having worked with autotools for years on some fairly complex projects, when they work, they do make life a lot simpler than trying to do cross-platform stuff other ways.
Obviously, autotools will work just fine on OSX, but they don't support integration with native applications very well. Anytime you're doing any GUI stuff, you'll have developers using Xcode projects. If there are a lot of source files, adding these to the project manually and getting things working from an autotools build is a bit of a PITA.
Again, I don't have an answer, but I wanted to provide some OSX-centric observations.
Cheers,
ast
--
Andrew S. Townley <as...@atownley.org>
http://atownley.org
Re: [lucy-dev] C implementation [was Re: [lucy-dev] All dependency
licensing issues resolved]
Posted by Nathan Kurz <na...@verse.com>.
On Sun, Nov 6, 2011 at 6:42 PM, Peter Karman <pe...@peknet.com> wrote:
> Marvin Humphrey wrote on 10/28/11 1:09 AM:
>> It may be hard/awkward/impossible to do everything we need with Make. We
>> still have to run the Clownfish compiler from Perl right now, so when we get
>> to that, we'll need a Perl script that we can run from Make.
>
> Is there anything to be gained by using autoconf and friends?
>
> Or asked another way, why would we *not* want to use autoconf and friends?
A couple of Linux developers recently came up with a sample library
designed to show best practices:
http://0pointer.de/blog/projects/libabc.html
They take a strong pro-autoconf stance that I think reflects the
current Linux mainstream:
----------------------------------------------------------------------------
use autotools
- every custom config/makefile build system is worse for everybody
than autotools is
- we are all used to autotools, it works, nobody cares
- it's only two simple files to edit and include in git, which are
well understood by many many people, not just you.
- ignore all crap autotools create in the source tree. never check
the created files into git
- Never, ever, ever install config.h. That's internal to your
sources and is nothing to install.
- And really, anything but autotools is not an option. Just get over
it. Everything else is crack, and it will come back to you if you
choose anything else, sooner or later. Why? think cross
compilation, installation/uninstallation, build root integration,
separate object trees, standard adherence, tarball handling, make
distcheck, portability between distros, ...
------------------------------------------------------------------------------
In the comments, there are a few couple good arguments for CMake as a
more palatable and portable alternative, but I think the authors are
right that we will viewed with considerable suspicion and initial
prejudice by Linux developers if we don't use autoconf for a C
library.
Strangely, I think it's actually permissible if the actual Makefile
calls out to Perl and Charmonizer (and to build Charmonizer), but for
acceptance this should be hidden behind a layer of "configure && make
&& make install".
I'm not sure what the Windows perspective looks like, but I fear it
might not be compatible with this view. Can any of the new additions
to this list offer that perspective? And what works well for OSX?
--nate
Re: [lucy-dev] C implementation [was Re: [lucy-dev] All dependency
licensing issues resolved]
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 10/28/11 1:09 AM:
> Second task: probably build and run Charmonizer. Basically port
> trunk/ruby/Rakefile to the build language of your choice, which was GNU Make
> if I recall correctly. (The same content is in the Perl build, but alongside
> a lot of other stuff, which is why I suggest working off the Ruby build.)
>
> It may be hard/awkward/impossible to do everything we need with Make. We
> still have to run the Clownfish compiler from Perl right now, so when we get
> to that, we'll need a Perl script that we can run from Make.
Is there anything to be gained by using autoconf and friends?
Or asked another way, why would we *not* want to use autoconf and friends?
I realize that it duplicates a lot of what charmonizer does. OTOH, automake can
generate a fully-featured Makefile like Module::Build does for Perl (I know M::B
doesn't create a file called 'Makefile' but the concept is the same).
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] C implementation [was Re: [lucy-dev] All dependency
licensing issues resolved]
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Oct 27, 2011 at 11:26:02PM -0500, Peter Karman wrote:
> /me raises toast
/me quaffs deeply
> With that out of the way, I propose a host language implementation in C to go
> along with the existing Perl implementation. I'm volunteering to lead that
> effort. I think a C implementation can be useful on its own and as a learning
> process for How to Write a Lucy Implementation.
>
> I will happily advocate for a Lucy graduation VOTE once we have another language
> complete.
+1
This will be fun. :) C is an interesting choice for a second language. Lucy
is still designed for OO dynamic languages, and the interface will never feel
exactly like the C from k&r.
> Who's with me?
Huzzah!
First suggestion: start with an svn copy of "trunk/example-lang" to "trunk/c"?
Also, consider screwing up several times to get your commit numbers up,
preferably on line endings so that you get svn blame/credit for every line of
every file after the fix. ;)
Second task: probably build and run Charmonizer. Basically port
trunk/ruby/Rakefile to the build language of your choice, which was GNU Make
if I recall correctly. (The same content is in the Perl build, but alongside
a lot of other stuff, which is why I suggest working off the Ruby build.)
It may be hard/awkward/impossible to do everything we need with Make. We
still have to run the Clownfish compiler from Perl right now, so when we get
to that, we'll need a Perl script that we can run from Make.
Marvin Humphrey
Re: [lucy-dev] C implementation [was Re: [lucy-dev] All dependency
licensing issues resolved]
Posted by Torsten Curdt <tc...@vafer.org>.
> With that out of the way, I propose a host language implementation in C to go
> along with the existing Perl implementation. I'm volunteering to lead that
> effort. I think a C implementation can be useful on its own and as a learning
> process for How to Write a Lucy Implementation.
>
> I will happily advocate for a Lucy graduation VOTE once we have another language
> complete.
>
> Who's with me?
Sounds great!
[lucy-dev] C implementation [was Re: [lucy-dev] All dependency licensing issues
resolved]
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 10/27/11 5:31 PM:
> Greets,
>
> A few hours ago, the existing implementation of the Clownfish parser was
> swapped out for one based on Flex and the Lemon parser generator, eliminating
> Lucy's dependency on the CPAN module Parse::RecDescent.
>
> As of today, the Lucy mainline no longer has any non-core Perl dependencies,
> and all of the licensing and legal issues that needed to be resolved during
> Lucy's incubation have been resolved.
>
awesome. really. great work, Marvin.
/me raises toast
With that out of the way, I propose a host language implementation in C to go
along with the existing Perl implementation. I'm volunteering to lead that
effort. I think a C implementation can be useful on its own and as a learning
process for How to Write a Lucy Implementation.
I will happily advocate for a Lucy graduation VOTE once we have another language
complete.
Who's with me?
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] All dependency licensing issues resolved
Posted by Torsten Curdt <tc...@vafer.org>.
>>> Personally I'd love to see Objective C, but not having an immediate need for it and a severe lack of tuits (not to mention minimal C skillz), I won't be able to work on it. But I'm sure someone will soon.
>>
>> Maybe I can follow along his efforts for the Objective C part.
>> No promises - but might be the missing part for me that is enough to
>> start actually helping.
>
> I realise this has little weight since all I can do is talk about it right now, but I think a vanilla C approach would kill more birds, as you could then use it rather easily in C, C++ and Objective C without further effort. It wouldn't have class and implementation files, but adding those would be a different layer as I understand.
Indeed. That's another option. After all we could then also just wrap
the C stuff up into a ObjC API.
cheers,
Torsten
Re: [lucy-dev] All dependency licensing issues resolved
Posted by "Andrew S. Townley" <as...@atownley.org>.
Hi guys,
On 28 Oct 2011, at 08:38 a.m., Torsten Curdt <tc...@vafer.org> wrote:
>>> ...wouldn't be python or ruby attracting a couple of more folks?
>>
>> Well, we currently have a committer, Brad Harder, who is very interested in a Tcl port and has been working with Marvin on IRC to figure out what's needed. I know, crazy, right? But you take em as you get em, and Brad is pretty awesome.
>
> Wow. OK :)
>
>> So yeah, unless someone else steps up wanting to port to another language with the same level of engagement, it will likely be Tcl.
>>
>> Personally I'd love to see Objective C, but not having an immediate need for it and a severe lack of tuits (not to mention minimal C skillz), I won't be able to work on it. But I'm sure someone will soon.
>
> Maybe I can follow along his efforts for the Objective C part.
> No promises - but might be the missing part for me that is enough to
> start actually helping.
I realise this has little weight since all I can do is talk about it right now, but I think a vanilla C approach would kill more birds, as you could then use it rather easily in C, C++ and Objective C without further effort. It wouldn't have class and implementation files, but adding those would be a different layer as I understand.
My own project hasn't gone near the full text engine for nearly a year, so I haven't been able to make any progress on anything Lucy. :(
Something is likely better than nothing....
Cheers,
ast
Re: [lucy-dev] All dependency licensing issues resolved
Posted by Torsten Curdt <tc...@vafer.org>.
>> ...wouldn't be python or ruby attracting a couple of more folks?
>
> Well, we currently have a committer, Brad Harder, who is very interested in a Tcl port and has been working with Marvin on IRC to figure out what's needed. I know, crazy, right? But you take em as you get em, and Brad is pretty awesome.
Wow. OK :)
> So yeah, unless someone else steps up wanting to port to another language with the same level of engagement, it will likely be Tcl.
>
> Personally I'd love to see Objective C, but not having an immediate need for it and a severe lack of tuits (not to mention minimal C skillz), I won't be able to work on it. But I'm sure someone will soon.
Maybe I can follow along his efforts for the Objective C part.
No promises - but might be the missing part for me that is enough to
start actually helping.
cheers,
Torsten
Re: [lucy-dev] All dependency licensing issues resolved
Posted by "David E. Wheeler" <da...@kineticode.com>.
On Oct 27, 2011, at 6:30 PM, Torsten Curdt wrote:
> Tcl? Not saying that ObjC is the first choice but wouldn't be
> something more... hm.. how do I say it... :)
>
> ...wouldn't be python or ruby attracting a couple of more folks?
Well, we currently have a committer, Brad Harder, who is very interested in a Tcl port and has been working with Marvin on IRC to figure out what's needed. I know, crazy, right? But you take em as you get em, and Brad is pretty awesome.
So yeah, unless someone else steps up wanting to port to another language with the same level of engagement, it will likely be Tcl.
Personally I'd love to see Objective C, but not having an immediate need for it and a severe lack of tuits (not to mention minimal C skillz), I won't be able to work on it. But I'm sure someone will soon.
Best,
David
Re: [lucy-dev] All dependency licensing issues resolved
Posted by Torsten Curdt <tc...@vafer.org>.
> A volunteer for an additional host binding language could begin work at any
> time. Alternatively, you can wait while we continue the process of
> restructuring and refactoring with the goal of making binding easier.
>
> It's my understanding that all of our prospective ObjC volunteers have decided
> to lurk until they don't have to read/write any Perl to achieve their
> objectives, and therefore they are still blocked by
> <https://issues.apache.org/jira/browse/LUCY-142>, "Port Clownfish compiler to
> C". Nevertheless, the Flex/Lemon parser was a subtask of LUCY-142 which just
> happened to kill multiple birds with one stone :) -- so we are making
> progress.
Cool. Thanks for the update!
> Development resources continue to be directed towards porting
> rather than other goals such as speed or search-related features.
>
> After LUCY-142, other plans include...
>
> * Have Charmonizer generate a monolithic C file.
> * Move everything under trunk/core/Lucy/Object under clownfish/. This
> will allow a porter to write bindings for only a dozen or so classes
> before having to tackle bindings for all of Lucy.
> * Add a language other than ObjC, probably Tcl.
Tcl? Not saying that ObjC is the first choice but wouldn't be
something more... hm.. how do I say it... :)
...wouldn't be python or ruby attracting a couple of more folks?
> Each item we check off from that list represents an opportunity to jump in and
> get started.
Naaa, I will also wait until the port is semi-finished (sorry, not a perl guy :)
> Lucy is easy to use. It is not yet easy to hack on, but we know how to change
> that and in time we will succeed.
Looking forward to it!
cheers,
Torsten
Re: [lucy-dev] All dependency licensing issues resolved
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Oct 28, 2011 at 12:42:20AM +0200, Torsten Curdt wrote:
> So when/how can we start with the ObjC support then? ;)
A volunteer for an additional host binding language could begin work at any
time. Alternatively, you can wait while we continue the process of
restructuring and refactoring with the goal of making binding easier.
It's my understanding that all of our prospective ObjC volunteers have decided
to lurk until they don't have to read/write any Perl to achieve their
objectives, and therefore they are still blocked by
<https://issues.apache.org/jira/browse/LUCY-142>, "Port Clownfish compiler to
C". Nevertheless, the Flex/Lemon parser was a subtask of LUCY-142 which just
happened to kill multiple birds with one stone :) -- so we are making
progress. Development resources continue to be directed towards porting
rather than other goals such as speed or search-related features.
After LUCY-142, other plans include...
* Have Charmonizer generate a monolithic C file.
* Move everything under trunk/core/Lucy/Object under clownfish/. This
will allow a porter to write bindings for only a dozen or so classes
before having to tackle bindings for all of Lucy.
* Add a language other than ObjC, probably Tcl.
Each item we check off from that list represents an opportunity to jump in and
get started.
In conclusion, I'd like to reiterate an assertion from a few days ago:
Lucy is easy to use. It is not yet easy to hack on, but we know how to change
that and in time we will succeed.
Marvin Humphrey
Re: [lucy-dev] All dependency licensing issues resolved
Posted by Torsten Curdt <tc...@vafer.org>.
Great news! Congrats!
So when/how can we start with the ObjC support then? ;)
cheers,
Torsten
....and back to lurk mode