When a customer has installed 25 extra products and wants me to migrate his site, I want to be able to give him a good idea of how hard that is going to be, how much trouble, without needing to be convincing. Do the products have tests? Is there good test coverage?

On pypi you can see how many times a package has been downloaded. Gives an indication.

I want at least some automatic information, like number of tests, coverage.

It takes about one or two hours per package to configure a buildbot. You can grab statistics from that. Maybe automatically run pyflakes and pep8 tests.

Each package has an owner.

We can calculate a value for a package, like lines of code times the coverage. Can be touchy.

Perhaps create a directory buildbot in the collective, where people can put buildout config files for their packages.

It is better to have a src directory in a package instead of having the code next to the setup.py file.

Add automatically collected information to PloneSoftwareCenter.

Could be tricky to prevent someone uploading code to the collective that is then executed by the buildbot and for instance starts sending spam.

Show translation coverage.

We should not do rating (yet).

Look at the pylint package.

You can make pyflakes less complaining.

pep8 and pyflakes tests could be optional.

Action points, we can sprint on this:

• get buildbot infrastructure
• add fields to PSC for code coverage, and number of tests; could be annotations
• POST request for writing the info there from the buildbot
• scripts to parse the buildbot output and post the info

Plone 3.3 had about 6 months of prereleases. Very little testing and feedback coming in, very late. Shouting "Please test!" did not help. If companies were using prereleases and it was working fine you only heard it when you explicitly asked it.

Several browser tests are missing, like for collections, which is why they were broken for two releases. Also Selenium tests.

Hanno was looking at all the bugs, reassigning them. Very useful, but too much for one single person.

Another task would be specifically testing just before or after a release.

Having data about how many times the versions.cfg of a release candidate is downloaded would be handy. Getting no negative feedback but also no positive feedback is not good. Are there no problems or is no-one using it.

Having a list of things to do before a release is handy.

Testing a release candidate during the Plone TuneUps is good. Make some noise about that.

InstallFest: get people to try out the installers and be available on irc for support.

http://pypi.python.org/pypi/mr.ripley: replay the requests of a live site on a staging server.

Idea: button "Ready for Plone 4" for third party products on plone.org?

Buildbots for the most popular third party products?

Important things to do:

1. Triaging bugs.
2. Get people to test releases.

Tell Joanna when a new release is coming up so we could use testers in the Plone TuneUp.

Get a list of which things to change when a new release is there, like also the topic of the #plone irc channel.

Test coverage runs for packages are interesting as well.

Each zeo client has its own object cache. If you have an 8 GB Data.fs in the zeo server, 16 GB memory, and 8 zeo clients, then the clients each have only 2 GB memory available. If something is needed that is outside the cache you need to access the disk, which is bad.

The bfg folks made something where you have to explicitly mark an object for writing; so objects that are just for reading can be shared between clients.

You can use the multiprocess package.

You can cache calculated results with memoize. Is then stored in every zeoclient. memoize is ready to switch to memcached so you can share the memoized data between the clients.

I am a developer, physicist, author, working for Free Software Foundation Europe.

"Politics is a process by which groups of people make decisions." (http://en.wikipedia.org/wiki/Politics) Decisions about how to spend money, do we relicense software, anything.

"Everything is politics" (Thomas Mann).

The Plone Foundation has Relicensed some of the software this year. You managed to boil that down to a majority vote. Plone could only do that because it has the Plone Foundation. Without such a body you would need consensus, where there is no active opposition to an idea anymore. Consensus can work, but it can also lead to "shoutocracy" where the loudest voices win. For relicensing consensus is not enough, you would need unanimity. Can lead to deadlock, for example when one of the contributors is dead and can no longer agree to anything.

Copyright law. For national laws you need majority. In bi/multilateral situations you need unanimity: all parties have to agree. In the United Nations you need consensus. Unanimity can lead to harsh situations, where one party is obviously stronger, or single-party systems where the party says "everyone voted for us".

"In politics, nothing happens by accident. If it happens, you can bet it was planned that way." (Franklin D. Roosevelt).

Trade Related Aspects of Intellectual Property Rights (TRIPS) agreement. Was a coalition of the willing. U.S. Special 301 asks corporations: which companies have been "naughty" this year? Leads of black/grey-listing on behalf of the other corporations. Lobbying is very, very profitable, calculated as 22,000 by a few professors.

"Politics is too serious a matter to be left to politicians." (Charles de Gaulle)

You have to be at the negotiation table otherwise you have no influence, your wishes/needs will not be taken into account. Software patterns, web standards are affecting all of us.

"Those who are too smart to engage in politics are punished by being governed by those who are dumber." (Plato)

Challenge: single vendor versus community. Plone has decided it is a community. How do you address growth? How do we keep our core strong when more and more people come to the community? How do we keep our community able to make decisions? What about the structural "bottleneck bugs" that you know have to be fixed but no-one wants to do it and no customer is going to pay for it?

Open Database Alliance, http://odba.org, is being created. Membership fees are for 50 percent allocated by members and only 20-30 percent allocated by the board. So if either the members or the board want something, it can happen. There is room for plurality and diversity there, also room for Plone as it is also about databases.

Some conclusions.

1. Get active. Get involved. "In politics, an organised minority is a political majority." (Jesse Jackson)
2. The most important asset of Plone is you, the community.
3. Coordinate with your allies. You are not alone. Others are working on the same issues as you. Build alliances with them. That way you can shape things.

"What do your want to be a sailor for? there are greater storms in politics than you will ever find at sea. Piracy, broadsides, blood on the decks. You will find them all in politics." (David Lloyd George)

Build structures that allow your core people to operate without burning out.

Don't make enemies lightly; keep a professional dispute on a professional level: don't make it personal. It is easier to turn a friend into an enemy than turning an enemy into a friend.