esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anne Kathrine Petteroe <>
Subject Re: How about targetting a "release"?
Date Mon, 18 May 2009 09:39:05 GMT
My wishlist for a release in June would be:

#52 Add types of authentication besides OpenID

#16  Unifying server calls (JSON-related)
# 58 CometActor TagCloud.scala - Conversion to JSON

# 60 Change the Scala code to remove HTML from Track functionality
# 61 Change the Scala code to remove HTML for Login functionality
# 62 Change the Scala code to remove HTML for Action functionality
# 63 Change the Scala code to remove HTML for the specific User-related

# 59 Better documentation of our existing Scala code

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?


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

View raw message