Hi Thomas,
My comments are inline below:
Thomas Weidner wrote:
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
There is no 1.0.1 branch. The 1.0.1 release will be tagged from the
release-1.0 branch. A 1.0.2 release, though we may not have one before
1.1.0, would also be produced from this branch. When 1.1.0 is
approaching, we'll create a release-1.1 branch, from which 1.1.0,
1.1.1,
etc. would be tagged. This is illustrated with an image in the
lifecycle
document. (We _could_ create further release branches, such as for
1.0.1
and 1.0.2 separately, but such additional complexity is probably not
warranted for this project at this time.)
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 ? ;-) )
You aren't likely to lose your commit rights, Thomas, but we have to
reserve the right to revoke committers' privileges should they
decide to
continually ignore our contribution policies. There will be plenty of
questions, particularly during this initial stage of post-1.0.0
development, and I expect a high degree of leniency as everyone learns
the process together.
If anyone should have trouble with their SVN commit access, please
contact me personally, and I will see to it that such issues are
resolved.
The next point is that we have first to find a zend member who looks
through the changes before we commit them.
No, in most cases, you can simply have another contributor review your
work. Of course, you can always ask a Zend liaison to review your
work,
but we have limited bandwidth, and we have to delegate as much of this
work as possible to the community itself. We just want to make sure
that
unit tests pass and that the changes have been reviewed for potential
risks to stability before they are merged on to a release branch.
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.
The PHP project is managed in much the same way, actually, where
contributors are required to commit their changes to two places. The
main point of the review requirement is to help maintain the stability
of the release branches.
JIRA issues can be resolved as soon as passing unit tests for the fix
are committed to the trunk, though the issue should be marked as fixed
for the affected versions. (For us right now this means that resolving
an issue in the trunk fixes 1.1.0, and once the changes are merged to
the release branch, it would also fix 1.1.1.)
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 ?
As mentioned in the lifecycle document, no documentation is to be
merged
to release branches. Documentation improvements will go out with minor
and major releases (e.g., 1.1.0 and 2.0.0, respectively).
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.
It depends on the scope of the work and how long you expect the work
to
take. We don't want you to be stuck holding back committing your
incomplete work. If you write 200 lines of code today, you should
have a
place to commit it, even if it is not complete. This creates an
instant
backup and facilitates review before completion.
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.
No, minor and backward compatible changes may be made directly to the
trunk, but they should be accompanied by passing unit tests to confirm
the desired behavior from the changes.
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 ?
I don't know about eclipse specifically, but you can switch a single
working copy between two branches. Again, this is documented in the
lifecycle document; perhaps some elaboration is needed to make it more
clear? To strike a balance, we also do not want to be overwhelmingly
verbose, but where clarifications can be made, all the better. :)
Thanks for these questions! I'm sure you're not the only one thinking
about them, and hopefully these answers help a bit.
Best regards,
Darby
