New Cows

Last day of sprinting. I had the idea most people were at least somewhat tired by now. I know I am.

We started the day with sprinter group reports (again, I hope I do not forget something here..):

Jan-Jaap kept an eye on the build slaves for Grok during our release preparations. This revealed a last minute bug in test cases of grokcore.view on Windows. Of course someone left filesystem path comparisons in the tests that could not work on Windows (hint: it was me…). So with a fast bugfix release of that we had all green flags and we were good to go for the 1.0b2.

Leonardo explored various aproaches to creating new grok projects without having to be online. Grokproject tries to do that, but it is not yet ideal. Maybe there're better eays of achieving this.

Sacha had been working on creating an Ubuntu Live-CD with one of more Grok applications installed on it to really have an "out-of-the-box" experience for people who want to give Grok a try.

Timo finished the migration of http://grok.zope.org to a more recent version of Plone. Great! It probably took him longer that he had hoped, but we're very glad he picked up this ball!

Sylvain had been working on porting five.grok and a lot of related packages to 1.0b2. It proofed not be that diffcult.

The documentation team gathered notes and remarks on the various tutorials and other documentation about using Grok. They are encouraged to send these notes to the Grok documentation mailinglist so that this useful work is not forgotten. It also makes for a nice "deliverable" for yourself to be able to share what you've been working on with others.

Vincent had been working the rdb integration libaries for Grok. There were late-night :-) checkins of an rdbexample application for Grok to demonstrate how this works. But he worked on megrok.z3cform and grokui.admin and a lot more packages too!

