Btw, as Darby mentioned in his initial email, we are very open to feedback re: the lifecycle document. This is our stab at putting something out there which we think will not be too hard but will also enable high-quality. Any suggestions for tweaks/changes should definitely be voiced. We'll definitely need to strike a balance here (which we tried to do).
Andi > -----Original Message----- > From: Andi Gutmans [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 17, 2007 2:08 PM > To: Thomas Weidner; Darby Felton > Cc: [email protected]; Alexander Veremyev > Subject: RE: [fw-general] Re: Lifecycle Handling > > 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 > > > > >
