where is this discussion happening? I can jump in.
2010-03-01 06028, 2010
nikki
me neither
2010-03-01 06042, 2010
ijabz
no, just worked with warp on search server and looked at latest lucene update
2010-03-01 06042, 2010
navap
ruaok: It's been happening on IRC in spurts over the last few days.
2010-03-01 06048, 2010
luks
I was having fun reading some audio fingerrinting papers :)
2010-03-01 06000, 2010
ruaok
luks: you call that fun?
2010-03-01 06011, 2010
ruaok
luks: are you familiar with jhears?
2010-03-01 06017, 2010
luks
not really
2010-03-01 06029, 2010
ruaok
might be wiorth looking at.
2010-03-01 06034, 2010
luks
I just discovered the Waveprint paper from Google Research
2010-03-01 06037, 2010
luks
and it seems to simple
2010-03-01 06042, 2010
ruaok
its an open implementation that is friendly towards MB.
2010-03-01 06049, 2010
luks
that I got interested in playing with it
2010-03-01 06050, 2010
ruaok
got link?
2010-03-01 06059, 2010
ruaok
MBChatLogger: off
2010-03-01 06059, 2010
MBChatLogger
is not logging
2010-03-01 06046, 2010
MBChatLogger
is logging
2010-03-01 06058, 2010
ruaok
anyone else have anything for review?
2010-03-01 06018, 2010
ruaok
ruaok has changed the topic to: agenda: estimating tickets, review granularity, clean markup, artist i18n, script detecting
2010-03-01 06042, 2010
ruaok
ok, the next issue is one of the things that I hinted as as being hard to deal with between paid and volunteer programmers.
2010-03-01 06001, 2010
ruaok
I'm trying to get our dev team to be able to make a realistic schedule and stick to it.
2010-03-01 06013, 2010
ruaok
not only our customers appreciate that, but our community does too.
2010-03-01 06034, 2010
ruaok
the idea was to make tickets unassigned so that there is an open pool of tickets to choose from.
2010-03-01 06053, 2010
ruaok
but we've use the model to accept a ticket, and estimate it so that we can keep a schedule going forward.
2010-03-01 06059, 2010
ruaok
the two clash horribly.
2010-03-01 06007, 2010
ruaok
anyone have any ideas on this front?
2010-03-01 06030, 2010
ruaok
or reactions?
2010-03-01 06039, 2010
aCiD2
If you want time estimates, what we have now works best, imo
2010-03-01 06049, 2010
aCiD2
people just have to feel confident to steal tickets away
2010-03-01 06052, 2010
aCiD2
as you mentioned
2010-03-01 06005, 2010
nikki
is it possible to estimate tickets roughly without accepting them, or are acid2's and warp's estimates totally different?
2010-03-01 06005, 2010
ruaok
yeah, I'm not sure this is welcoming enough.
2010-03-01 06009, 2010
navap
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.
2010-03-01 06011, 2010
aCiD2 nods
2010-03-01 06018, 2010
aCiD2
nikki: atm, fairly different
2010-03-01 06035, 2010
nikki
what navap said was what I was about to say next :P
2010-03-01 06049, 2010
navap
:)
2010-03-01 06000, 2010
aCiD2
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
2010-03-01 06002, 2010
ruaok
navap: that might be tricky. some volunteers (like luks) like to take HUGE tickets, strap on the rocket pack and go for a ride.
2010-03-01 06012, 2010
aCiD2
very true
2010-03-01 06022, 2010
warp
if aCiD2 and I just take responsibility for a certain components, we could just estimate those tickets without them being assigned
2010-03-01 06035, 2010
navap
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.
2010-03-01 06041, 2010
ruaok
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.
2010-03-01 06008, 2010
ruaok
navap: yeah, I guess.
2010-03-01 06048, 2010
ruaok
this is going to be a trciky thing to deal with, regardless.
2010-03-01 06051, 2010
luciddrmr
aCiD2, warp:
2010-03-01 06004, 2010
luciddrmr
why dont you guys just make time estimates and then reassign the issues to no one?
2010-03-01 06006, 2010
nikki
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
2010-03-01 06017, 2010
luciddrmr
unless you want to keep the issue for yourself, in which case, do that.
2010-03-01 06019, 2010
aCiD2
luciddrmr: are those estimates meaningful?
2010-03-01 06026, 2010
aCiD2
once they are floating in the ether that is
2010-03-01 06037, 2010
luciddrmr
acid2: i think any estimation is better than none. especially if done by one of you
2010-03-01 06041, 2010
aCiD2
true
2010-03-01 06045, 2010
warp nods.
2010-03-01 06049, 2010
luciddrmr
you guys have a sense of how long these things take
2010-03-01 06021, 2010
nikki
that's pretty much what I was suggesting, you can always update the estimate later if it's wrong, can't you?
2010-03-01 06023, 2010
ruaok
right now warp and aCiD2 code at different speeds, but that will level our over time.
2010-03-01 06039, 2010
luciddrmr
kind of makes a bit of your job adminstrative, but ruoak could pitch in and do some of it too
2010-03-01 06049, 2010
ruaok
then the question becomes this: whose job is it to estimate a task?
2010-03-01 06000, 2010
aCiD2
I'd like to avoid spending yet more time in JIRA plugging numbers in
2010-03-01 06007, 2010
ruaok
I could see it falling between the cracks when no one takes ownership.
2010-03-01 06014, 2010
nikki points to what warp said
2010-03-01 06035, 2010
aCiD2
nikki: and if it's not our component?
2010-03-01 06042, 2010
warp
ruaok: assign different components to different people, e.g. I get release editor and webservice.
2010-03-01 06045, 2010
aCiD2
I see the best solution is that whoever sees the task first estimates it
2010-03-01 06047, 2010
nikki
whoever's component it is is responsible then
2010-03-01 06057, 2010
aCiD2
if someone actually thinks "oh, i'll do that!" they can take it and restimate
2010-03-01 06001, 2010
ruaok
oh. what if we do this:
2010-03-01 06014, 2010
ruaok
use the component owner to decide who owns the ticket.
2010-03-01 06018, 2010
luciddrmr
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
2010-03-01 06021, 2010
ruaok
er. who estimates the ticket.
2010-03-01 06031, 2010
ruaok
once the ticket is estimated by the default owner, its assigned to no one.
2010-03-01 06051, 2010
ruaok
that way its clear who should do the estimating.
2010-03-01 06055, 2010
ruaok
how does that sound?
2010-03-01 06028, 2010
warp
ruaok: that was what I was suggesting, so sounds good to me :P
2010-03-01 06034, 2010
aCiD2
good, but...
2010-03-01 06042, 2010
ruaok
oh, sorry, misunderstood you then. :)
2010-03-01 06013, 2010
aCiD2
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
2010-03-01 06035, 2010
aCiD2
but hopefully that's not too hard to setup
2010-03-01 06047, 2010
ruaok
aCiD2: can you look to see if you can tweak that?
2010-03-01 06052, 2010
aCiD2
ok
2010-03-01 06053, 2010
ruaok
and then get back to me?
2010-03-01 06058, 2010
brianfreud_ joined the channel
2010-03-01 06008, 2010
aCiD2 nods
2010-03-01 06023, 2010
ruaok
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.
2010-03-01 06032, 2010
ruaok
thanks for all the suggestions!
2010-03-01 06037, 2010
ruaok
ok, next.
2010-03-01 06048, 2010
ruaok
right now I am seeing a *lot* of reviews in CR.
2010-03-01 06054, 2010
ruaok
seemingly for each little bug.
2010-03-01 06003, 2010
warp nods.
2010-03-01 06011, 2010
ruaok
is that granularity good or should we say that simple fixes ought to not get reviewed?
2010-03-01 06020, 2010
aCiD2
I think this granularity is good
2010-03-01 06028, 2010
aCiD2
I'm very happy with it atm, rarely does a fix need to be commited asap
2010-03-01 06000, 2010
ruaok
warp, luks: thoughts?
2010-03-01 06006, 2010
warp
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.
2010-03-01 06041, 2010
ruaok
ok, sounds like we should keep doing it for the time being. if it gets tedious in a month or so we'll revisit.
2010-03-01 06041, 2010
aCiD2
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
2010-03-01 06043, 2010
ijabz
IMO the most important thing is whereever possible every change has a unit test, does that happen
2010-03-01 06057, 2010
aCiD2
ijabz: 50/50 atm probably
2010-03-01 06023, 2010
aCiD2
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)
2010-03-01 06035, 2010
ijabz
Because with just code reviews you are asking someone else to spot your mistakes
2010-03-01 06035, 2010
aCiD2
but genearlly yea- I agree with you, new features or clear bugs should have unit tests
2010-03-01 06041, 2010
warp
ijabz: currently lots of interface things don't get unittests, most of the data changes do. from what I see.
2010-03-01 06054, 2010
ruaok nods at warp
2010-03-01 06057, 2010
aCiD2
ijabz: asking for another set of eyes, it's no excuse to write sloppy code :)
2010-03-01 06001, 2010
navap
How do you have a unittest for a UI bug fix?
2010-03-01 06025, 2010
aCiD2
navap: some are testable, we have some tests for them
2010-03-01 06025, 2010
ruaok
ruaok has changed the topic to: agenda: unit tests, clean markup, artist i18n, script detecting
2010-03-01 06034, 2010
warp
navap: most interface changes test if the data is there, not how it is display. that's good enough I think.
2010-03-01 06037, 2010
aCiD2
but CSS stuff aren't realistically testable
2010-03-01 06041, 2010
aCiD2
as with typos and other stuff
2010-03-01 06041, 2010
ijabz
Sure, dosnt really work for UI bug fixes
2010-03-01 06058, 2010
ijabz
but they are less critical/dangeous
2010-03-01 06005, 2010
ruaok nods
2010-03-01 06010, 2010
brianfreud_
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.
2010-03-01 06059, 2010
ruaok
warp: clean markup!
2010-03-01 06002, 2010
ijabz
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
2010-03-01 06012, 2010
ruaok
agenda: clean markup, artist i18n, script detecting
2010-03-01 06027, 2010
aCiD2
ijabz: pretty much because that's just done, so it's not much of a topic :)
2010-03-01 06034, 2010
ruaok
ijabz: that is because the unit testing is already happening for things we can test easily.
2010-03-01 06047, 2010
warp
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()
2010-03-01 06047, 2010
ruaok
ruaok has changed the topic to: agenda: clean markup, artist i18n, script detecting
2010-03-01 06048, 2010
ijabz
thats good then ;)
2010-03-01 06015, 2010
warp
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
2010-03-01 06029, 2010
ruaok nods
2010-03-01 06035, 2010
warp
ruaok: luks' objected to that, so I'm wondering how clean we should keep that markup
2010-03-01 06055, 2010
aCiD2
i'm pretty much in with luks here too - provide enough markup to easily generate these elements
2010-03-01 06059, 2010
aCiD2
but I think brianfreud_ is more with you :)
2010-03-01 06021, 2010
brianfreud_
Only so far as it impacts performance significantly
2010-03-01 06022, 2010
luks
warp: if you need html like that, do it from javascript
2010-03-01 06026, 2010
warp
ruaok: note that in this particular case it concerns the tooltips, which are easily made translated in the templates, but much harder in javascript.
2010-03-01 06029, 2010
ruaok
provide enough markup, what do you mean?
2010-03-01 06042, 2010
luks
I think the html output from he server should be as clean as possible
2010-03-01 06056, 2010
aCiD2
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
2010-03-01 06011, 2010
ruaok
ah
2010-03-01 06026, 2010
aCiD2
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
2010-03-01 06033, 2010
aCiD2
you just have to remember to store/lookup strings through it
2010-03-01 06042, 2010
warp
aCiD2: ok
2010-03-01 06027, 2010
ruaok has no real input on this.
2010-03-01 06033, 2010
aCiD2
also
2010-03-01 06050, 2010
brianfreud_
w td to be inserted and rendered, even if you hid the table while doing it)
2010-03-01 06021, 2010
aCiD2
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
2010-03-01 06044, 2010
brianfreud_
ugh, please please please don't touch the native prototypes! :D
2010-03-01 06045, 2010
navap
brianfreud_: We don't have those kinds of tables anymore though.
2010-03-01 06055, 2010
pronik_tp
speaking of translations, js-gettext is pretty easily implemented if needed, so no problem there
2010-03-01 06006, 2010
brianfreud_
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
2010-03-01 06014, 2010
warp
aCiD2: yes, if the markup has to be clean, I'll probably use some little templating engine.
2010-03-01 06032, 2010
aCiD2
kewl
2010-03-01 06002, 2010
warp
ruaok: well, most seem to think clean markup is more important. I'll go with that.
