I’m going to be playing Opencore Release Manager, starting now. Let me explain what that means, and relay some plans.
Scope
I’m just talking about opencore, the Plone extension at the heart of the openplans software stack.
I’m not talking about any other part of the openplans software stack (tasktracker, wordpress, deliverance, …)
I’m definitely not talking about openplans.org the website.
Opencore needs a release manager?
Opencore was originally created by TOPP for www.openplans.org. So opencore releases have historically been driven by the needs of www.openplans.org’s deployment schedule. Since our deployment process doesn’t require a formal opencore release, releases tend to be a rare afterthought.
But there are at least two things that more formal releases would help with:
- Lower the barrier for other community members to get started using opencore.
- Let the world know about what we’re doing.
My overarching goal is to promote a lively community of developers and users for opencore, and provide some balance to TOPP’s path of least resistance–to only worry about our own deployments.
Why me?
Ethan asked me to do it and I was happy to volunteer. (If you don’t know who Ethan is either, this picture should suffice: http://www.openplans.org/people/ejucovy )
Who?
I’m Paul Winkler, a Zope user and developer since 1999, a TOPP employee since October 2007, and Opencore’s release manager since right now. http://www.openplans.org/people/slinkp
What will determine the release schedule?
I want to decouple Opencore’s release cycle from the TOPP deployment cycle. Douglas Mayle has volunteered to act as the openplans.org deployment manager; he and I have tentatively agreed on this plan:
Of course TOPP’s own needs will continue to drive a lot of opencore development, which is a good thing; but that shouldn’t be a burden on you, the wider opencore user/developer community.
Does the Release Manager have to be a TOPP employee?
No. I’m just the first. It should be a rotating job. It’s my hope that before long, people outside TOPP will be willing and able to play this role.
When will the job rotate?
Don’t know yet.
What does the Opencore Release Manager do?
- Manage the release schedule (not TOPP’s deployment schedule!). This does not mean I’m the dictator, just the point man and coordinator.
- Shepherd release candidates through a stabilization process.
- Create and announce final release packages.
- Document upgrade process.
- Document any backward incompatibilities.
- Draft and enforce relevant dev process standards (e.g. which branches or plugins should you commit bugfixes or features to).
- Document this process for the next release manager.
At this stage, I’ll also be acting as a sort of ambassador between TOPP and the wider community. Which is a bit silly, as every opencore contributor does that to whatever extent they wish. But I think for now it’s useful to consciously formalize it as part of my job. I will make an effort to:
- Solicit community input about decisions we need to make for opencore.
- Remind TOPP employees to discuss and make decisions about opencore out in the open. If you have a real-life relevant conversation I’ll try to remind you to post a summary to the mailing list.
- Keep the community updated on changes to our build process. If we break your builds, you can complain to the opencore-user or opencore-dev mailing list, and you should expect a response from me.
- Lobbyist for the community: e.g. prioritizing and scheduling feature requests and bugfixes.
There will of course be other forces at TOPP driving things with other priorities, but *my* role will be to ensure that the community’s needs don’t get ignored. This is more about release management than development management: I’m not in charge of deciding which features get done when. But whenever good code comes from the community, we have a responsibility to get that code released in a timely manner, and generally be as responsive as we can.
What about the rest of the stack?
We realize that most of the non-TOPP users of opencore are using some or all of the entire www.openplans.org stack. We’d eventually like to be making formal releases of all the packages, and possibly some kind of “batteries included” big meta-package; but that’s in the future. For now, opencore is our fastest-moving target and the most in need of release management.
Release Numbers
We supposedly have a policy now (Ethan proposed it here: http://tinyurl.com/4ybpro) … but we haven’t been sticking with it. I’m going to draft a proposal for a simpler convention and process. More on this in a later message.
Releases, Eggs, and Builds
I’d like to be releasing versioned eggs of opencore to PyPi. These should be installable into a suitable Zope/Plone instance using nothing more than easy-install.
(We have made a few releases to PyPi, but they aren’t actually usable … some files are missing.)
For bootstrapping a full stack including Zope, Plone, and other non-egg stuff, TOPP will continue to use and develop our Fassembler build tools. But it should become easier to do without that, if you want.
Branch Policy
We are currently trying to follow a “Stable Trunk” practice. Experimental and risky code should not be on the trunk.
Developer Infrastructure
This is only tangentially related to release management. I just wanted to note in passing that we’re planning a more thought-out integrated home on the web for opencore development. We’re calling this the “TOPP Dev Center” for now. Other open-source packages from TOPP will live there too.
In the meantime:
Wiki and mailing lists are at: http://www.openplans.org/projects/opencore
Trac (bug tracking) is at: http://trac.openplans.org/openplans
If you need a Trac account, just ask. (I wish we could take anonymous bug reports, but we got trac spam. There is a guest account, but I’m not sure of the login details.)
If you want SVN commit access, first you should send some bugfixes and features as patches (either in trac or on the dev list). We’ll happily give commit access to people who have a history of submitting good patches. There will be a contributor agreement you’ll have to sign, somewhat similar to Zope’s.
Current Road Map
Some things coming up in the short term:
- Plone 3
We will soon be releasing a version of opencore that runs on Plone 3. Rob Miller has done all the hard work and we just need to QA this branch and merge it back to the trunk.
Currently, the plan is:
- TOPP will create a release candidate from the plone3 branch.
- TOPP will QA this branch.
- TOPP will deploy this branch to www.openplans.org.
When that goes well, I will:
- Branch off the current opencore trunk to an opencore-plone2.5 branch
- Make a final stable release from the opencore-plone2.5 branch (to be followed by bugfix releases as necessary)
- Merge the plone 3 branch back to the trunk.
This will definitely happen this summer; hopefully even in July. More concrete dates will be forthcoming.
If people in the community expect to continue using the Plone 2.5 version for a while, I would like to hear about it so I can serve you better.
- Easier “plugin” management using z3c.autoinclude. This will replace our usage of zcmlloader, doing the same job but better (and other people are actively developing it).
Some ongoing maintenance tasks I’d love community help with:
- Opencore is slow. Let’s make things faster. (But let’s get plone 3 merged to trunk first, it already helps substantially.)
- The test suite has a lot of problems. More on this in a later message.
- Dependency cleanup. I suspect there is cruft in the Products “bundle” that we don’t actually use.
- What do you guys want?
Going forward, this road map should have a permanent home prominently linked in the aformentioned dev center. There is already such a page at http://www.openplans.org/projects/opencore/planning but it badly needs an update. I’ll be looking to revive that.
Questions?
Whew. Sorry for the length. Feedback would be most welcome.
- PW
