mRFC 0046: (Mjölnir) new cvs-model
Revision History
- 2009-06-16, created by Oskari Kokko
About the current model of commiting to the midgard repo
Nowdays anyone can commit to the repo of ragnaroek and to the new midcom 3. I'm not talking about how things work in MidCOM 3, because so few is using or commiting to the yet. So, the examples I'm writing are from ragnaroek and the main idea of this mRFC is to avoid these problems in MidCOM 3 (I speak of MidCOM 3, even though we desided to ditch that name and start using Midgard CMS instead).
Problems that I have had lately with the midcom have allways somewhat related to something that was working being broken all of a sudden. And the only thing that I did, was to upgrade some midcom-component, because some other fix was made to the new release. So, while something is fixed, the new version allways brings other new 'features' along, that somehow broke things. This is because everyone has commit rights to the repo and no one has enought time to test the every outcome of their changes to the code. So, we need some rules for commiting.
New cvs-model
The codebase of midcom being so big as it is now, there is no possibility for anyone to see all the possible risks in a new feature all by himself, at least when that someone needs to work at the same time. So, what I propose, is to have testing and stable branches and make some sort of a valuation when moving fixes and features from testing-branch to the stable branch. Now we have the trunk for ragnaroek, whitch automatically becomes 'stable', when a new release is made. So, there should be selected group of people, who can approve a set of commits from the testing-branch to the stable one.
What does a set of commits nead to be approved to the stable branch
For any feature needed to be in the stable branch, there is someone who needs it there. So, he / she makes a document containing following things
- List of commits needed to be moved to stable branch
- List of tickets affected by this
- So, basicly this is the list of fixed things
- List of new features
- List of things that these changes might affect
- Unit tests of all the new features
- Basicly, in the end, all the features in Midcom 3 should have unit test
- A test report
- Screenshot about the unit test results
- Test report must contain tests about all the new features, fixed issues and tests about the things that these changes may affect
- Test report should contain at least few screenshots of the tests (these tests mean manually clicking the feature, because with unit tests you propably won't see all of the possible outcomes)
After the person neading the new features in the stable branch has made this request with enought test data, those who can approve commits from testing to stable, make the changes. So, for those who can approve, the job really isn't that big, because the coder has done all the testing and made a report about it. Report can be then made public, so afterwards others can see what happened and where.
As a side note at this point, those who are able to approve commits, can't approve their own commits. They need allways some other to approve their commits.
Other option is to have someone, who really has time to run tests after every commit. But as we don't have the Midgard Foundation yet, I see no possibility in here. And to be honest, testing others commits might be a bit hard job.
Basicly, what I'm saying, is that the current situation is unbearable and we need to do things a bit differently than it is now.