How to setup your Plone core sprint
2013 octobre 19
I promised to published this article last year but… well, no excuse. The topic is still hot as we work on in Arnhem in November 2013, 11 to 15 to finish it for Plone 5.
- If you are working in the Plone core you must should a plip before the beginning of the sprint. It will be easier for other people to follow your work some months later.
- For commiters, the main point is to check if you already give your contributor agreement back to the Plone Fundation. If you’re not there should be someone with blank agreements in your sprint to make things go easy.
- Once you know how many sprinters you have on your topic you must organize the area to be comfortable for all.
- Fing a way to show everybody the tasks that are on going and who is working on. My way is a whiteboard with post-its
- Prepare the technical parts before to start coding:
- Identify all the packages you’re working on and create a remote branch for your plip. We were working at first on Products.CMFPlone, plone.app.content, plone.app.users, and after we also include plone.app.controlpanel in the list.
- Don’t make a branch in buildout.coredev create a plips configuration file in the ‘plips‘ folder.Then run your buildout using this configuration file as master: bin/buildout -c plips/plip13260-cpy-removal.cfg
- Check if everybody have commit rights.
- If there’s a change in the plip configuration file notice it to everyone fast.
- Make regular internal reports to know who needs help or work 🙂
- Write down what’s you’re doing on
For commiters, the main point is to check if you already give your contributor agreement back to the Plone Fundation. If you’re not there should be someone with blank agreements in your sprint to make things go easy.
Commiters should also follow a process to make the pull going right:
- Have fun
- After each plip configuration file update check if all plip eggs are well checkouted and if they are in the good branch
- When you start a task create a local branch to avoiding conflicts before your merge
- Commit early, often
- Fetch and pull others commits before to merge
- Run tests without ‘-t‘
- Merge your work in the plip branch, not the master
- Test again before the push
- If you need help asks (I know, git is overcomplicated 😉 )
- Have fun! Did I say it before?
- Have a follow up plan and stay in touch
Thanks to Eric Steele for the first setup, Liz as the proposer of the sprint topic, Maurits as the technical leader and for all people around there that were working on that sprint.