[Gsoc] Project List

[Martijn Faassen]

Hey Stephan,

On 3/29/07, Stephan Richter <srichter at cosmos.phy.tufts.edu> wrote:
> I just checked the project list and I think having 2 Grok projects in the top3
> is a bit excessive. I think Grok serves a part of the Zope 3 community, but
> so much as to warrant 2 projects. I think this is the new kid on the block
> effect.

Probably true.

> Further, I would be really disturbed, if Paul does not get one of his proposed
> projects (I really do not care which one). Of all the candidates, Paul has
> the most promise to become a long-term committer and advocat of Zope 3. He is
> also extremely smart, so he can produce very well-thought-out code.

I agree that Paul should get a project.

> Okay, now that I write a mail to the list I can address some comments on the
> ZCML proposal.
>
> Martijn, I did the measurements last year already (when I applied for the
> project), and I know that converting the XML strings via schemas to Python
> values is about 50% of the startup time. Pickles, on the other hand, are
> quickly read, so I think the overall gain would be about 50%. For example, if
> Zope takes 4 seconds to start now, it would take 2 seconds after the
> improvements. I think that wildly! improves programming comfort. I would have
> never applied or suggested the project if I would have not known the numbers.

I realize that the suggestion to optimize ZCML would not have been
made if you weren't aware it was taking part of the startup time.

> As for switching to Python actions for configuration, I think this is worthy
> thinking about. However, I think this particular problem has a wide scope and
> takes a lot of work, more than what I would expect of a student during a GSoC
> project. Also, the method of attack has not been fully thought out, adding to
> the risk. If someone else would commit serious time to help Paul here, not
> only with design but also

Sentence appears to be cut off here. I have confidence in Paul, and
you as a mentor, in this. This isn't a project that has to be done in
a couple of days, after all. You have a bit of time to step back and
think through methods of attack.

I think the project should include:

* doing some more measurement. Besides doublechecking your result in a
difficult area (not that I doubt that your result isn't in the right
ballpark!), this will help Paul analyze whether his own efforts have
any effect.

* investigate *other* areas in which startup time can be improved.
What if Paul managed to speed up ZCML and is now twiddling his thumbs?
I'd prefer the project to be "speed up Zope 3 startup time, and by the
way, we know ZCML is slow so we're going to pay lots of attention to
this first" as opposed to "hey, Paul, we have this implementation
strategy for ZCML speeding up worked out, you just build it". Better
for Paul, better for everyone. I'm not saying Paul will manage to
actually optimize anything but ZCML, I'm just saying we shouldn't
exclude this from the start. The goal is startup time, not pickling
ZCML. That's a proposed solution.

* Just speaking as one stakeholder here from the perspective of Grok:
As to pickling ZCML to speed up startup time, I'd really appreciate it
if we couldn't explore some options that would benefit Grok as well,
besides just startup time. We're messing about with the ZCML machinery
anyway, so it's be a shame not to at least consider things. Perhaps
instead of pickling ZCML we can have some Python action generation
layer and make ZCML use that. Then we pickle that. I'm handwaving
here, and perhaps I'm wrong or you're already looking this direction
anyway. I'm just speaking as a stakeholder. That doesn't mean that
Grok's concerns should change everything, it just means that I'd like
the design to be affected by this. So instead of telling Paul right
away "Paul, use this design to solve the problem" we instead say
"Paul, we have some ideas in this direction, and these are the goals
and these are stakeholders, what can we come up with?"

All this has much to do with the scope of the summer of code project.
Right now, because you already did the research and have the design in
your head, it's very concrete. You give the impression that you think
the project is risky enough not to widen the scope. You can evaluate
this better than I can, but it surprises me a little.

I hope that as a mentor you can step back with Paul for a bit and
consider possible alternative strategies to reach the same *goal*,
which is increased startup time for Zope 3. This includes repeating
some of the research and considering alternate designs. I think this
is a better learning experience for Paul too: software development is
not just implementation, it's also a weighing of concerns.

Probably all of this is fairly obvious anyway and you would've done
this anyway when the project starts, but I just figured I'd spell out
my comments.

Regards,

Martijn