On 22 Mar 2010, at 04:12, Noah Slater wrote: > So, are we officially good to go? > > Can I upload the artefact from the current tag, or do I need to retag the > 0.11.x branch?
You'll need to re-tag. Are you not on comm...@? :) Cheers Jan -- > > Thanks. > > On 21 Mar 2010, at 19:00, Jan Lehnardt wrote: > >> >> On 21 Mar 2010, at 13:38, Robert Dionne wrote: >> >>> Ok Noah, This is only a test case issue, and not in the changes code as I >>> though. Jan found the issue and it works fine for me now in both FF and >>> CLI. -- Bob >> >> As an added bonus, the test suite should now work 100% in WebKit (for me at >> least :) >> >> Cheers >> Jan >> -- >> >> >>> >>> >>> On Mar 21, 2010, at 1:30 PM, Jan Lehnardt wrote: >>> >>>> >>>> On 21 Mar 2010, at 12:24, Robert Dionne wrote: >>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mar 21, 2010, at 1:16 PM, Jan Lehnardt wrote: >>>>> >>>>>> >>>>>> On 21 Mar 2010, at 12:10, Noah Slater wrote: >>>>>> >>>>>>> What are the CLI tests, if not the etap tests? Are they integrated into >>>>>>> the build system? >>>>>> >>>>>> The CLI tests are the same as the browser tests, just run through our >>>>>> couchjs binary >>>>>> that has custom HTTP extensions to make the xhr work. At this point I >>>>>> don't think it >>>>>> is reliable enough to mimic browser behaviour and that we shouldn't use >>>>>> it for vetting >>>>>> the state of the code. >>>>> >>>>> This is likely true, but in this particular case I think there's a bug in >>>>> the changes code (that I'm trying to dig out). It's nice that it works on >>>>> your machine but on my machine, using FF, it fails often enough. Moreover >>>>> it's been around for a long time now so I figure it's worth figuring out. >>>>> >>>>> I don't have a dog in this fight (.ie. a paying customer) so this failure >>>>> doesn't bother me. With respect to policy, given the various bogocities >>>>> of browsers, I'd recommend something like these CLI tests plus the etaps >>>>> ought to be the "official" tests for vetting, and part of the build >>>> >>>> Not that I disagree, but part (most?) of the appeal of the browser based >>>> tests are that they run in a real-world client instead of the lab that is >>>> couchjs+http :) >>>> >>>> Cheers >>>> Jan >>>> -- >>>> >>>>> >>>>> >>>>>> >>>>>> It is very useful when developing new code to not have to switch to and >>>>>> reload the >>>>>> browser over and over again. >>>>>> >>>>>> Cheers >>>>>> Jan >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> On 21 Mar 2010, at 17:05, Jan Lehnardt wrote: >>>>>>> >>>>>>>> >>>>>>>> On 21 Mar 2010, at 06:04, Robert Dionne wrote: >>>>>>>> >>>>>>>>> On Mar 21, 2010, at 4:00 AM, Jan Lehnardt wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 20 Mar 2010, at 20:06, Paul Davis wrote: >>>>>>>>>> >>>>>>>>>>> On Sat, Mar 20, 2010 at 2:31 PM, Noah Slater <[email protected]> wrote: >>>>>>>>>>>> I think faulty test case should block the release, if I am to have >>>>>>>>>>>> any >>>>>>>>>>>> future sanity preparing releases. I don't want to delay and >>>>>>>>>>>> longer, so if >>>>>>>>>>>> you guys are absolutely sure this is a test error and not code >>>>>>>>>>>> error, then I >>>>>>>>>>>> propose that the test be commented out. Our tests form a contract >>>>>>>>>>>> between >>>>>>>>>>>> us, internally, and our users. If that contract has a bug, it >>>>>>>>>>>> should be >>>>>>>>>>>> removed or fixed - or it simply dilutes the importance of >>>>>>>>>>>> contract. If some >>>>>>>>>>>> one comments out the test, and we agree it is not indicative of an >>>>>>>>>>>> important >>>>>>>>>>>> bug, I can call the vote within hours. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'd have to agree on this. From the point of view of a release, if a >>>>>>>>>>> test reports a failure then it should be made to not report a >>>>>>>>>>> failure. >>>>>>>>>>> If that's accomplished by disabling it, then there will be a commit >>>>>>>>>>> with a message that explains why it was disabled and etc and such on >>>>>>>>>>> and so forth. >>>>>>>>>> >>>>>>>>>> I'd do that if the test was failing for me :) >>>>>>>>> >>>>>>>>> it's not failing for you when you run changes.js with the CLI ? >>>>>>>>> Fails for me every time. >>>>>>>> >>>>>>>> I don't consider the CLI tests as part of the official test suite just >>>>>>>> yet. >>>>>>>> >>>>>>>> Cheers >>>>>>>> Jan >>>>>>>> -- >>>>>>>> >>>>>>>>> >>>>>>>>> Anyway I poked at this a bit yesterday and am not 100% sure the issue >>>>>>>>> is in the test. I tried putting a sleep in with no luck. If my >>>>>>>>> understanding of the JS is correct, CouchDB is supposed to be >>>>>>>>> synchronous so it's not timing. >>>>>>>>> >>>>>>>>> If someone could comment on the test itself it would be helpful. The >>>>>>>>> section of the code that fails: >>>>>>>>> >>>>>>>>> // changes get all_docs style with deleted docs >>>>>>>>> var doc = {a:1}; >>>>>>>>> db.save(doc); >>>>>>>>> db.deleteDoc(doc); >>>>>>>>> var req = CouchDB.request("GET", >>>>>>>>> "/test_suite_db/_changes?filter=changes_filter/bop&style=all_docs"); >>>>>>>>> var resp = JSON.parse(req.responseText); >>>>>>>>> TEquals(3, resp.results.length, "should return matching rows"); >>>>>>>>> >>>>>>>>> >>>>>>>>> seems odd to me. all_docs as I read the code will return docs with >>>>>>>>> deletes and conflicts but in this call the filter bop will not apply >>>>>>>>> to the doc {a:1} so I'm not sure what this delete prior to the call >>>>>>>>> is about. Anyway I can make it fail in the debugger so perhaps I can >>>>>>>>> find the root cause. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cheers >>>>>>>>>> Jan >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
