[Grok-dev] branches review

[Martijn Faassen]

Hi there,

In the past we've experienced a few times that we had branches which 
existed in limbo for a long time. Let's make sure that doesn't happen a 
lot. I'll catalog the current branches I'm aware of. Creator(s) of the 
branch, please let us know their status and if it's ready for a review> 
What should a reviewer be paying special attention to? Reviewers, please 
volunteer and get these finalized and merged!

faassen-rest - Martijn Faassen
------------------------------

REST support for Grok. Basically allowing GET, PUT, POST and DELETE to 
have custom implementations really easily in special rest protocol 
"skins". Hopefully this can serve as the foundation of various RESTful 
protocol implementations.

I will spend a bit more time with it this week and put it up for review. 
I hope to be able to merge by the end of this week.

gocept.zope3instance-recipe - Philipp von Weitershausen
-------------------------------------------------------

This is an old branch. I assume this can go away as we went the 
eggification route. If that's correct, can you remove this one please, 
Philipp?

gotcha-configuration-actions - Godefroid Chapelle, Philipp
----------------------------------------------------------

Godefroid started this branch, and then Philipp took it over and pushed 
it to a point near to merging. Philipp also already started a separate 
thread about this: excellent! Let's discuss the status of this branch 
over there.

jasper-grokdoctool - Jasper op de Coul, Uli
-------------------------------------------

I'm unclear about the status of this one. Perhaps this branch was 
already merged at the sprint? In this case Jasper or Uli should remove it.

ksmith-mcweekly-boundpagetemplate - Kevin Smith
-----------------------------------------------

Kevin, what is all this about? I know you explained it before, but we 
need a refresher. :)

ksmith_mcweekly-groklets  - Kevin Smith
---------------------------------------

Groklets, a simplified approach to viewlets with Grok.

I think this branch deserves a small design document by Kevin. How does 
this diverge from "standard" viewlets? Is it compatible? How would one 
typically use these? Kevin, could you start a thread on this topic?

ksmith-mcweekly-layers - Kevin Smith
------------------------------------

I think this one got merged, so Kevin, can you remove this branch?

ksmith-mcweekly-viewlets - Kevin Smith
--------------------------------------

An earlier approach to viewlets in Grok. Presumably this is superseded 
by the groklets branch. Is this still needed for reference? If not, can 
you remove it, Kevin?

luciano-tutorial - Luciano
--------------------------

Luciano and others adjusted the tutorial. I started reviewing it, but 
never finalized an actual merge in the trunk. I think this one is 
therefore still waiting for my attention, correct?

neanderthal-startupspeed - Lennart, Joachim Schmitz, Ahmed
----------------------------------------------------------

This work was started at the Neanderthal sprint. Essentially it excludes 
from loading the ZCML that is only there to provide the ZMI. It could 
probably be tweaked and extended. The aim is to gain some speed in startup.

Some points about this branch:

* we exclude ZCML files that other ZCML files want to *include*. That's 
not really an ideal design. It'd be nicer if our target ZCML was 
factored in such a way we didn't need to include the ZMI-specific stuff 
in the first place. I understand that at least in part this work has 
been done.

* this only reaches a 10% increase in startup speed. That's not really 
that much, so maintaining this may not be worth it. We should review 
Jim's response to our discussion on zope3-dev, however.

* some people consider Grok's UI not ready yet to completely replace the 
ZMI, and that we therefore can't really throw things out. We need to 
reach a point where the ZMI is really unnecessary anymore. To do this, 
we need to make a list of what features our UI(s) should have.

Basically this whole branch seems to deserve a discussion topic of its 
own. Please someone start one. :)

philikon-grokcore.component - Philipp
-------------------------------------

Philipp started splitting Grok into independently reusable pieces 
(enabled by Martian). The first piece we split off is anything that is 
fairly purely component architecture oriented. I think this one waits 
for changes to land in the gotcha-configuration-actions branch first, so 
see that discussion.

philikon-reload - Philipp
-------------------------

Code-reload support for Grok. I had the impression that we discovered 
that this approach was fundamentally flawed. If that's correct, is it 
still worth retaining this branch?

regebro-guido-templates - Lennart, Guido Wesdorp
------------------------------------------------

Support for plugging in Genshi and potentially other template languages 
into Grok. I have the impression this branch is quite far along. Is this 
only waiting for a review, or does more work need to be done before we 
can merge this one?

ulif-adminui - Uli
------------------

I'm not sure what the status of this branch is. The admin UI work before 
it got merged into the trunk? In this case the branch can be removed, 
correct?

ulif-i18n - Uli
---------------

i18n support, the Grok way. I have the impression that this one is 
waiting for someone to review it, correct? If so, please start a thread 
describing the basic design so we can finalize this process.

ulif-reference - Uli
--------------------

Not sure about the status of this work. Can this be removed?

ulif-viewinfo - Uli, Martijn, Jasper
------------------------------------

I understood Uli has been removing the admin UI out of the grok core. Is 
this branch then still relevant? Concerning moving the admin UI out of 
the Grok core, I think we need a mail with a plan. Uli, could you write 
up such a plan and post it to a new thread?

I've removed some branches I'm sure could be removed myself. :)

Regards,

Martijn