Souheil too worked on the grokui.admin package and made good progress for making this UI pluggable! He also updated megrok.*` packages to work with 1.0b2.

Martijn and I continued on grokcore.view and later split up: Martijn worked with on the rdb libraries and the ZTK and together with Jan-Jaap I explored how an integration of z3c.hashedresource and hurry.resource and grok.DirectoryResource could look like.

So, that was it. Now we're off to dinner somewhere in the city center of Köln and tomorrow will have early breakfast with whoever is still around.

Thank you all for a very productive sprint! See you next time, hopefully soon!

Let's also not forget to thank Alroldo and Novareto for organizing this sprint - that's always a lot of work. Thank you!!

now playing: "We will grok you" - Queen

Today we released 1.0b2. Yeah!

It took a while, but we're happy with this beta. The final 1.0 will most probably be almost identical.

But we're working on post-1.0 Grok already and there's lots of plans:

Martijn and I got grokcore.view to work with the latest martian. Next will be grokcore.viewlet and grokcore.formlib. This should be relatively straightforward.

There's also a branch of grokcore.view that improves the registry of templates that can be associated with views. Merging the registry code itself is not too diffcult. However, there's one complication: we need to make sure all templates are registered before we can actually grok the views that might associated them.

Grokkers can have a specific order, but this is the order in which the grokkers grok one module. The order in which the modules are handled is not determined.This is problem when view components in, say, module A subclass from view components in module B. The templates that get associated to the view components in B will probably not have been registered yet at the moment of grokking module A.

This needs to be solved obviously. Hopefully tomorrow.

And there're more plans still:

• Consider how the megrok.layout extension might become a core feature.
• Consider how the combination of hurry.resource and grok.DirectoryResource and something like z3c.hashedresource can be combined in one convience Grok extension. Or maybe even also be a core feature.
• Using the ZTK as a basis.
• Proper Python 2.6 support.
• Fixing more issues.

As always a sprint builds up lots of momentum rather quickly. We need to find a way to keep this momentum to a certain extend in between sprints. One way could maybe be to actually have more sprints.

I can imagine trying to organize smaller, very much focussed sprints on a more regular basis. Many of the Grok developers are really not that far away from eachother. Hopefully we can manage to do that.

But there's one more day of sprinting left still! Now that the release is out the door, we should get some "real" development done again :-)

We have a plan.

Today started with short reports by the sprinting groups. The things I can recall right now - I'm sorry if I forget something:

Jan-Jaap and Hanno worked on getting quite a number of buildslaves running on a buildbot dedidacted to having the ZTK, Grok and lots of related packages tested on multiple platforms on multiple versions of Python. Leonardo and Jan-Jaap then started on trying to get more "green lights" there…

Leonardo also has helped Martijn and me to get the release of Grok in good shape - more on that later. On monday Hanno and Christian Theune worked mainly on the official ZTK, making good progress there. Hopefully Grok can start to use the ZTK in the not too distant future.

Timo has been working hard on the rather thankless job of upgrading the http://grok.zope.org/ site to a newer version of Plone. Others have been working on reviewing and improving the "unofficial" documentation found there and where possible trying to promote documentation to the "official" documentation that is maintained along with Grok itself in SVN.

Uli and Christian Klinger and Sylvain and Vincent have been working on splitting the introspecter code off from grokui.admin in order to make that lighter weight. The introspector should come back as some extension to the admin view at some point - that code should not be forgotten. There're more ideas for admin view extensions like local utility configuration user interfaces and introspectors for locally granted roles and permissions.

They've also been working through the implications imposed by the infamous grok.CodeView split. Which brings me to, well, that topic again :-)

After a good nights sleep we decided to revert the split.

So there, grokcore.view will no longer have a CodeView - it was a mistake. grokcore.viewlet and grokcore.formlib and other packages need to be fixed - again - now. That may seem like a waste of effort, but most people felt this was really the right decision. Grok itself is mostly fixed already, so tomorrow Grok 1.0b2 is being released. And very short after that we will release 1.0.

Later in the afternoon we went to Bonn and vistited Ludwig von Beethoven's birthplace. We made life difficult for a nice waitress in the local noodlesbar. The food was good! But the cashregister broke down - so finding out who had to pay what turned into chaos…

Oh, right and I promised some pictures too!

Us busy sprinting at the GfU:

Beethoven's birtplace:

now playing: "I want to Grok you like an animal" - NiN

"General complexity is better than specific complexity"

Today's plan was to finish of the release we started yesterday. But we found some complications.

Martijn and I also started on finally making the Grok and the grokcore.* family work with the latest martian release. That release has fixed the long standing issues with module-level directives and inheritance.

We started with grokcore.component. The idea being that if we can this one to work, the others might not be that complicated anymore. And things fell in place quite well! grokcore.component lost some specific complexity as it used to implement its own idea of finding a context object (used by the adapter and utility grokkers), but it now relies on the general strategy in martian for it.

Another conclusion is that, if you write your own directives, in their implementation they are not allowed to use other directives for retrieving information. Since the directives work on import-time, you can quite easily get trapped in what effectively is an circular import. So that has been fixed in grokcore.component as well now. Tests pass. Yeah!

But no finished release still…

During the day we found lots of issues surrounding the recent split of grok.View and grok.CodeView. Now that the first beta was kinda out there, people actually started using grok.CodeView and wondered why the split actually happened. It didn't seem all that usefull especially as it turned out that there were some bugs to be fixed and more splitting off needed to happen (the grok.Viewlet actually needs a grok.CodeViewlet to keep things symetrical for example).

At the same time, since good progress was made on making grokcore.component compatible with latest martian, Martijn and I were in doubt whether the original technical reasons for having the split are actually still all that significant.

So, no next beta. And heavy discussions back and forth.

Tomorrow will try to find out whether it really isn't safer to not release Grok with the CodeView split off at all and having it to maybe later introduce it in a next feature release, versus now releasing a big API change with 1.0 only to have it maybe reverted later on…

We'll start off tomorrow with a report by all the sprinter groups - lots of useful things are happening. In the afternoon we're heading for a city trip in Bonn.

Like every sprint we started of with introductions and setting the agenda

Main important issue: getting one dot oh out of the door. At the very a least a first beta. Together with Leonardo and Martijn we aimed for a release at the end of the day. Unfortunately we didn't completely succeed.

Although the 1.0b1 is tagged and already on the package index, we decided to not let it be picked up by projects created by grokproject just yet.

The two things we need to resolve tomorrow morning before we can do that are:

1. z3c.recipe.eggbasket needs to be updated to work with latest zc.buildout in order to make a new "bundle" (a tarball containing not only grok itself, but also all of its dependencies) of the release. The bundlemaker command line throws an error since some API internal to zc.buildout has changed.
2. the buildout.cfg created by the about-to-be-released grokproject will make use of a different recipe for creating the Data.fs and its containing subdirectory var/filestorage. Of course we need to double, no triple check that projects that update their buildout.cfg to look like the ones grokproject will create do not accidentally loose their Data.fs, because of buildout throwing away everything in the parts subdirectory. This is mainly a documentation issue, but still.

We had a dinner at a typical German brauhaus and generally had a very nice day. Even though the goals were not completely met, it felt productive. Now it is time to go to sleep. You never know what people expect early results from us… :-)