Hi Thomas, The reason we asked for commits to the stable branch to be reviewed by another person (Zend or community) is so that we have another eye on commits that go into the stable releases. My past experience has been that sometimes bad fixes or API breaking fixes get commited (by accident) and I think this could help mitigate the risk. We intentionally don't limit this to Zenders. We think anyone who is well versed in the Zend Framework can be another helping eye on the commit. The person will not always be an expert on your code but might be able to catch some issues with the commit. Btw, you'd commit to trunk first so people would have an easy time to see the commit. In your case btw, Alex from our team would be a good person to have review the commits but anyone is fine.
I know it's a bit of overhead but I think the additional process would help make sure we release high quality mini releases. Quality is really one of the key things which should set our project apart. Andi > -----Original Message----- > From: Thomas Weidner [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 17, 2007 1:31 PM > To: Darby Felton > Cc: [email protected]; Alexander Veremyev > Subject: [fw-general] Re: Lifecycle Handling > > Hy Darby, > > >> 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.) > > So we should always use the Zend Branch 1.0 when committing > as long as its for fixing bugs. > Right ? But only if it has been reviewed by someone. > > >> 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. > > And exact here is my personal problem ;-) > > I am the main author and only person who codes all the I18N classes. > There is no other contributor. So I must ask Zend to review my code. > > > 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.) > > And what about fixes which do not include unit tests ? > For example... > I am not able to write tests for issues which are related to > 64bit machines only or for race conditions. > > >> 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). > > But should new documentation be reviewed by Zend ??? > > > 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. > > When I integrate new features to a class I can not committ > only parts.... > This would brake the existing class in the trunk or incubator. > And I dont want to get flamed for things which I know not to > work for now. > > Coding a new class for example is no problem... > but changing existing classes is a problematic thing. > The other thing is that I can not code every day... > often I have several days where no progress is done. > > I think noone would be happy if I for example integrate the > new SQL-translate adapter but the base class work not anymore > in incubator because I commited to early. > > > 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. :) > > No I can not... > For example Zend_Date.... > I've integrated new features (array access). > But when there is a new bug I have to integrate it in trunk > (where the new feature resists) and in maintenance. > Otherwise the maintenance branch would also have the new > feature integrated which is not allowed. > > As in maintenance no new features are being integrated this > is the only possible way as I see it. > > Ok... > So who can review my changes since the last release ? > I've made several changes and bug fixes which should be integrated. > > Greetings > Thomas > I18N Team Leader > >
