#musicbrainz-devel

where is this discussion happening? I can jump in.

me neither

no, just worked with warp on search server and looked at latest lucene update

ruaok: It's been happening on IRC in spurts over the last few days.

I was having fun reading some audio fingerrinting papers :)

luks: you call that fun?

luks: are you familiar with jhears?

not really

might be wiorth looking at.

I just discovered the Waveprint paper from Google Research

and it seems to simple

its an open implementation that is friendly towards MB.

that I got interested in playing with it

got link?

MBChatLogger: off

is not logging

is logging

anyone else have anything for review?

ruaok has changed the topic to: agenda: estimating tickets, review granularity, clean markup, artist i18n, script detecting

ok, the next issue is one of the things that I hinted as as being hard to deal with between paid and volunteer programmers.

I'm trying to get our dev team to be able to make a realistic schedule and stick to it.

not only our customers appreciate that, but our community does too.

the idea was to make tickets unassigned so that there is an open pool of tickets to choose from.

but we've use the model to accept a ticket, and estimate it so that we can keep a schedule going forward.

the two clash horribly.

anyone have any ideas on this front?

or reactions?

If you want time estimates, what we have now works best, imo

people just have to feel confident to steal tickets away

as you mentioned

is it possible to estimate tickets roughly without accepting them, or are acid2's and warp's estimates totally different?

yeah, I'm not sure this is welcoming enough.

How about only high priority/major tasks get assigned to a dev (and timed), all the smaller stuff and nitpicking improvements stay unassigned for anyone else to pick up.

nikki: atm, fairly different

what navap said was what I was about to say next :P

:)

yea, I think some tickets have to have an owner, or they just won't get done, because i'll avoid them and work on fun tickets instead :P

navap: that might be tricky. some volunteers (like luks) like to take HUGE tickets, strap on the rocket pack and go for a ride.

very true

if aCiD2 and I just take responsibility for a certain components, we could just estimate those tickets without them being assigned

ruaok: Sure, but there aren't too many luks' around are there. And the random times that happen, I'm sure we can deal with it.

well, I think I'm going to leave this as an open issue for now. see if we can come up with some more ideas over time.

navap: yeah, I guess.

this is going to be a trciky thing to deal with, regardless.

aCiD2, warp:

why dont you guys just make time estimates and then reassign the issues to no one?

it would be an improvement for people who've not done anything with mb before, since they're most likely to pick the minor, easy to fix things

unless you want to keep the issue for yourself, in which case, do that.

luciddrmr: are those estimates meaningful?

once they are floating in the ether that is

acid2: i think any estimation is better than none. especially if done by one of you

true

you guys have a sense of how long these things take

that's pretty much what I was suggesting, you can always update the estimate later if it's wrong, can't you?

right now warp and aCiD2 code at different speeds, but that will level our over time.

kind of makes a bit of your job adminstrative, but ruoak could pitch in and do some of it too

then the question becomes this: whose job is it to estimate a task?

I'd like to avoid spending yet more time in JIRA plugging numbers in

I could see it falling between the cracks when no one takes ownership.

nikki: and if it's not our component?

ruaok: assign different components to different people, e.g. I get release editor and webservice.

I see the best solution is that whoever sees the task first estimates it

whoever's component it is is responsible then

if someone actually thinks "oh, i'll do that!" they can take it and restimate

oh. what if we do this:

use the component owner to decide who owns the ticket.

i think if you are a person who knows how long task X should take and you see it doesn't have a time estimate, then you can estimate for task X

er. who estimates the ticket.

once the ticket is estimated by the default owner, its assigned to no one.

that way its clear who should do the estimating.

how does that sound?

ruaok: that was what I was suggesting, so sounds good to me :P

good, but...

oh, sorry, misunderstood you then. :)

we need to clear up JIRA emails a bit. If I got emailed about my own tickets and my components tickets, this is fine - I know all emails concern me. But if I get flooded with every ticket in JIRA (as is atm), I'll end up missing some things

but hopefully that's not too hard to setup

aCiD2: can you look to see if you can tweak that?

ok

and then get back to me?

this suggestion is the best way forward I've heard so far. so lets leave the on the table for now and see if we can decide this in this week.

