Andrew, I agree if a new patch under discussion and a commit was made -- bad form to commit.
However, a revert within 24 hours seems reasonable, especially if done by the original committer. A revert is done to undo harm (failed build, massive test failures, or serious bug found with nontrivial effort to repair). Personally, I'd rather have a bad commit, a revert and then a single clean commit (even if this last one came a few days later) instead of a bad commit, and then a series of addendums that come a few days later. Jon. On Mon, Feb 11, 2013 at 7:20 PM, Andrew Purtell <[email protected]> wrote: > I'm also concerned that the revert happened here while discussion was > ongoing. Given the latest comments on the issue, this could have been > handled by a new issue that replaces the offending code with reflection. I > don't care about the revert per se but would ask we avoid making changes > out from under a discussion until the matter is resolved with consensus. We > will have cleaner revision history and less churn overall as a result. I > know many of us have to-do lists of HBase JIRAs to retire, but there is no > need to be hasty. Because we are all busy, unnecessary commit speed makes > it more likely mistakes like this will slip by review in the first place > too. > > For your consideration. > > > On Mon, Feb 11, 2013 at 5:40 PM, Ted <[email protected]> wrote: > >> No. >> The release was cut before the revert. >> >> On Feb 11, 2013, at 5:35 PM, Enis Söztutar <[email protected]> wrote: >> >> > I was going to +1 the release, with the following checks I did: >> > - Checked md5 sums >> > - Checked gpg signature (gpg --verify ) >> > - Checked included documentation book.html, etc. >> > - Running unit tests (passed on unsecure, secure) >> > - Started in local mode, run LoadTestTool >> > - integration tests (not working fully properly, but expected since >> > HBASE-7521 is not in yet) >> > >> > I guess this means that the release candidate has sunk, right? >> > Enis >> > >> > >> > >> > On Mon, Feb 11, 2013 at 4:59 PM, Stack <[email protected]> wrote: >> > >> >> Good catch Jon. >> >> >> >> We need to be vigilant here all. >> >> >> >> Incompatibilities cost users and those following behind us as they burn >> >> cycles doing gymnastics trying to get over the incompatibility -- if it >> is >> >> possible to get over the incompatibility at all. They make us look bad. >> >> Worse, usually the incompatibility is found months later after we have >> all >> >> moved on and have long forgot what it was we committed (and even why) so >> >> all the more reason to be on the look out at commit time. >> >> >> >> St.Ack >> >> >> >> >> >> On Mon, Feb 11, 2013 at 4:48 PM, Jonathan Hsieh <[email protected]> >> wrote: >> >> >> >>> Apache Hat: What a particular vendor chooses to puts in its releases >> >>> shouldn't affect an Apache release and especially if we are breaking >> >>> the >> >>> project's versioning / compatibility rules. >> >>> >> >>> Jon. >> >>> >> >>> On Mon, Feb 11, 2013 at 4:32 PM, Ted Yu <[email protected]> wrote: >> >>>> I downloaded hadoop-0.20.2+737 from Cloudera website. >> >>>> >> >>>> I found getShortUserName() in UserGroupInformation >> >>>> >> >>>> Haven't checked other 0.20.x source code yet. >> >>>> >> >>>> FYI >> >>>> >> >>>> On Mon, Feb 11, 2013 at 4:24 PM, Jonathan Hsieh <[email protected]> >> >>> wrote: >> >>>> >> >>>>> Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94 that >> >>>>> makes HBase 0.94 now require Hadoop 1.0 (instead of the older >> >>>>> hadoops). This was supposed to be a new requirement for hbase >> 0.96.0. >> >>>>> [2] >> >>>>> >> >>>>> Are we ok with making the next 0.94 upgrade incompatible? (And if >> we >> >>>>> are we need to release note this kind of stuff). >> >>>>> >> >>>>> Jon. >> >>>>> >> >>>>> [1] https://issues.apache.org/jira/browse/HBASE-7814 >> >>>>> >> >>>>> [2] >> >> >> http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3ccadcmmghtqx73jzte4schy04iqs9npzp3u84hm2sm7icl6r8...@mail.gmail.com%3E >> >>>>> >> >>>>> >> >>>>> On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <[email protected]> >> >>> wrote: >> >>>>>> The backporting situation for 0.94 is an exception it seems, because >> >>> of >> >>>>> the >> >>>>>> fact that 96 is so late. But until 96 comes out, we can keep up the >> >>>>> current >> >>>>>> approach. It has worked mostly for the time being. >> >>>>>> >> >>>>>> Enis >> >>>>>> >> >>>>>> >> >>>>>> On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <[email protected] >> >>> >> >>>>> wrote: >> >>>>>> >> >>>>>>> That said, let's make sure every backport has meaningful >> >>> justification >> >>>>>>> (determined by consensus). >> >>>>>>> >> >>>>>>> >> >>>>>>> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell < >> >> [email protected]> >> >>>>>>> wrote: >> >>>>>>> >> >>>>>>>> -1 until we have an actual stable 0.96 release. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <[email protected] >> >>> >> >>>>> wrote: >> >>>>>>>> >> >>>>>>>>> Lately there have been a lot of issues being committed to trunk >> >>> and >> >>>>>>>>> also back-ported to 0.94 (I've done it myself too). Since we're >> >>> so >> >>>>> far >> >>>>>>>>> into 0.94's release cycle should we think about not allowing >> >> minor >> >>>>>>>>> features >> >>>>>>>>> and code clean ups to be back-ported ? >> >>>>>>> >> >>>>>>> -- >> >>>>>>> Best regards, >> >>>>>>> >> >>>>>>> - Andy >> >>>>>>> >> >>>>>>> Problems worthy of attack prove their worth by hitting back. - Piet >> >>> Hein >> >>>>>>> (via Tom White) >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> // Jonathan Hsieh (shay) >> >>>>> // Software Engineer, Cloudera >> >>>>> // [email protected] >> >>> >> >>> >> >>> >> >>> -- >> >>> // Jonathan Hsieh (shay) >> >>> // Software Engineer, Cloudera >> >>> // [email protected] >> >> >> > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) -- // Jonathan Hsieh (shay) // Software Engineer, Cloudera // [email protected]
