You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by Daniel Kulp <dk...@apache.org> on 2009/05/05 22:23:16 UTC
How about targetting a "release"?
One of the main things I've seen work successfully in many project to get the
community moving as well as attract new developers/users is to get an actual
release out. There are a lot of people that won't go through the effort of
checking out from svn, building, etc.... They want to see an actual release
to play with.
Thus, my suggestion, would be to set a date for a release (even a "milestone"
release, like a "0.1" version) and see what can be done before then. For
example, maybe target June 30th, see what can be put in before then, and kind
of run with it. Even if it ends up being "not much different" than what is in
SVN right now, it's at least a step forward.
Thoughts?
Are there other ideas that folks have to help get things moving again?
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: How about targetting a "release"?
Posted by David Pollak <fe...@gmail.com>.
Dan,
I think this is a great idea.
Sorry for going dark this week. We've been having a less than optimal
release with one of the projects I'm working on. I'll re-engage next week.
Thank you very much for adding value and thinking about how to help ESME
succeed.
David
On Tue, May 5, 2009 at 1:23 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> One of the main things I've seen work successfully in many project to get
> the
> community moving as well as attract new developers/users is to get an
> actual
> release out. There are a lot of people that won't go through the effort
> of
> checking out from svn, building, etc.... They want to see an actual
> release
> to play with.
>
> Thus, my suggestion, would be to set a date for a release (even a
> "milestone"
> release, like a "0.1" version) and see what can be done before then. For
> example, maybe target June 30th, see what can be put in before then, and
> kind
> of run with it. Even if it ends up being "not much different" than what is
> in
> SVN right now, it's at least a step forward.
>
> Thoughts?
>
> Are there other ideas that folks have to help get things moving again?
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Re: How about targetting a "release"?
Posted by Richard Hirsch <hi...@gmail.com>.
I think it depends on how much work and fundamental change the "code
rewrite" would entail. If there is a lot of changes, then we might need some
sort of a code freeze.
D.
On Mon, May 18, 2009 at 11:39 AM, Anne Kathrine Petteroe
<yo...@gmail.com>wrote:
> My wishlist for a release in June would be:
>
> #52 Add types of authentication besides OpenID
> https://issues.apache.org/jira/browse/ESME-52
>
> #16 Unifying server calls (JSON-related)
> https://issues.apache.org/jira/browse/ESME-16
> # 58 CometActor TagCloud.scala - Conversion to JSON
> https://issues.apache.org/jira/browse/ESME-58
>
> # 60 Change the Scala code to remove HTML from Track functionality
> https://issues.apache.org/jira/browse/ESME-60
> # 61 Change the Scala code to remove HTML for Login functionality
> https://issues.apache.org/jira/browse/ESME-61
> # 62 Change the Scala code to remove HTML for Action functionality
> https://issues.apache.org/jira/browse/ESME-62
> # 63 Change the Scala code to remove HTML for the specific User-related
> https://issues.apache.org/jira/browse/ESME-63
>
> # 59 Better documentation of our existing Scala code
> https://issues.apache.org/jira/browse/ESME-59
>
> And of course the UI.
> But in order for the UI development to move ahead we need the server-side
> developers to remove the HTML in the Scala code first.
>
> My question however is:
> Does it make sense if we need to do a rewrite of the existing code?
> Shouldn't we try to do the rewrite first?
>
> /Anne
>
>
> On 9. mai. 2009, at 10.19, Richard Hirsch wrote:
>
> Let's select a few Jira items that we would like to have and run with them.
>> I think those Jira items that are very specific and relate to detailed
>> functionality would probably be the best idea.
>>
>> Any suggestions for which Jira items to select?
>>
>> D.
>>
>> On Tue, May 5, 2009 at 10:23 PM, Daniel Kulp <dk...@apache.org> wrote:
>>
>>
>>> One of the main things I've seen work successfully in many project to get
>>> the
>>> community moving as well as attract new developers/users is to get an
>>> actual
>>> release out. There are a lot of people that won't go through the
>>> effort
>>> of
>>> checking out from svn, building, etc.... They want to see an actual
>>> release
>>> to play with.
>>>
>>> Thus, my suggestion, would be to set a date for a release (even a
>>> "milestone"
>>> release, like a "0.1" version) and see what can be done before then.
>>> For
>>> example, maybe target June 30th, see what can be put in before then, and
>>> kind
>>> of run with it. Even if it ends up being "not much different" than what
>>> is
>>> in
>>> SVN right now, it's at least a step forward.
>>>
>>> Thoughts?
>>>
>>> Are there other ideas that folks have to help get things moving again?
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://www.dankulp.com/blog
>>>
>>>
>
Re: How about targetting a "release"?
Posted by Anne Kathrine Petteroe <yo...@gmail.com>.
On 18. mai. 2009, at 20.53, Vassil Dichev wrote:
> I've been thinking myself what it would take to release a finished
> version. A release would make it easier for others to try out ESME and
> a release schedule would motivate us to focus on short-term goals.
>
> I could add ESME-53 (Access pools), and the associated feature
> requests 54-57. Access pools are a personal itch, as their absence was
> the main reason a certain micromessaging solution has been rejected in
> a team I've been in. A lot of the server functionality for access
> pools is finished and the work left is mostly related to the UI.
>
> I wasn't fully aware that HTML cleanup from the scala files is
> stopping development of the current UI. If that's the case, I should
> probably put the access pools on hold and focus on this task, so
> others are not blocked by 60-63. Is this the case?
Currently it is a show stopper.
>
>
> As for a rewrite- anything more significant than the HTML/Scala
> refactoring is not at all realistic for a release schedule 1 1/2
> months from now. I would prefer that any rewrite with our current
> resources is incremental, if possible, otherwise it would mean ESME
> development is frozen for months. I have no desire to kill whatever
> inertia ESME has without any visible results at this time. It should
> be possible to focus on areas, which are not affected so much by the
> perceived inelegance of the code base. Remember- for the outside world
> it is important for ESME to deliver, otherwise it's easy to conclude
> ESME development is stalled.
>
> Vassil
Re: How about targetting a "release"?
Posted by David Pollak <fe...@gmail.com>.
I'll pull all the HTML out of the Scala code today/tonight as well as
documenting the files that I change.
Let me also see what I can do about separating the authentication out of the
User class.
On Mon, May 18, 2009 at 3:06 PM, Darren Hague <dh...@fortybeans.com> wrote:
> It's not so much the documentation - with a bit of study, I can work out
> what the code is doing. Where I have trouble is refactoring it from there to
> where I want it to be (with particular reference here to getting the HTML
> out of the .scala files). I think that better, more maintainable code will
> eliminate the need for much documentation.
>
> Maybe we can tempt some of the other Lift guys in here? There is a great
> case for making ESME the poster child for Lift - but that means that the
> codebase must be readable, maintainable and well-commented. As I have said,
> given patterns to work from, I'm happy to do the spade work here. Yes, that
> makes me something of a script kiddie for now, but that (in combination with
> study) is how people learn.
>
> Cheers,
> Darren
>
>
> Anne Kathrine Petteroe wrote:
>
>> Darren,
>>
>> I have felt the missing documentation is a roadblock too, that was the
>> reason why I put Jira task #59 (Better documentation of our existing Scala
>> code) on my wishlist for a release.
>> I've wanted to use ESME to learn Scala/Lift myself, but haven't found our
>> code being much help at all.
>>
>> @David: Is this something you could look at?
>> Not sure how much time you have between now and June 30th?
>>
>> /Anne
>>
>> On 18. mai. 2009, at 21.17, Darren Hague wrote:
>>
>> The outstanding HTML-out-of-Scala-code tickets would be good to address.
>>> I've looked at the Track one, but a couple of hours investigation led me
>>> nowhere. The HTML is just too embedded at the moment. Unlike the Comet
>>> stuff, where the HTML was relatively easy to extract (because of the nature
>>> of Comet), I had no luck with the other stuff, short of wondering how to
>>> initialise a Scala XML node from an HTML file - for which I couldn't find
>>> any example code anywhere.
>>>
>>> Right now, and speaking as someone who's been dabbling in Scala & Lift
>>> for over a year, the ESME codebase is just too hard to work with in many of
>>> the areas I've investigated. Whatever it takes, and however long it takes,
>>> we need to get the codebase into a state where it is understandable and
>>> maintainable, and this is mostly beyond my skills at present. I will buy
>>> the available Lift & Scala books as available to see if this helps, but in
>>> the short term my effectiveness is limited. I'm happy to do pattern-based
>>> work - if someone can show me an example of how something should be done,
>>> and wants a bunch more of it done, then I am happy to pitch in.
>>>
>>> Please note that I am not down on Scala & Lift themselves - I presented
>>> Scala to my team last week, and got some good feedback (to the degree that I
>>> may be allowed to include some Scala in the production code I'm working on)
>>> and I will be presenting Lift in the next few weeks.
>>>
>>> All the best,
>>> Darren
>>>
>>> Vassil Dichev wrote:
>>>
>>>> I've been thinking myself what it would take to release a finished
>>>> version. A release would make it easier for others to try out ESME and
>>>> a release schedule would motivate us to focus on short-term goals.
>>>>
>>>> I could add ESME-53 (Access pools), and the associated feature
>>>> requests 54-57. Access pools are a personal itch, as their absence was
>>>> the main reason a certain micromessaging solution has been rejected in
>>>> a team I've been in. A lot of the server functionality for access
>>>> pools is finished and the work left is mostly related to the UI.
>>>>
>>>> I wasn't fully aware that HTML cleanup from the scala files is
>>>> stopping development of the current UI. If that's the case, I should
>>>> probably put the access pools on hold and focus on this task, so
>>>> others are not blocked by 60-63. Is this the case?
>>>>
>>>> As for a rewrite- anything more significant than the HTML/Scala
>>>> refactoring is not at all realistic for a release schedule 1 1/2
>>>> months from now. I would prefer that any rewrite with our current
>>>> resources is incremental, if possible, otherwise it would mean ESME
>>>> development is frozen for months. I have no desire to kill whatever
>>>> inertia ESME has without any visible results at this time. It should
>>>> be possible to focus on areas, which are not affected so much by the
>>>> perceived inelegance of the code base. Remember- for the outside world
>>>> it is important for ESME to deliver, otherwise it's easy to conclude
>>>> ESME development is stalled.
>>>>
>>>> Vassil
>>>>
>>>>
>>>
>>
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Re: How about targetting a "release"?
Posted by Darren Hague <dh...@fortybeans.com>.
It's not so much the documentation - with a bit of study, I can work out
what the code is doing. Where I have trouble is refactoring it from
there to where I want it to be (with particular reference here to
getting the HTML out of the .scala files). I think that better, more
maintainable code will eliminate the need for much documentation.
Maybe we can tempt some of the other Lift guys in here? There is a great
case for making ESME the poster child for Lift - but that means that the
codebase must be readable, maintainable and well-commented. As I have
said, given patterns to work from, I'm happy to do the spade work here.
Yes, that makes me something of a script kiddie for now, but that (in
combination with study) is how people learn.
Cheers,
Darren
Anne Kathrine Petteroe wrote:
> Darren,
>
> I have felt the missing documentation is a roadblock too, that was the
> reason why I put Jira task #59 (Better documentation of our existing
> Scala code) on my wishlist for a release.
> I've wanted to use ESME to learn Scala/Lift myself, but haven't found
> our code being much help at all.
>
> @David: Is this something you could look at?
> Not sure how much time you have between now and June 30th?
>
> /Anne
>
> On 18. mai. 2009, at 21.17, Darren Hague wrote:
>
>> The outstanding HTML-out-of-Scala-code tickets would be good to
>> address. I've looked at the Track one, but a couple of hours
>> investigation led me nowhere. The HTML is just too embedded at the
>> moment. Unlike the Comet stuff, where the HTML was relatively easy
>> to extract (because of the nature of Comet), I had no luck with the
>> other stuff, short of wondering how to initialise a Scala XML node
>> from an HTML file - for which I couldn't find any example code anywhere.
>>
>> Right now, and speaking as someone who's been dabbling in Scala &
>> Lift for over a year, the ESME codebase is just too hard to work with
>> in many of the areas I've investigated. Whatever it takes, and
>> however long it takes, we need to get the codebase into a state where
>> it is understandable and maintainable, and this is mostly beyond my
>> skills at present. I will buy the available Lift & Scala books as
>> available to see if this helps, but in the short term my
>> effectiveness is limited. I'm happy to do pattern-based work - if
>> someone can show me an example of how something should be done, and
>> wants a bunch more of it done, then I am happy to pitch in.
>>
>> Please note that I am not down on Scala & Lift themselves - I
>> presented Scala to my team last week, and got some good feedback (to
>> the degree that I may be allowed to include some Scala in the
>> production code I'm working on) and I will be presenting Lift in the
>> next few weeks.
>>
>> All the best,
>> Darren
>>
>> Vassil Dichev wrote:
>>> I've been thinking myself what it would take to release a finished
>>> version. A release would make it easier for others to try out ESME and
>>> a release schedule would motivate us to focus on short-term goals.
>>>
>>> I could add ESME-53 (Access pools), and the associated feature
>>> requests 54-57. Access pools are a personal itch, as their absence was
>>> the main reason a certain micromessaging solution has been rejected in
>>> a team I've been in. A lot of the server functionality for access
>>> pools is finished and the work left is mostly related to the UI.
>>>
>>> I wasn't fully aware that HTML cleanup from the scala files is
>>> stopping development of the current UI. If that's the case, I should
>>> probably put the access pools on hold and focus on this task, so
>>> others are not blocked by 60-63. Is this the case?
>>>
>>> As for a rewrite- anything more significant than the HTML/Scala
>>> refactoring is not at all realistic for a release schedule 1 1/2
>>> months from now. I would prefer that any rewrite with our current
>>> resources is incremental, if possible, otherwise it would mean ESME
>>> development is frozen for months. I have no desire to kill whatever
>>> inertia ESME has without any visible results at this time. It should
>>> be possible to focus on areas, which are not affected so much by the
>>> perceived inelegance of the code base. Remember- for the outside world
>>> it is important for ESME to deliver, otherwise it's easy to conclude
>>> ESME development is stalled.
>>>
>>> Vassil
>>>
>>
>
Re: How about targetting a "release"?
Posted by Anne Kathrine Petteroe <yo...@gmail.com>.
Darren,
I have felt the missing documentation is a roadblock too, that was the
reason why I put Jira task #59 (Better documentation of our existing
Scala code) on my wishlist for a release.
I've wanted to use ESME to learn Scala/Lift myself, but haven't found
our code being much help at all.
@David: Is this something you could look at?
Not sure how much time you have between now and June 30th?
/Anne
On 18. mai. 2009, at 21.17, Darren Hague wrote:
> The outstanding HTML-out-of-Scala-code tickets would be good to
> address. I've looked at the Track one, but a couple of hours
> investigation led me nowhere. The HTML is just too embedded at the
> moment. Unlike the Comet stuff, where the HTML was relatively easy
> to extract (because of the nature of Comet), I had no luck with the
> other stuff, short of wondering how to initialise a Scala XML node
> from an HTML file - for which I couldn't find any example code
> anywhere.
>
> Right now, and speaking as someone who's been dabbling in Scala &
> Lift for over a year, the ESME codebase is just too hard to work
> with in many of the areas I've investigated. Whatever it takes, and
> however long it takes, we need to get the codebase into a state
> where it is understandable and maintainable, and this is mostly
> beyond my skills at present. I will buy the available Lift & Scala
> books as available to see if this helps, but in the short term my
> effectiveness is limited. I'm happy to do pattern-based work - if
> someone can show me an example of how something should be done, and
> wants a bunch more of it done, then I am happy to pitch in.
>
> Please note that I am not down on Scala & Lift themselves - I
> presented Scala to my team last week, and got some good feedback (to
> the degree that I may be allowed to include some Scala in the
> production code I'm working on) and I will be presenting Lift in the
> next few weeks.
>
> All the best,
> Darren
>
> Vassil Dichev wrote:
>> I've been thinking myself what it would take to release a finished
>> version. A release would make it easier for others to try out ESME
>> and
>> a release schedule would motivate us to focus on short-term goals.
>>
>> I could add ESME-53 (Access pools), and the associated feature
>> requests 54-57. Access pools are a personal itch, as their absence
>> was
>> the main reason a certain micromessaging solution has been rejected
>> in
>> a team I've been in. A lot of the server functionality for access
>> pools is finished and the work left is mostly related to the UI.
>>
>> I wasn't fully aware that HTML cleanup from the scala files is
>> stopping development of the current UI. If that's the case, I should
>> probably put the access pools on hold and focus on this task, so
>> others are not blocked by 60-63. Is this the case?
>>
>> As for a rewrite- anything more significant than the HTML/Scala
>> refactoring is not at all realistic for a release schedule 1 1/2
>> months from now. I would prefer that any rewrite with our current
>> resources is incremental, if possible, otherwise it would mean ESME
>> development is frozen for months. I have no desire to kill whatever
>> inertia ESME has without any visible results at this time. It should
>> be possible to focus on areas, which are not affected so much by the
>> perceived inelegance of the code base. Remember- for the outside
>> world
>> it is important for ESME to deliver, otherwise it's easy to conclude
>> ESME development is stalled.
>>
>> Vassil
>>
>
Re: How about targetting a "release"?
Posted by Darren Hague <dh...@fortybeans.com>.
The outstanding HTML-out-of-Scala-code tickets would be good to address.
I've looked at the Track one, but a couple of hours investigation led me
nowhere. The HTML is just too embedded at the moment. Unlike the Comet
stuff, where the HTML was relatively easy to extract (because of the
nature of Comet), I had no luck with the other stuff, short of wondering
how to initialise a Scala XML node from an HTML file - for which I
couldn't find any example code anywhere.
Right now, and speaking as someone who's been dabbling in Scala & Lift
for over a year, the ESME codebase is just too hard to work with in many
of the areas I've investigated. Whatever it takes, and however long it
takes, we need to get the codebase into a state where it is
understandable and maintainable, and this is mostly beyond my skills at
present. I will buy the available Lift & Scala books as available to
see if this helps, but in the short term my effectiveness is limited.
I'm happy to do pattern-based work - if someone can show me an example
of how something should be done, and wants a bunch more of it done, then
I am happy to pitch in.
Please note that I am not down on Scala & Lift themselves - I presented
Scala to my team last week, and got some good feedback (to the degree
that I may be allowed to include some Scala in the production code I'm
working on) and I will be presenting Lift in the next few weeks.
All the best,
Darren
Vassil Dichev wrote:
> I've been thinking myself what it would take to release a finished
> version. A release would make it easier for others to try out ESME and
> a release schedule would motivate us to focus on short-term goals.
>
> I could add ESME-53 (Access pools), and the associated feature
> requests 54-57. Access pools are a personal itch, as their absence was
> the main reason a certain micromessaging solution has been rejected in
> a team I've been in. A lot of the server functionality for access
> pools is finished and the work left is mostly related to the UI.
>
> I wasn't fully aware that HTML cleanup from the scala files is
> stopping development of the current UI. If that's the case, I should
> probably put the access pools on hold and focus on this task, so
> others are not blocked by 60-63. Is this the case?
>
> As for a rewrite- anything more significant than the HTML/Scala
> refactoring is not at all realistic for a release schedule 1 1/2
> months from now. I would prefer that any rewrite with our current
> resources is incremental, if possible, otherwise it would mean ESME
> development is frozen for months. I have no desire to kill whatever
> inertia ESME has without any visible results at this time. It should
> be possible to focus on areas, which are not affected so much by the
> perceived inelegance of the code base. Remember- for the outside world
> it is important for ESME to deliver, otherwise it's easy to conclude
> ESME development is stalled.
>
> Vassil
>
Re: How about targetting a "release"?
Posted by Vassil Dichev <vd...@apache.org>.
I've been thinking myself what it would take to release a finished
version. A release would make it easier for others to try out ESME and
a release schedule would motivate us to focus on short-term goals.
I could add ESME-53 (Access pools), and the associated feature
requests 54-57. Access pools are a personal itch, as their absence was
the main reason a certain micromessaging solution has been rejected in
a team I've been in. A lot of the server functionality for access
pools is finished and the work left is mostly related to the UI.
I wasn't fully aware that HTML cleanup from the scala files is
stopping development of the current UI. If that's the case, I should
probably put the access pools on hold and focus on this task, so
others are not blocked by 60-63. Is this the case?
As for a rewrite- anything more significant than the HTML/Scala
refactoring is not at all realistic for a release schedule 1 1/2
months from now. I would prefer that any rewrite with our current
resources is incremental, if possible, otherwise it would mean ESME
development is frozen for months. I have no desire to kill whatever
inertia ESME has without any visible results at this time. It should
be possible to focus on areas, which are not affected so much by the
perceived inelegance of the code base. Remember- for the outside world
it is important for ESME to deliver, otherwise it's easy to conclude
ESME development is stalled.
Vassil
Re: How about targetting a "release"?
Posted by Anne Kathrine Petteroe <yo...@gmail.com>.
My wishlist for a release in June would be:
#52 Add types of authentication besides OpenID
https://issues.apache.org/jira/browse/ESME-52
#16 Unifying server calls (JSON-related)
https://issues.apache.org/jira/browse/ESME-16
# 58 CometActor TagCloud.scala - Conversion to JSON
https://issues.apache.org/jira/browse/ESME-58
# 60 Change the Scala code to remove HTML from Track functionality
https://issues.apache.org/jira/browse/ESME-60
# 61 Change the Scala code to remove HTML for Login functionality
https://issues.apache.org/jira/browse/ESME-61
# 62 Change the Scala code to remove HTML for Action functionality
https://issues.apache.org/jira/browse/ESME-62
# 63 Change the Scala code to remove HTML for the specific User-related
https://issues.apache.org/jira/browse/ESME-63
# 59 Better documentation of our existing Scala code
https://issues.apache.org/jira/browse/ESME-59
And of course the UI.
But in order for the UI development to move ahead we need the server-
side developers to remove the HTML in the Scala code first.
My question however is:
Does it make sense if we need to do a rewrite of the existing code?
Shouldn't we try to do the rewrite first?
/Anne
On 9. mai. 2009, at 10.19, Richard Hirsch wrote:
> Let's select a few Jira items that we would like to have and run
> with them.
> I think those Jira items that are very specific and relate to detailed
> functionality would probably be the best idea.
>
> Any suggestions for which Jira items to select?
>
> D.
>
> On Tue, May 5, 2009 at 10:23 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>>
>> One of the main things I've seen work successfully in many project
>> to get
>> the
>> community moving as well as attract new developers/users is to get an
>> actual
>> release out. There are a lot of people that won't go through the
>> effort
>> of
>> checking out from svn, building, etc.... They want to see an actual
>> release
>> to play with.
>>
>> Thus, my suggestion, would be to set a date for a release (even a
>> "milestone"
>> release, like a "0.1" version) and see what can be done before
>> then. For
>> example, maybe target June 30th, see what can be put in before
>> then, and
>> kind
>> of run with it. Even if it ends up being "not much different" than
>> what is
>> in
>> SVN right now, it's at least a step forward.
>>
>> Thoughts?
>>
>> Are there other ideas that folks have to help get things moving
>> again?
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
Re: How about targetting a "release"?
Posted by Richard Hirsch <hi...@gmail.com>.
Let's select a few Jira items that we would like to have and run with them.
I think those Jira items that are very specific and relate to detailed
functionality would probably be the best idea.
Any suggestions for which Jira items to select?
D.
On Tue, May 5, 2009 at 10:23 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> One of the main things I've seen work successfully in many project to get
> the
> community moving as well as attract new developers/users is to get an
> actual
> release out. There are a lot of people that won't go through the effort
> of
> checking out from svn, building, etc.... They want to see an actual
> release
> to play with.
>
> Thus, my suggestion, would be to set a date for a release (even a
> "milestone"
> release, like a "0.1" version) and see what can be done before then. For
> example, maybe target June 30th, see what can be put in before then, and
> kind
> of run with it. Even if it ends up being "not much different" than what is
> in
> SVN right now, it's at least a step forward.
>
> Thoughts?
>
> Are there other ideas that folks have to help get things moving again?
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>