Re: [Openstack] Bug fixes and test cases submitted against stable/diablo
On Wed, 2011-11-09 at 14:57 +0100, Thierry Carrez wrote: Soren Hansen wrote: 2011/11/9 Nachi Ueno ueno.na...@nttdata-agilenet.com: I understand your point. Stop QAing stable/diablo and focus on Essex. Oh, no no. That's not the point. I'm thrilled to have you work on QAing Diablo. The only issue is that the fixes you come up with should be pushed to Essex first. There are two reasons for this: * If we don't push the fixes to Essex, the problems will still be present in Essex and every release after that. * Having them in Essex lets us try them out, vet them and validate them more thoroughly before we let them into the stable branch. When a patch lands in the stable branch it has to be well tested already (unless of course Essex has deviated too much, in which case we'll have to accept the risk of getting it into Diablo directly). +1 You should submit patches to master and then backport them to stable/diablo, rather than proposing them for stable/diablo directly. That ensures your work benefits both branches: making diablo better without making essex worse than diablo. If that's just too much work, maybe you should raise the issue at the next QA meeting to try to get some outside help ? At the QA meeting yesterday, I offered my help to Nati. I will handle proposing his patches to Essex up to a future date where Nati and his team will switch to code against Essex, not Diablo/stable and propose first to master, then others will backport to diablo/stable. Nati and I will decide on that future date for his team to switch their focus to Essex trunk and not have to have someone manually forward-port these patches to trunk. Cheers, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Bug fixes and test cases submitted against stable/diablo
Hi folks Thank you for your help Mark and Jay and Reviewers I removed all review request for diablo/stable from Gerrit. And, We will follow community policy. Current our test code and bug fix is based on stable/diablo. For each branch. forward-porting is needed. 12 bug patch branch is in progress ( they are almost done) 34 bug patch branch is on github(*) 30 test code branch is on github. (*)https://github.com/ntt-pf-lab/nova/branches From next work alter these branches, We will follow the policy (Essex first). However, for now, we have not enough man-power. So please help us. I wrote a script which shows bug description and conflict files and merge command. (See https://gist.github.com/1355816) Each branch is linked to bug report. If you guys help forward-porting work, would you please assign the bug for yourself. (Thanks Jay!) Naming rule in our repository is like this. https://github.com/ntt-pf-lab/nova/tree/openstack-qa-nova-(bugID) For now, There are bugs which is not fixed yet, so test code fails. So I think we should start from bug fix. Cheers Nati 2011/11/10 Jay Pipes jaypi...@gmail.com: On Wed, 2011-11-09 at 14:57 +0100, Thierry Carrez wrote: Soren Hansen wrote: 2011/11/9 Nachi Ueno ueno.na...@nttdata-agilenet.com: I understand your point. Stop QAing stable/diablo and focus on Essex. Oh, no no. That's not the point. I'm thrilled to have you work on QAing Diablo. The only issue is that the fixes you come up with should be pushed to Essex first. There are two reasons for this: * If we don't push the fixes to Essex, the problems will still be present in Essex and every release after that. * Having them in Essex lets us try them out, vet them and validate them more thoroughly before we let them into the stable branch. When a patch lands in the stable branch it has to be well tested already (unless of course Essex has deviated too much, in which case we'll have to accept the risk of getting it into Diablo directly). +1 You should submit patches to master and then backport them to stable/diablo, rather than proposing them for stable/diablo directly. That ensures your work benefits both branches: making diablo better without making essex worse than diablo. If that's just too much work, maybe you should raise the issue at the next QA meeting to try to get some outside help ? At the QA meeting yesterday, I offered my help to Nati. I will handle proposing his patches to Essex up to a future date where Nati and his team will switch to code against Essex, not Diablo/stable and propose first to master, then others will backport to diablo/stable. Nati and I will decide on that future date for his team to switch their focus to Essex trunk and not have to have someone manually forward-port these patches to trunk. Cheers, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Bug fixes and test cases submitted against stable/diablo
2011/11/9 Nachi Ueno ueno.na...@nttdata-agilenet.com: I understand your point. Stop QAing stable/diablo and focus on Essex. Oh, no no. That's not the point. I'm thrilled to have you work on QAing Diablo. The only issue is that the fixes you come up with should be pushed to Essex first. There are two reasons for this: * If we don't push the fixes to Essex, the problems will still be present in Essex and every release after that. * Having them in Essex lets us try them out, vet them and validate them more thoroughly before we let them into the stable branch. When a patch lands in the stable branch it has to be well tested already (unless of course Essex has deviated too much, in which case we'll have to accept the risk of getting it into Diablo directly). However the current situation is different. IMO the quality diablo is not ready for real deployment. In the diablo summit, I think we agreed the policy Do not decrease code coverage on merge. But it is not applied through diablo timeframe,and the diablo has small coverage. This is true :( We are struggling with very tight schedule. X( If our contribution is rejected to the stable/diablo, to maintain our own branch is only option for us. And I don't really want to do this. Yes, I would very much like to avoid this as well. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Bug fixes and test cases submitted against stable/diablo
Soren Hansen wrote: 2011/11/9 Nachi Ueno ueno.na...@nttdata-agilenet.com: I understand your point. Stop QAing stable/diablo and focus on Essex. Oh, no no. That's not the point. I'm thrilled to have you work on QAing Diablo. The only issue is that the fixes you come up with should be pushed to Essex first. There are two reasons for this: * If we don't push the fixes to Essex, the problems will still be present in Essex and every release after that. * Having them in Essex lets us try them out, vet them and validate them more thoroughly before we let them into the stable branch. When a patch lands in the stable branch it has to be well tested already (unless of course Essex has deviated too much, in which case we'll have to accept the risk of getting it into Diablo directly). +1 You should submit patches to master and then backport them to stable/diablo, rather than proposing them for stable/diablo directly. That ensures your work benefits both branches: making diablo better without making essex worse than diablo. If that's just too much work, maybe you should raise the issue at the next QA meeting to try to get some outside help ? -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Bug fixes and test cases submitted against stable/diablo
Hi Nati (Restarting our offline discussion here ...) I see you've proposed a stack of changes to Nova. Nice work! Kudos! https://review.openstack.org/#q,status:open+project:openstack/nova+branch:stable/diablo+owner:nati,n,z However, they shouldn't be submitted against the stable/diablo branch. If they were just merged there, they would never make it into the Essex and later releases. The policy for what is acceptable in the stable branch is documented here: http://wiki.openstack.org/StableBranch The policy is pretty standard practice for stable branches and the reasons for it include: 1) We try and reduce the risk of regressions on the stable branch to the absolute minimum. We also try to reduce the size and number of changes so that people using the stable branch can be confident that the risk of the changes is low and they can review the changes themselves. 2) Getting fixes onto the main development branch before applying them to the stable branch means we have a good chance of catching any regressions caused by the fix on master before it has a chance to cause a regression on the stable branch. 3) But most importantly, the policy is there to ensure that people don't focus on stable branches to the detriment of the development branch. If everyone focused their effort on fixing the stable branch and never included those fixes in the development branch, every new release would be in terrible shape and the fixing effort would have to start over again. I think you're in the situation that (3) is trying to prevent. i.e. you and your team are focused on testing and fixing Diablo and don't have the time to submit your fixes against Essex. While it's great to see your fixes, IMHO you really need to think longer term. If you leave it until later to rebase the fixes onto master, you'll probably find it to be very difficult and may never complete the rebase. And if you never complete the rebase, all your effort is essentially wasted in the long term. I think most of the Linux distributors learnt this lesson the hard way over the years and now have an upstream first policy. Hopefully we can save you the pain of dealing a similar mess when Essex comes out! :-) Thanks, Mark. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Bug fixes and test cases submitted against stable/diablo
Hi Mark Thank you for your sharing discussion. # hmm, If I could create new instance of me, problem will be fixed. I understand your point. Stop QAing stable/diablo and focus on Essex. Ideally, we should focus on upstream branch. Ideally, we can start use the code after release out. However the current situation is different. IMO the quality diablo is not ready for real deployment. In the diablo summit, I think we agreed the policy Do not decrease code coverage on merge. But it is not applied through diablo timeframe,and the diablo has small coverage. And for essex, the specs are changing, so it is quite difficult QA by non-implementer. In addition, to wait 6 month is not allowed for my team. So QAing stable/branch with fixed specs is very important. Our contribution is 1000 unit test cases for stable/diablo nova, and bug patch (I'm not sure all test could be used for Essex) #Sorry i sent wrong number for you. There test cases found about 60 bugs. And also we are writing each bag patch. https://bugs.launchpad.net/nova/+bugs?search=Searchfield.bug_reporter=nati-ueno For test case, it didn't have bad effect for code. Otherwise they helps keep quality of code. No violation for (1). So I think it should be merged to stable/diablo. For bug patch, it should be discussed case-by-case. Some large refactoring have done already for Essex,then some bugs are fixed on the refactoring. We are struggling with very tight schedule. X( If our contribution is rejected to the stable/diablo, to maintain our own branch is only option for us. And I don't really want to do this. 2011/11/8 Mark McLoughlin mar...@redhat.com: Hi Nati (Restarting our offline discussion here ...) I see you've proposed a stack of changes to Nova. Nice work! Kudos! https://review.openstack.org/#q,status:open+project:openstack/nova+branch:stable/diablo+owner:nati,n,z However, they shouldn't be submitted against the stable/diablo branch. If they were just merged there, they would never make it into the Essex and later releases. The policy for what is acceptable in the stable branch is documented here: http://wiki.openstack.org/StableBranch The policy is pretty standard practice for stable branches and the reasons for it include: 1) We try and reduce the risk of regressions on the stable branch to the absolute minimum. We also try to reduce the size and number of changes so that people using the stable branch can be confident that the risk of the changes is low and they can review the changes themselves. 2) Getting fixes onto the main development branch before applying them to the stable branch means we have a good chance of catching any regressions caused by the fix on master before it has a chance to cause a regression on the stable branch. 3) But most importantly, the policy is there to ensure that people don't focus on stable branches to the detriment of the development branch. If everyone focused their effort on fixing the stable branch and never included those fixes in the development branch, every new release would be in terrible shape and the fixing effort would have to start over again. I think you're in the situation that (3) is trying to prevent. i.e. you and your team are focused on testing and fixing Diablo and don't have the time to submit your fixes against Essex. While it's great to see your fixes, IMHO you really need to think longer term. If you leave it until later to rebase the fixes onto master, you'll probably find it to be very difficult and may never complete the rebase. And if you never complete the rebase, all your effort is essentially wasted in the long term. I think most of the Linux distributors learnt this lesson the hard way over the years and now have an upstream first policy. Hopefully we can save you the pain of dealing a similar mess when Essex comes out! :-) Thanks, Mark. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Bug fixes and test cases submitted against stable/diablo
sending on behalf of Nati, on his request Hi Mark, Thank you for your sharing discussion. # hmm, If I could create new instance of me, problem will be fixed. I understand your point. Stop QAing stable/diablo and focus on Essex. Ideally, we should focus on upstream branch. Ideally, we can start use the code after release out. However the current situation is different. IMO the quality diablo is not ready for real deployment. In the diablo summit, I think we agreed the policy Do not decrease code coverage on merge. But it is not applied through diablo timeframe,and the diablo has small coverage. And for essex, the specs are changing, so it is quite difficult QA by non-implementer. In addition, to wait 6 month is not allowed for my team. So QAing stable/branch with fixed specs is very important. Our contribution is 1000 unit test cases for stable/diablo nova, and bug patch (I'm not sure all test could be used for Essex) #Sorry i sent wrong number for you. There test cases found about 60 bugs. And also we are writing each bag patch. https://bugs.launchpad.net/nova/+bugs?search=Searchfield.bug_reporter=nati-ueno For test case, it didn't have bad effect for code. Otherwise they helps keep quality of code. No violation for (1). So I think it should be merged to stable/diablo. For bug patch, it should be discussed case-by-case. Some large refactoring have done already for Essex,then some bugs are fixed on the refactoring. We are struggling with very tight schedule. (angry) If our contribution is rejected to the stable/diablo, to maintain our own branch is only option for us. And I don't really want to do this. Thanks! - Nati -Original Message- From: openstack-bounces+rohit.karajgi=vertex.co...@lists.launchpad.net [mailto:openstack-bounces+rohit.karajgi=vertex.co...@lists.launchpad.net] On Behalf Of Mark McLoughlin Sent: Tuesday, November 08, 2011 10:50 PM To: Nati Ueno Cc: openstack@lists.launchpad.net Subject: [Openstack] Bug fixes and test cases submitted against stable/diablo Hi Nati (Restarting our offline discussion here ...) I see you've proposed a stack of changes to Nova. Nice work! Kudos! https://review.openstack.org/#q,status:open+project:openstack/nova+branch:stable/diablo+owner:nati,n,z However, they shouldn't be submitted against the stable/diablo branch. If they were just merged there, they would never make it into the Essex and later releases. The policy for what is acceptable in the stable branch is documented here: http://wiki.openstack.org/StableBranch The policy is pretty standard practice for stable branches and the reasons for it include: 1) We try and reduce the risk of regressions on the stable branch to the absolute minimum. We also try to reduce the size and number of changes so that people using the stable branch can be confident that the risk of the changes is low and they can review the changes themselves. 2) Getting fixes onto the main development branch before applying them to the stable branch means we have a good chance of catching any regressions caused by the fix on master before it has a chance to cause a regression on the stable branch. 3) But most importantly, the policy is there to ensure that people don't focus on stable branches to the detriment of the development branch. If everyone focused their effort on fixing the stable branch and never included those fixes in the development branch, every new release would be in terrible shape and the fixing effort would have to start over again. I think you're in the situation that (3) is trying to prevent. i.e. you and your team are focused on testing and fixing Diablo and don't have the time to submit your fixes against Essex. While it's great to see your fixes, IMHO you really need to think longer term. If you leave it until later to rebase the fixes onto master, you'll probably find it to be very difficult and may never complete the rebase. And if you never complete the rebase, all your effort is essentially wasted in the long term. I think most of the Linux distributors learnt this lesson the hard way over the years and now have an upstream first policy. Hopefully we can save you the pain of dealing a similar mess when Essex comes out! :-) Thanks, Mark. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
