Re: [fw-general] Re: Lifecycle Handling
Hi all, I added some minor changes to the version lifecycle document today. Included is a note and svn checkout example about checking out the release branch and trunk separately: http://framework.zend.com/wiki/x/HYo You can click the envelope icon in the upper right-hand part of the page to "watch" the page and receive e-mail when a change is made. Still no comments on the document... who will be the brave first poster? Best regards, Darby Thomas Weidner wrote: > I use also tools which are able to do such things... > UltraCompare is my choice. > > I think we should also write this "best practice" into the document. > Just to mention: Even if the things are clear to me, I asked this > questions because documentation did not make this clear enough ;-) > > Greetings > Thomas > I18N Team Leader > > - Original Message - From: "Bill Karwin" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, July 18, 2007 12:20 AM > Subject: RE: [fw-general] Re: Lifecycle Handling > > > Yes, the best working practice is to maintain two svn working copies. > One for trunk, and one for the branch (remember to "svn update" in both > trees regularly!) > > Here's a recommendation: I use a tool for comparing two directory > trees, called zsCompare. It allows me to compare full directories, and > see which files are different. Then I can open an individual file in > both trees to compare side by side. Then I can merge lines of code from > one tree to the other on a case-by-case basis. > http://www.zizasoft.com/products/zsCompare/index.shtml > > The Lite version costs only US$35 for a single license. I think it's > perfect for cases like this where you are comparing and merging bits > between two similar trees of files. > > I started using zsCompare when I was programming in Java, because the > tool can compare collections of files even inside .zip or .jar archives! > It saved me a lot of time. > > Of course other tools exist that can be used in a similar way, but > zsCompare works well for me. > > Regards, > Bill Karwin > >> -----Original Message- >> From: Thomas Weidner [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, July 17, 2007 3:00 PM >> To: Bill Karwin; fw-general@lists.zend.com >> Subject: Re: [fw-general] Re: Lifecycle Handling >> >> Hy, >> >> which means that core-contributors have to have two released >> on their workstations. >> The trunk for new features and the branch for maintenance releases. >> >> That's what I asked for and noone was able to definitly say yes or no. >> I expect most people would not be very amused if I fix bugs >> only for 1.1 >> (trunk) instead of 1.0.x (branch) ;-) >> >> Greetings >> Thomas >> I18N Team Leader >> >> - Original Message - >> From: "Bill Karwin" <[EMAIL PROTECTED]> >> To: >> Sent: Tuesday, July 17, 2007 11:15 PM >> Subject: RE: [fw-general] Re: Lifecycle Handling >> >> >> >> > -Original Message- >> > From: Thomas Weidner [mailto:[EMAIL PROTECTED] >> > >> > 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. >> >> This means there are a few choices: >> >> (a) Implement the same bug fix in a different way, to work >> with the code >> in the branch. But depending on the nature of the bug, this >> may be too >> much work. >> >> (b) Implement the bug fix in both trunk and branch, >> implemented in a way >> that doesn't rely on the new features. Sometimes this is >> possible, but >> sometimes it's not possible or it's too much work. >> >> (c) Fix the bug in the trunk but don't fix it in the branch. >> Users must >> wait until 1.1.0 to get some bug fixes. >> >> I think all cases will fit into the three choices above. :-) >> >> Regards, >> Bill Karwin >> >> > >
Re: [fw-general] Re: Lifecycle Handling
I use also tools which are able to do such things... UltraCompare is my choice. I think we should also write this "best practice" into the document. Just to mention: Even if the things are clear to me, I asked this questions because documentation did not make this clear enough ;-) Greetings Thomas I18N Team Leader - Original Message - From: "Bill Karwin" <[EMAIL PROTECTED]> To: Sent: Wednesday, July 18, 2007 12:20 AM Subject: RE: [fw-general] Re: Lifecycle Handling Yes, the best working practice is to maintain two svn working copies. One for trunk, and one for the branch (remember to "svn update" in both trees regularly!) Here's a recommendation: I use a tool for comparing two directory trees, called zsCompare. It allows me to compare full directories, and see which files are different. Then I can open an individual file in both trees to compare side by side. Then I can merge lines of code from one tree to the other on a case-by-case basis. http://www.zizasoft.com/products/zsCompare/index.shtml The Lite version costs only US$35 for a single license. I think it's perfect for cases like this where you are comparing and merging bits between two similar trees of files. I started using zsCompare when I was programming in Java, because the tool can compare collections of files even inside .zip or .jar archives! It saved me a lot of time. Of course other tools exist that can be used in a similar way, but zsCompare works well for me. Regards, Bill Karwin -Original Message- From: Thomas Weidner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 17, 2007 3:00 PM To: Bill Karwin; fw-general@lists.zend.com Subject: Re: [fw-general] Re: Lifecycle Handling Hy, which means that core-contributors have to have two released on their workstations. The trunk for new features and the branch for maintenance releases. That's what I asked for and noone was able to definitly say yes or no. I expect most people would not be very amused if I fix bugs only for 1.1 (trunk) instead of 1.0.x (branch) ;-) Greetings Thomas I18N Team Leader - Original Message - From: "Bill Karwin" <[EMAIL PROTECTED]> To: Sent: Tuesday, July 17, 2007 11:15 PM Subject: RE: [fw-general] Re: Lifecycle Handling > -Original Message- > From: Thomas Weidner [mailto:[EMAIL PROTECTED] > > 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. This means there are a few choices: (a) Implement the same bug fix in a different way, to work with the code in the branch. But depending on the nature of the bug, this may be too much work. (b) Implement the bug fix in both trunk and branch, implemented in a way that doesn't rely on the new features. Sometimes this is possible, but sometimes it's not possible or it's too much work. (c) Fix the bug in the trunk but don't fix it in the branch. Users must wait until 1.1.0 to get some bug fixes. I think all cases will fit into the three choices above. :-) Regards, Bill Karwin
Re: [fw-general] Re: Lifecycle Handling
Hi, I do similar, with a tool named WinMerge, gotta love Open Source :). http://winmerge.org/ Best, -- Andries Seutens http://andries.systray.be Bill Karwin schreef: Yes, the best working practice is to maintain two svn working copies. One for trunk, and one for the branch (remember to "svn update" in both trees regularly!) Here's a recommendation: I use a tool for comparing two directory trees, called zsCompare. It allows me to compare full directories, and see which files are different. Then I can open an individual file in both trees to compare side by side. Then I can merge lines of code from one tree to the other on a case-by-case basis. http://www.zizasoft.com/products/zsCompare/index.shtml The Lite version costs only US$35 for a single license. I think it's perfect for cases like this where you are comparing and merging bits between two similar trees of files. I started using zsCompare when I was programming in Java, because the tool can compare collections of files even inside .zip or .jar archives! It saved me a lot of time. Of course other tools exist that can be used in a similar way, but zsCompare works well for me. Regards, Bill Karwin -Original Message- From: Thomas Weidner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 17, 2007 3:00 PM To: Bill Karwin; fw-general@lists.zend.com Subject: Re: [fw-general] Re: Lifecycle Handling Hy, which means that core-contributors have to have two released on their workstations. The trunk for new features and the branch for maintenance releases. That's what I asked for and noone was able to definitly say yes or no. I expect most people would not be very amused if I fix bugs only for 1.1 (trunk) instead of 1.0.x (branch) ;-) Greetings Thomas I18N Team Leader - Original Message - From: "Bill Karwin" <[EMAIL PROTECTED]> To: Sent: Tuesday, July 17, 2007 11:15 PM Subject: RE: [fw-general] Re: Lifecycle Handling -Original Message- From: Thomas Weidner [mailto:[EMAIL PROTECTED] 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. This means there are a few choices: (a) Implement the same bug fix in a different way, to work with the code in the branch. But depending on the nature of the bug, this may be too much work. (b) Implement the bug fix in both trunk and branch, implemented in a way that doesn't rely on the new features. Sometimes this is possible, but sometimes it's not possible or it's too much work. (c) Fix the bug in the trunk but don't fix it in the branch. Users must wait until 1.1.0 to get some bug fixes. I think all cases will fit into the three choices above. :-) Regards, Bill Karwin Gecontroleerd op virussen door de JOJO Secure Gateway.
RE: [fw-general] Re: Lifecycle Handling
> -Original Message- > From: Thomas Weidner [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 17, 2007 2:58 PM > To: Andi Gutmans; Darby Felton > Cc: fw-general@lists.zend.com; Alexander Veremyev > Subject: Re: [fw-general] Re: Lifecycle Handling > > Just to mention: > Dont only rely on code-quality... also documentation quality > should be archived. > Many of our contributors are no english natives. We should > also think about having someone looking over documentation > parts before they are integrated yes, I agree. The only issue with that is that it should really be a technical writer and I don't have such a resource available right now. I will try and see what can be done though but not sure how much I can do. Andi
RE: [fw-general] Re: Lifecycle Handling
Hi Thomas, You obviously can't do what you can't do. If you can't reproduce but had someone else validated that the fix is good then that's in the spirit of what we wrote. In most cases you should still be able to write a unit test that would fail on his system (otherwise how did he verify that it was fixed). Note: You did ask another person to verify your patch which is in the spirit of what we wrote. It's important to understand that these guidelines are trying to help everyone stick to a good high-quality process. We will have to tweak as we implement them in real-life. I think most would agree though that if we can follow this process we will end up a higher-quality project than most others. Just the notion of asking people to get peer review is something which is not implemented explicitly in most other projects. With the Zend Framework we don't only want to deliver best practices with the framework itself but also lead by example in how we develop, test and document. Andi > -Original Message- > From: Thomas Weidner [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 17, 2007 2:34 PM > To: Willie Alberty; Zend Framework > Subject: Re: [fw-general] Re: Lifecycle Handling > > Hy, > > >> 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. > > > > There may be no other core contributors for the i18n classes, but > > there are dozens of contributors to the framework. I > monitor the i18n > > list as I'm sure many others do. if you need a reviewer, > I'm sure any > > one of us would be happy to look at your code. > > Would be great... > As always I am of course speaking out loud what others dont > want to say because they are to shy ;-) > > >> 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. > > > > Then how can you be sure that the bug has been fixed? Bug > fixing is > > where unit tests truly shine: before you fix a bug, you > write a test > > that shows the bug exists. Then you fix the bug. In this > way, you can > > be assured that you will never re-introduce the bug because there > > will always be a test for it. > > Speaking of the two mentioned cases: > > There was a bug within the gettext adapter which only occur > on big endian encoding with particular 64bit machines. > On other 64bit machines the problem did not show. The reason > is a bug within php itself. > > How should I code a test, when I am not able to reproduce it ? > And in my opinion the already written tests were broken > within these machines. > But the people who committed the bugs were not able to run > unit tests on their machines. > > And I know that the bug was fixed because I gave the changed > lines to the one who had the bug and he said it worked. > > The second bug I mentioned could not be reproduced... > Wether by me nor by the one who wrote us the bug. > I only added two exceptions for handling such impossible conditions. > If this conditions arise someone has changed the locale > source files and this is something I am not able to write a test for. > > Speaking of normal bugs, I am of course always writing the > unit tests... > If you look at the testbed for Zend_Date you will see that it > is the biggest of the whole framework. > This is normal coding process... > > >> 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. > > > > You should simply checkout two working copies, one from the > branch, > > and one from the trunk. This is how I've handled > maintenance branches > > for years. > > That's exactly what I expected and asked for, but noone > wanted to answer this definitly. > > Review: > > So I need review and integration of the following trunk changes: > 5636 > 5720 > 5721 > I would have to integrate them into the next tag release. > All other changes could be reviewed > 5693 > 5628 > 5618 > 5586 - 5613 > and are for 1.1.0 > > > Greetings > Thomas > I18N Team Leader > >
RE: [fw-general] Re: Lifecycle Handling
Yep this is the case. We do the same in the PHP project. Actually right now we have three (4.4.x, 5.2.x and 6.x). There's really no other way but we will try and aim to only have two at any given time (pray...). > -Original Message- > From: Thomas Weidner [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 17, 2007 3:00 PM > To: Bill Karwin; fw-general@lists.zend.com > Subject: Re: [fw-general] Re: Lifecycle Handling > > Hy, > > which means that core-contributors have to have two released > on their workstations. > The trunk for new features and the branch for maintenance releases. > > That's what I asked for and noone was able to definitly say yes or no. > I expect most people would not be very amused if I fix bugs > only for 1.1 > (trunk) instead of 1.0.x (branch) ;-) > > Greetings > Thomas > I18N Team Leader > > - Original Message - > From: "Bill Karwin" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, July 17, 2007 11:15 PM > Subject: RE: [fw-general] Re: Lifecycle Handling > > > > > -Original Message- > > From: Thomas Weidner [mailto:[EMAIL PROTECTED] > > > > 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. > > This means there are a few choices: > > (a) Implement the same bug fix in a different way, to work > with the code > in the branch. But depending on the nature of the bug, this > may be too > much work. > > (b) Implement the bug fix in both trunk and branch, > implemented in a way > that doesn't rely on the new features. Sometimes this is > possible, but > sometimes it's not possible or it's too much work. > > (c) Fix the bug in the trunk but don't fix it in the branch. > Users must > wait until 1.1.0 to get some bug fixes. > > I think all cases will fit into the three choices above. :-) > > Regards, > Bill Karwin > >
RE: [fw-general] Re: Lifecycle Handling
Yes, the best working practice is to maintain two svn working copies. One for trunk, and one for the branch (remember to "svn update" in both trees regularly!) Here's a recommendation: I use a tool for comparing two directory trees, called zsCompare. It allows me to compare full directories, and see which files are different. Then I can open an individual file in both trees to compare side by side. Then I can merge lines of code from one tree to the other on a case-by-case basis. http://www.zizasoft.com/products/zsCompare/index.shtml The Lite version costs only US$35 for a single license. I think it's perfect for cases like this where you are comparing and merging bits between two similar trees of files. I started using zsCompare when I was programming in Java, because the tool can compare collections of files even inside .zip or .jar archives! It saved me a lot of time. Of course other tools exist that can be used in a similar way, but zsCompare works well for me. Regards, Bill Karwin > -Original Message- > From: Thomas Weidner [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 17, 2007 3:00 PM > To: Bill Karwin; fw-general@lists.zend.com > Subject: Re: [fw-general] Re: Lifecycle Handling > > Hy, > > which means that core-contributors have to have two released > on their workstations. > The trunk for new features and the branch for maintenance releases. > > That's what I asked for and noone was able to definitly say yes or no. > I expect most people would not be very amused if I fix bugs > only for 1.1 > (trunk) instead of 1.0.x (branch) ;-) > > Greetings > Thomas > I18N Team Leader > > - Original Message - > From: "Bill Karwin" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, July 17, 2007 11:15 PM > Subject: RE: [fw-general] Re: Lifecycle Handling > > > > > -Original Message- > > From: Thomas Weidner [mailto:[EMAIL PROTECTED] > > > > 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. > > This means there are a few choices: > > (a) Implement the same bug fix in a different way, to work > with the code > in the branch. But depending on the nature of the bug, this > may be too > much work. > > (b) Implement the bug fix in both trunk and branch, > implemented in a way > that doesn't rely on the new features. Sometimes this is > possible, but > sometimes it's not possible or it's too much work. > > (c) Fix the bug in the trunk but don't fix it in the branch. > Users must > wait until 1.1.0 to get some bug fixes. > > I think all cases will fit into the three choices above. :-) > > Regards, > Bill Karwin > >
Re: [fw-general] Re: Lifecycle Handling
Hy, which means that core-contributors have to have two released on their workstations. The trunk for new features and the branch for maintenance releases. That's what I asked for and noone was able to definitly say yes or no. I expect most people would not be very amused if I fix bugs only for 1.1 (trunk) instead of 1.0.x (branch) ;-) Greetings Thomas I18N Team Leader - Original Message - From: "Bill Karwin" <[EMAIL PROTECTED]> To: Sent: Tuesday, July 17, 2007 11:15 PM Subject: RE: [fw-general] Re: Lifecycle Handling -Original Message- From: Thomas Weidner [mailto:[EMAIL PROTECTED] 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. This means there are a few choices: (a) Implement the same bug fix in a different way, to work with the code in the branch. But depending on the nature of the bug, this may be too much work. (b) Implement the bug fix in both trunk and branch, implemented in a way that doesn't rely on the new features. Sometimes this is possible, but sometimes it's not possible or it's too much work. (c) Fix the bug in the trunk but don't fix it in the branch. Users must wait until 1.1.0 to get some bug fixes. I think all cases will fit into the three choices above. :-) Regards, Bill Karwin
Re: [fw-general] Re: Lifecycle Handling
Hy, 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. Yeah... I just remember the change which gavin made to the Zend_Date API which broke the complete class where I was nearly in giving up my work for Zend Framework. And it was a Zender who broke it. ;-) 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. I am with you in having things checked by minimum 4 eyes. But it seems that I am the only one who has questions on the practical useage for all... ;-) Better to have this questions answered early than too late ;-) In your case btw, Alex from our team would be a good person to have review the commits but anyone is fine. I know, otherwise I would have cc'ed my mails to another Zend'er ;-)) 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. Definitly... Just to mention: Dont only rely on code-quality... also documentation quality should be archived. Many of our contributors are no english natives. We should also think about having someone looking over documentation parts before they are integrated Greetings Thomas I18N Team Leader
Re: [fw-general] Re: Lifecycle Handling
Hy, 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. There may be no other core contributors for the i18n classes, but there are dozens of contributors to the framework. I monitor the i18n list as I'm sure many others do. if you need a reviewer, I'm sure any one of us would be happy to look at your code. Would be great... As always I am of course speaking out loud what others dont want to say because they are to shy ;-) 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. Then how can you be sure that the bug has been fixed? Bug fixing is where unit tests truly shine: before you fix a bug, you write a test that shows the bug exists. Then you fix the bug. In this way, you can be assured that you will never re-introduce the bug because there will always be a test for it. Speaking of the two mentioned cases: There was a bug within the gettext adapter which only occur on big endian encoding with particular 64bit machines. On other 64bit machines the problem did not show. The reason is a bug within php itself. How should I code a test, when I am not able to reproduce it ? And in my opinion the already written tests were broken within these machines. But the people who committed the bugs were not able to run unit tests on their machines. And I know that the bug was fixed because I gave the changed lines to the one who had the bug and he said it worked. The second bug I mentioned could not be reproduced... Wether by me nor by the one who wrote us the bug. I only added two exceptions for handling such impossible conditions. If this conditions arise someone has changed the locale source files and this is something I am not able to write a test for. Speaking of normal bugs, I am of course always writing the unit tests... If you look at the testbed for Zend_Date you will see that it is the biggest of the whole framework. This is normal coding process... 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. You should simply checkout two working copies, one from the branch, and one from the trunk. This is how I've handled maintenance branches for years. That's exactly what I expected and asked for, but noone wanted to answer this definitly. Review: So I need review and integration of the following trunk changes: 5636 5720 5721 I would have to integrate them into the next tag release. All other changes could be reviewed 5693 5628 5618 5586 - 5613 and are for 1.1.0 Greetings Thomas I18N Team Leader
Re: [fw-general] Re: Lifecycle Handling
Hi All I've got some small commits for Zend_Mail that should be released ASAP, as it affects SMTP - it was revision 5724 Could someone please review these and give me a heads-up on the best way to merge into the 1.0.1 branch? Cheers 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, t
RE: [fw-general] Re: Lifecycle Handling
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: fw-general@lists.zend.com; 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: fw-general@lists.zend.com; 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
RE: [fw-general] Re: Lifecycle Handling
> -Original Message- > From: Thomas Weidner [mailto:[EMAIL PROTECTED] > > 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. This means there are a few choices: (a) Implement the same bug fix in a different way, to work with the code in the branch. But depending on the nature of the bug, this may be too much work. (b) Implement the bug fix in both trunk and branch, implemented in a way that doesn't rely on the new features. Sometimes this is possible, but sometimes it's not possible or it's too much work. (c) Fix the bug in the trunk but don't fix it in the branch. Users must wait until 1.1.0 to get some bug fixes. I think all cases will fit into the three choices above. :-) Regards, Bill Karwin
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: fw-general@lists.zend.com; 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 b
Re: [fw-general] Re: Lifecycle Handling
On Jul 17, 2007, at 1:31 PM, Thomas Weidner wrote: 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... 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. There may be no other core contributors for the i18n classes, but there are dozens of contributors to the framework. I monitor the i18n list as I'm sure many others do. if you need a reviewer, I'm sure any one of us would be happy to look at your code. JIRA issues can be resolved as soon as passing unit tests for the fix are committed to the trunk,.. 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. Then how can you be sure that the bug has been fixed? Bug fixing is where unit tests truly shine: before you fix a bug, you write a test that shows the bug exists. Then you fix the bug. In this way, you can be assured that you will never re-introduce the bug because there will always be a test for it. 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. You should simply checkout two working copies, one from the branch, and one from the trunk. This is how I've handled maintenance branches for years. -- Willie Alberty, Owner Spenlen Media [EMAIL PROTECTED] http://www.spenlen.com/
[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
Re: [fw-general] Re: Lifecycle Handling
Darby Felton wrote: > Thomas Weidner wrote: > 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.) Oops - here 1.1.1 should be 1.0.1 instead. :)
[fw-general] Re: Lifecycle Handling
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
