#musicbrainz-devel

earlier in the UI design phase we identified a few use cases.

the simplest being the task of adding a single artist release in using the track parser method

since that will cover 90% of the use of the RE we need to makes sure that that path is adequately covered.

and I would like to see warp write tests that cover all of the functions of this simple use case.

ruaok: right now, one of the issues still remaining (feature-wise) is that either ocharles or I have to add skipping pages to the wizard

so, that when we update the RE on test, we can be certain that we didn't break the most basic use case.

so, that when someone like ijabz_ comes along he shouldn't get the impression that we've not tested anything.

ruaok: so that the 'duplicate releases' and 'add missing entities' tab are skipped when they're not needed. 'recordings' probably too.

(oh no, not recordings, nm)

warp: do you have a ticket for that?

hm, probably not.

please add a ticket for that and put it on CI for this week.

ok

how does what I outline sound for a new approach to the RE?

+d

I entered a ticket for skipping missing entities at least

well, it's what me and warp have wanted for a long time, but have never had a solution to do it

so yea, I think we're all on the same page

and the focus on the basic use case? ok with that?

ruaok: I'm not sure what exactly you mean with 'focus on use cases'.

mainly that we get a use case taken care of and working really well.

ruaok: well, i think it should be use cases + bug reports

so that when someone tries to use it in a simple case, they dont walk away flummoxed.

which I have several times.

neither me nor warp are best suited for determining the use cases to test though, the community would probably be better to tell us what those are

then when all the features pertaining to a particular use case have been covered, we can work on bugs that related to the next use case.

ocharles: I see that.

still not entirely clear on what you're asking. you want use to spend time (outside of current jira tickets) testing the release editor and adding tickets to jira for the issues we find?

I think we've already defined them in the UX phase of our work.

or you want me to create selenium tests for those use cases?

warp: no.

selenium yes.

its mostly a method for giving you more focus.

meaning that I don't want you to work on any bugs that are not related to the current use case at hand.

aaah

so, the process going forward should be:

1. create selenium test cases for a base set of tests.

2. define use cases.

warp has changed the topic to: Agenda: Reviews, MBS-1501 (/ws/2/collection), interface testing, release editor testing, smolder

3. pick a use case to focus on.

4. find bugs that related to use case.

5. fix bugs related to use case.

ocharles has changed the topic to: Agenda: Reviews, MBS-1501 (/ws/2/collection), interface testing, release editor testing, smolder, MBS-1507

6. extend selenum to include tests for the fixed bugs.

7. if use case not fully covered, go back to 4.

ok, understood.

so basically test driven design

or "use case driven design"

test driven jira ticket selection

:)

use case driven test drive design.

+n

I think we're all on the same page now. :)

the main idea is that we need to instill confidence in others that we know what we're doing and that we actually have a plan with the RE.

its become painfully clear that the RE is our ciritcal path to NGS.

and thus it needs a lot of attention.

I'll spend some time looking and and defining our use cases after the meeting.

onward to smolder?

yes

all these tests are pointless if they're not being run.

so I want to start setting up continuous integration stuff on hobbes (as I promised ages ago)

smolder seems the most viable option right now, as it is written in perl and understands TAP output

ruaok: shall I just start setting that stuff up on hobbes as I see fit?

sure, why not?

just checking :)

k

hobbes has been ready for yo.

+u

that all for this agenda item?

ocharles: MBS-1507.

you have 2 minutes. go!

http://jira.musicbrainz.org/browse/MBS-1507 see my comment

I will be swapping with alex this weekend or next weeked, so my private time may become a bit hectic. so I can't make any promises on when I start moving on that, but I'll try to get it running ASAP.

agree with ocharles

ok

what if we redirect only on a single hit that is 95% of better confidence?

(I find them to be confusing on the current server too :)

ruaok: based on lucenes idea of confidence?

a lot of people whined when we didn't have them on the search server.

ocharles: yes.

and never redirect for direct searches?

if lucene is really confident, redirect.

it seems to give a one out of two word match "100" on test

mind you, postgres does have basic ranking, but it's not particularly impressive

direct searches are less likely to have done funky matches.

postgres ranking is relative to the other search results, it's useless when considered without that context.

we could try to do a case insensitive string compare there.

Score of 100 doenst really equate to exact match

direct searches are usually fine, they search for every word, so you don't get A B matching A C

it's the indexed search that's the problem, since A B *does* match A C

if we really must redirect, the string compare sounds fine.

you could do simple text match on result on mbserver if you really want to keep redirect

that actually sounds pretty sane.

its a narrow margin of times that is going to fire.

simple text matching is not that simple though...

ocharles: who cares?

if its too tight it doesn't redirect.

as in it will probably never redirect

and for the *correct* cases it will.

ocharles: why not?

ocharles: it will.

ocharles: if I type "the beatles", why would it not redirect to the beatles?

if the search query is exact to the result, then it will.

warp: because that will give more than one result probably anyway

and that is what people want.

yeah, you get search results now

e.g. http://musicbrainz.org/search/textsearch.html?q...

ocharles: if the user gives a crappy query, thats their problem.

oh right

you have to have an artist where every word is unique for it to redirect

and I think that works fine.

anyone oppose the "case insensitive string compare" fix?

i see that as inconsistent

s/the beatles/autechre/ then.

:)

lol

(reeber artist query is funny becaue matching artist, alias ecetera)

ocharles: how is that inconsistent?

dammit. collab artists.

I'd like to run this past someone with UI interaction experience first

warp: see! :P

ruaok: because to me as a user, sometimes it redirects, sometimes I get one result

s/autechre/BESPA KUMAMERO/

that's why I don't think it's a problem to remove the redirects, the vast majority of queries don't return only one artist any more

nikki: if we remove them, people will bitch and then we're going to add them back in.

maybe this needs to be discussed more openly

because no consensus is being approached here

sure, if we want to ensure that we never ship NGS.

"removing redirects" or "redirect on exact string match only", both those options are perfectly fine with me.

fine fuck it.

remove it.

lol

if someone bitches, and they will, we can fix it after NGS.

just no more open discussions for little shit like this.

srsly. we gotta ship some time.

:D

ruaok, one more thing

shoot

Theres alot of jira issues not allocated to a compoent, I worry they are getting lost in the ether

ijabz_: as long as they are assigned to a person.

I think we just talked about that last week.

yeah, that was the result.