Re: Update on 0.22
Sorry I missed this thread earlier. I'm not going to worry about the water under the bridge at this point, but going forward I would like to only include those issues marked as blocker. If a new issue crops up I will be taking a closer look at it and may push back. We've got less than 10 issues left to go :-) Cheers, Nige Sent from my iPad On Jun 2, 2011, at 11:31 AM, Todd Lipcon t...@cloudera.com wrote: On Thu, Jun 2, 2011 at 11:06 AM, Konstantin Shvachko shv.had...@gmail.comwrote: I propose just to make them blockers before committing to attract attention of the release manager and get his approval. Imho, even small changes, like HDFS-1954 are blockers, because a vague UI message is bug and bugs are blockers. Bugs are blockers? Then we'll never release! Let's hear from Nigel what he thinks. It's his branch, if he's upset about the way it's being handled, he can deal with it as he sees fit. -Todd On Thu, Jun 2, 2011 at 10:39 AM, Todd Lipcon t...@cloudera.com wrote: On Wed, Jun 1, 2011 at 11:32 PM, Konstantin Shvachko shv.had...@gmail.comwrote: I can see them well. I think Suresh's point is that non-blockers are going into 0.22. Nigel, do you have full control over it? Of course it's up to Nigel to decide, but here's my personal opinion: One of the reasons we had a lot of divergence (read: external branches/forks/whatever) off of 0.20 is that the commit rules on the branch were held pretty strictly. So, if you wanted a non-critical bug fix or a small improvement, the only option was to do such things on an external fork. 0.20 was branched in December '08 and not released until mid April '09. In 4 months a fair number of bug fixes and small improvements go in. 0.22 has been around even longer. If we were to keep it to *only* blockers, then again it would be a fairly useless release due to the number of non-blocker bugs. Clearly there's a balance and a judgment call when moving things back to a branch. But at this point I'd consider small improvements and pretty much any bug fix to be reasonable, so long as it doesn't involve major reworking of components. Nigel: if this assumption doesn't jive (ha ha, get it?) with what you're thinking, please let me know :) -Todd On Wed, Jun 1, 2011 at 1:50 PM, Eric Baldeschwieler eri...@yahoo-inc.com wrote: makes sense to me, but it might be good to work to make these decisions visible so folks can understand what is happening. On Jun 1, 2011, at 1:46 PM, Owen O'Malley wrote: On Jun 1, 2011, at 1:27 PM, Suresh Srinivas wrote: I see that there are several non blockers being promoted to 0.22 from trunk. From my understanding, any non blocker change to 0.22 should be approved by vote. Is this correct? No, the Release Manager has full control over what goes into a release. The PMC votes on it once there is a release candidate. -- Owen -- Todd Lipcon Software Engineer, Cloudera -- Todd Lipcon Software Engineer, Cloudera
Re: Update on 0.22
I can see them well. I think Suresh's point is that non-blockers are going into 0.22. Nigel, do you have full control over it? Thanks, --Konstantin On Wed, Jun 1, 2011 at 1:50 PM, Eric Baldeschwieler eri...@yahoo-inc.comwrote: makes sense to me, but it might be good to work to make these decisions visible so folks can understand what is happening. On Jun 1, 2011, at 1:46 PM, Owen O'Malley wrote: On Jun 1, 2011, at 1:27 PM, Suresh Srinivas wrote: I see that there are several non blockers being promoted to 0.22 from trunk. From my understanding, any non blocker change to 0.22 should be approved by vote. Is this correct? No, the Release Manager has full control over what goes into a release. The PMC votes on it once there is a release candidate. -- Owen
Re: Update on 0.22
On Wed, Jun 1, 2011 at 11:32 PM, Konstantin Shvachko shv.had...@gmail.comwrote: I can see them well. I think Suresh's point is that non-blockers are going into 0.22. Nigel, do you have full control over it? Of course it's up to Nigel to decide, but here's my personal opinion: One of the reasons we had a lot of divergence (read: external branches/forks/whatever) off of 0.20 is that the commit rules on the branch were held pretty strictly. So, if you wanted a non-critical bug fix or a small improvement, the only option was to do such things on an external fork. 0.20 was branched in December '08 and not released until mid April '09. In 4 months a fair number of bug fixes and small improvements go in. 0.22 has been around even longer. If we were to keep it to *only* blockers, then again it would be a fairly useless release due to the number of non-blocker bugs. Clearly there's a balance and a judgment call when moving things back to a branch. But at this point I'd consider small improvements and pretty much any bug fix to be reasonable, so long as it doesn't involve major reworking of components. Nigel: if this assumption doesn't jive (ha ha, get it?) with what you're thinking, please let me know :) -Todd On Wed, Jun 1, 2011 at 1:50 PM, Eric Baldeschwieler eri...@yahoo-inc.com wrote: makes sense to me, but it might be good to work to make these decisions visible so folks can understand what is happening. On Jun 1, 2011, at 1:46 PM, Owen O'Malley wrote: On Jun 1, 2011, at 1:27 PM, Suresh Srinivas wrote: I see that there are several non blockers being promoted to 0.22 from trunk. From my understanding, any non blocker change to 0.22 should be approved by vote. Is this correct? No, the Release Manager has full control over what goes into a release. The PMC votes on it once there is a release candidate. -- Owen -- Todd Lipcon Software Engineer, Cloudera
Re: Update on 0.22
I propose just to make them blockers before committing to attract attention of the release manager and get his approval. Imho, even small changes, like HDFS-1954 are blockers, because a vague UI message is bug and bugs are blockers. Thanks, --Konstantin On Thu, Jun 2, 2011 at 10:39 AM, Todd Lipcon t...@cloudera.com wrote: On Wed, Jun 1, 2011 at 11:32 PM, Konstantin Shvachko shv.had...@gmail.comwrote: I can see them well. I think Suresh's point is that non-blockers are going into 0.22. Nigel, do you have full control over it? Of course it's up to Nigel to decide, but here's my personal opinion: One of the reasons we had a lot of divergence (read: external branches/forks/whatever) off of 0.20 is that the commit rules on the branch were held pretty strictly. So, if you wanted a non-critical bug fix or a small improvement, the only option was to do such things on an external fork. 0.20 was branched in December '08 and not released until mid April '09. In 4 months a fair number of bug fixes and small improvements go in. 0.22 has been around even longer. If we were to keep it to *only* blockers, then again it would be a fairly useless release due to the number of non-blocker bugs. Clearly there's a balance and a judgment call when moving things back to a branch. But at this point I'd consider small improvements and pretty much any bug fix to be reasonable, so long as it doesn't involve major reworking of components. Nigel: if this assumption doesn't jive (ha ha, get it?) with what you're thinking, please let me know :) -Todd On Wed, Jun 1, 2011 at 1:50 PM, Eric Baldeschwieler eri...@yahoo-inc.com wrote: makes sense to me, but it might be good to work to make these decisions visible so folks can understand what is happening. On Jun 1, 2011, at 1:46 PM, Owen O'Malley wrote: On Jun 1, 2011, at 1:27 PM, Suresh Srinivas wrote: I see that there are several non blockers being promoted to 0.22 from trunk. From my understanding, any non blocker change to 0.22 should be approved by vote. Is this correct? No, the Release Manager has full control over what goes into a release. The PMC votes on it once there is a release candidate. -- Owen -- Todd Lipcon Software Engineer, Cloudera
Re: Update on 0.22
On Jun 2, 2011, at 11:06 AM, Konstantin Shvachko wrote: I propose just to make them blockers before committing to attract attention of the release manager and get his approval. The traditional response has almost always been that they get changed to non-blockers before release. One person's blocker is another person's issue to ignore.
Re: Update on 0.22
On Thu, Jun 2, 2011 at 11:06 AM, Konstantin Shvachko shv.had...@gmail.comwrote: I propose just to make them blockers before committing to attract attention of the release manager and get his approval. Imho, even small changes, like HDFS-1954 are blockers, because a vague UI message is bug and bugs are blockers. Bugs are blockers? Then we'll never release! Let's hear from Nigel what he thinks. It's his branch, if he's upset about the way it's being handled, he can deal with it as he sees fit. -Todd On Thu, Jun 2, 2011 at 10:39 AM, Todd Lipcon t...@cloudera.com wrote: On Wed, Jun 1, 2011 at 11:32 PM, Konstantin Shvachko shv.had...@gmail.comwrote: I can see them well. I think Suresh's point is that non-blockers are going into 0.22. Nigel, do you have full control over it? Of course it's up to Nigel to decide, but here's my personal opinion: One of the reasons we had a lot of divergence (read: external branches/forks/whatever) off of 0.20 is that the commit rules on the branch were held pretty strictly. So, if you wanted a non-critical bug fix or a small improvement, the only option was to do such things on an external fork. 0.20 was branched in December '08 and not released until mid April '09. In 4 months a fair number of bug fixes and small improvements go in. 0.22 has been around even longer. If we were to keep it to *only* blockers, then again it would be a fairly useless release due to the number of non-blocker bugs. Clearly there's a balance and a judgment call when moving things back to a branch. But at this point I'd consider small improvements and pretty much any bug fix to be reasonable, so long as it doesn't involve major reworking of components. Nigel: if this assumption doesn't jive (ha ha, get it?) with what you're thinking, please let me know :) -Todd On Wed, Jun 1, 2011 at 1:50 PM, Eric Baldeschwieler eri...@yahoo-inc.com wrote: makes sense to me, but it might be good to work to make these decisions visible so folks can understand what is happening. On Jun 1, 2011, at 1:46 PM, Owen O'Malley wrote: On Jun 1, 2011, at 1:27 PM, Suresh Srinivas wrote: I see that there are several non blockers being promoted to 0.22 from trunk. From my understanding, any non blocker change to 0.22 should be approved by vote. Is this correct? No, the Release Manager has full control over what goes into a release. The PMC votes on it once there is a release candidate. -- Owen -- Todd Lipcon Software Engineer, Cloudera -- Todd Lipcon Software Engineer, Cloudera
Re: Update on 0.22
Nigel, I see that there are several non blockers being promoted to 0.22 from trunk. From my understanding, any non blocker change to 0.22 should be approved by vote. Is this correct? Regards, Suresh On 5/25/11 11:46 PM, Nigel Daley nda...@mac.com wrote: Looks like we're down to 12 blockers on 0.22. * Thanks to Cloudera for hosting a couple hack-a-thons over the past couple of weeks which helped get this number down. * Thanks to Devaraj Das for volunteering to get https://issues.apache.org/jira/browse/MAPREDUCE-2178 committed. * Thanks to Tom White for getting a CI build running that creates the actual release artifact. I'm planning to commit https://issues.apache.org/jira/browse/HADOOP-7106 (SVN reorg) this Friday at 2pm PDT. Todd, were you able to test git history based on your svn dump and import? Cheers, Nige
Re: Update on 0.22
On Jun 1, 2011, at 1:27 PM, Suresh Srinivas wrote: I see that there are several non blockers being promoted to 0.22 from trunk. From my understanding, any non blocker change to 0.22 should be approved by vote. Is this correct? No, the Release Manager has full control over what goes into a release. The PMC votes on it once there is a release candidate. -- Owen
Re: Update on 0.22
makes sense to me, but it might be good to work to make these decisions visible so folks can understand what is happening. On Jun 1, 2011, at 1:46 PM, Owen O'Malley wrote: On Jun 1, 2011, at 1:27 PM, Suresh Srinivas wrote: I see that there are several non blockers being promoted to 0.22 from trunk. From my understanding, any non blocker change to 0.22 should be approved by vote. Is this correct? No, the Release Manager has full control over what goes into a release. The PMC votes on it once there is a release candidate. -- Owen
Re: Update on 0.22
On Jun 1, 2011, at 1:50 PM, Eric Baldeschwieler wrote: makes sense to me, but it might be good to work to make these decisions visible so folks can understand what is happening. lol
Re: Update on 0.22
I'm starting this now. Nige On May 25, 2011, at 11:46 PM, Nigel Daley wrote: I'm planning to commit https://issues.apache.org/jira/browse/HADOOP-7106 (SVN reorg) this Friday at 2pm PDT. Todd, were you able to test git history based on your svn dump and import? Cheers, Nige
Re: Update on 0.22
I had to call this off as the auth and email patch was out of date. I'll reschedule for next Friday at 2pm. Nige On May 27, 2011, at 2:45 PM, Nigel Daley wrote: I'm starting this now. Nige On May 25, 2011, at 11:46 PM, Nigel Daley wrote: I'm planning to commit https://issues.apache.org/jira/browse/HADOOP-7106 (SVN reorg) this Friday at 2pm PDT. Todd, were you able to test git history based on your svn dump and import? Cheers, Nige
Update on 0.22
Looks like we're down to 12 blockers on 0.22. * Thanks to Cloudera for hosting a couple hack-a-thons over the past couple of weeks which helped get this number down. * Thanks to Devaraj Das for volunteering to get https://issues.apache.org/jira/browse/MAPREDUCE-2178 committed. * Thanks to Tom White for getting a CI build running that creates the actual release artifact. I'm planning to commit https://issues.apache.org/jira/browse/HADOOP-7106 (SVN reorg) this Friday at 2pm PDT. Todd, were you able to test git history based on your svn dump and import? Cheers, Nige
