[Grok-dev] grok 1.0: what needs doing?

[Jan-Wijbrand Kolman]

Reinout van Rees wrote:
> Especially for the grok sprint at Europython: what work needs doing for 1.0?
> Is any of that suitable sprint material? 
> 
> The 1.0 milestone bugs are at https://bugs.launchpad.net/grok/+milestone/1.0
> Is that list up to date? Does all of it need doing for 1.0? Just the
> critical/high items? Etc.

Good questions and good timing; I was about to post the following:


A couple of days ago Martijn and I had a discussion about Grok-1.0 over 
pizza. Besides the bugs listed in launchpad, there's two main topics for 1.0

1) The grok.template() directive inheritance bug.

2) Windows installation support.


On the second topic I cannot say too much. There's a team working on 
this and personally I think our Windows story should quite good before 
we call 1.0. In my opinion quite good means: either Grok installs fine 
in most situations on Windows and/or has a collection of documentation 
describing how to install Grok on Windows and how to avoid common pitfalls.

Windows-team; what's the status?


The grok.template() directive inheritance bug has been identified and 
martian has seen updates that principly allow us to fix the bug. 
However, it still is quite some work.

One of the implication though was to introduce another view-like 
component called CodeView. This view-like component does not have a 
template associated but is supposed to have a render() method. At the 
same time the current View component will drop support for the render() 
method. This will make reasoning about what grok.template() on what 
class in a class hierarchy is used versus what render() method is used 
much simpler.

Martijn and I thought of the following:

Since 1.0 is getting somewhat long in tooth now, let implement the 
CodeView component and indeed drop the render() method support on 
regular View componenta just before 1.0. That way we will not have a big 
API change after 1.0 when we solve the grok.template() inheritance bug.

Implementing the CodeView component should be relatively straightforward 
and indeed could be a good sprint topic. I do hope to get to it even 
before that though. And I also hope there will be some interest amongst 
the sprinters to look into the buglist and fix/reviews the outstanding 
issues... That would be soooo great to see happening! :-)


Let's aim for a 1.0 just after the sprint - ME GROK WANT RELEASED!


regards,
jw