Archive for August, 2009

A word about version number in packaging / release with pypi

Posted in plone, python on August 17, 2009 by toutpt

I often see lots of information about version number on release. I would like to explain it. For sure their is lots of different use case but here, I speak about a code you are writing and want to package.

For me there are 4 parts:

  • Major version number
  • Feature version indice
  • Current level of release
  • Status of the release

Major version number is about layout or about backward compatibility. When you change that number it means you have totaly change most of things or you have broke the layout because you have done a big mistake and you don’t have other choice. For example Zope 2.X.X and Zope 3.X.X.

Feature version indice is all about features. For me this number is increased when you have added feature(s). For example adding undo/redo to the software.

Current level of release is all about bug fixes. For example an i18n broken reported by someone.

The status is a character or a work like beta, rc, … and is all about release status. The order is:

  • alpha (a) often means only for developers, first calls for testing (try to install)
  • beta (b) often it is used to call for testing (install and use it)
  • candidate (c or rc) means no more bugs reported just about packaging and last call for testing

I m sure there are some formals paper around Internet that explains this a lot better, but I was just wanting to explain my point of view.

Advertisements

Monkey ! When patching can’t be merged: experimental.aggressiveopaquespeedup

Posted in plone, zope on August 12, 2009 by toutpt

Next to my first plone patch that improve performance I have profiling the code on a simple query: get a javascript from portal_javascript already computed.

The result is clear: 28% of the time is spent in opaqueitems. So I have discuss about it on CMF mailing list.

A monkey patch was already existing: experimental.opaquespeedup. I have read the code. It replace the time consuming calls on all attributes by a catalog request. But I know that catalog can be slow if the web site has lots of contents. I have decided to make something more aggressive, by just removing opaqueitems that seems to be not used.

So use it at your own risk: experimental.aggressiveopaquespeedup

My first patch ! Improve performance of Plone.

Posted in plone on August 12, 2009 by toutpt

I m proud of it, so I want to blog about it. Let me tell you the story of my first patch on Plone.

Two students from ‘Ecole polytechnique de l université de Nantes‘ has worked for me during 6 month. They have discover so much technologies:

  • Python
  • Zope
  • Plone
  • JMeter

Their subject was : “Just improve authentication performance of Plone”. They do not have succeed in doing this, but they has showed me some graphics where i have found a performance issue: the user properties. So i have kept Nasreddine BERCHIDA for the summer to continue on this. Thuesday 7 July, he has found that enumerateUsers from PlonePas.plugins.property was the source code that matters.

We have done a report with funkload with lots of users and got it: lots of green means performance improved.

The patch is about to be merged (I hope).

References:
mailing list discussion
bug tracker ticket (need a plone.org account)