Hy Zend'ers,
I just read through the newly created "lifecycle" description from darby.
So now I wanted to add my last changes as the next mini release is proposed.
I was not able to see the branch 1.0.1... only the old branch 1.0
And I dont want to loose my commit rights as stated in this description for
not commiting the changes to the new branch only because the branch is not
avaiable ;-) (who has to do the work if the team leader and main author gets
suspended ? ;-) )
The next point is that we have first to find a zend member who looks through
the changes before we commit them.
Sounds a little bit complicated for bug fixes like the one I made yesterday.
3 lines added for an not reproducable race condition.
No unit tests and no documentation possible or needed.
It should also be clearified if issues can be closed when they are commited
to trunk, or only after they were commited to branch.
How about improvements to the documentation ???
I will improve the documentation of the I18N components from time to time.
Add new pages to answer often asked questions and so on...
How should we handle this ? Until now we commited them to trunk...
Should they also be reviewed by a Zend member ?
Should improvements always be commited to incubator, reviewed and then
commited to core ?
Because I normally code all, write documentation and unit tests and then I
commit the complete change to trunk.
So as I see it in sum the new workflow from now on is,
to commit all to incubator, let verify through Zend and after all say, your
3 lines of code are ok, commit to trunk.
Also I will have to have two working copies in my eclipse...
One for the trunk and one for the actual maintenance branch or is there a
better way to handle this within eclipse ?
Some clearification would be nice ;-)
Greetings
Thomas
I18N Team Leader