thanks for all the suggestions!

ok, next.

right now I am seeing a *lot* of reviews in CR.

is that granularity good or should we say that simple fixes ought to not get reviewed?

I think this granularity is good

I'm very happy with it atm, rarely does a fix need to be commited asap

warp, luks: thoughts?

ruaok: maybe very very simple fixes shouldn't be reviewed. but as the new guy, I get a fair amount of feedback, so it's definitely good that everything I do ends up on reviewboard for the time being.

ok, sounds like we should keep doing it for the time being. if it gets tedious in a month or so we'll revisit.

I think the moment you say "don't review simple fixes" you introduce another problem - what's simple? I might think it's simple, but that's because I didn't do it right and broke a load of stuff

IMO the most important thing is whereever possible every change has a unit test, does that happen

ijabz: 50/50 atm probably

but we're still at a stage where we have to clarify exactly how things work, it's awkward to unit change something that wasn't done right in the first place (a bit tricky to explain)

Because with just code reviews you are asking someone else to spot your mistakes

but genearlly yea- I agree with you, new features or clear bugs should have unit tests

ijabz: currently lots of interface things don't get unittests, most of the data changes do. from what I see.

ijabz: asking for another set of eyes, it's no excuse to write sloppy code :)

How do you have a unittest for a UI bug fix?

navap: some are testable, we have some tests for them

ruaok has changed the topic to: agenda: unit tests, clean markup, artist i18n, script detecting

navap: most interface changes test if the data is there, not how it is display. that's good enough I think.

but CSS stuff aren't realistically testable

as with typos and other stuff

Sure, dosnt really work for UI bug fixes

but they are less critical/dangeous

I would suggest unit tests for anything that aren't strictly UI - so the GC engine would have them, the track parser would have them, but the RE's UI itself wouldn't, since UI stuff unit tests can be quite difficult to code, and essentially you end up writing a test for existing code, rather than a test in advance of writing the code.

warp: clean markup!

The point Im trying to make is there has been lots of talk about code review over the last few months, but not that much about unit testing

agenda: clean markup, artist i18n, script detecting

ijabz: pretty much because that's just done, so it's not much of a topic :)

ijabz: that is because the unit testing is already happening for things we can test easily.

ruaok: when writing javascript, I'm very used to already rendering stuff in the markup with <tag style="display:none">, and then just enabling/disableing that with .show() and .hide()

ruaok has changed the topic to: agenda: clean markup, artist i18n, script detecting

thats good then ;)

ruaok: those elements obviously display for people without css, and it isn't technically clean markup because you're sending out stuff which shouldn't be displayed

ruaok: luks' objected to that, so I'm wondering how clean we should keep that markup

i'm pretty much in with luks here too - provide enough markup to easily generate these elements

but I think brianfreud_ is more with you :)

Only so far as it impacts performance significantly

warp: if you need html like that, do it from javascript

ruaok: note that in this particular case it concerns the tooltips, which are easily made translated in the templates, but much harder in javascript.

provide enough markup, what do you mean?

I think the html output from he server should be as clean as possible

ruaok: for example, you want to make an input field fancy. Just have the <input> in the html, and add fanciness with javascript on page load

ah

warp: I don't think translation is a huge issue anymore, we have a text javascript file that's a TT file and can be translated as normal

you just have to remember to store/lookup strings through it

aCiD2: ok

also

w td to be inserted and rendered, even if you hid the table while doing it)

when I was rethinking about how to write JavaScript, I think I'd kill that whole MB.html thing, and just add String.template prototype, so you can do "<input id="#{foo}">".expand({ foo: 'yay-id' }) -- but that's up to you ofc

ugh, please please please don't touch the native prototypes! :D

brianfreud_: We don't have those kinds of tables anymore though.

speaking of translations, js-gettext is pretty easily implemented if needed, so no problem there

navap: that's why I say I'd only suggest moving that type of html to the server if it's a significant performance killer

aCiD2: yes, if the markup has to be clean, I'll probably use some little templating engine.

kewl

ruaok: well, most seem to think clean markup is more important. I'll go with that.

ok, motion carried. :)