#musicbrainz-devel

lookups are fairly done, but we've changed the spec so I need to go back and tweak the inc= parameters.

but browsing is totally new

hi pronik

I also want some proper testdata, because there will be a lot of code re-use, and changes in one part could easily break stuff elsewhere.

moin

Hrm, browsing as in "BR" to get artists starting with BR?

ollie: not quite.

because we already have routines for that, so surely it's just a case of providing a new view

I estimate one week to create test data and adapt the current lookups.

ollie: its more like a paged view of data. so that we don't output too much data and DoS the WS because of JSB or Mozart.

another week to create the browse requests

and some more time for the non-core entities, which involve POST requests.

Ah, right

so, 5 weeks to get it done?

ruaok: yes.

ok.

I think we can do better than 5 if I can jump in now...

ollie: how are you with the edit stuffs?

(with my week review)

ollie: that is where I am headed with this.

/ws/2 estimate document: http://spreadsheets.google.com/ccc?key=0AoCSF6P...

I've got everything excep the _LINK_ stuff. That will be done this week. I think I need to spend at least another 10 hours improving the migration speed (caching, etc)

and prepping it for a full migration

so, two weeks until you're done for beta2 status?

warp: how long did you say for the RE to be complete?

Well

ruaok: two more weeks I hope.

I still have a ton of other tasks scheduled for beta 2

but 2 weeks to get my high priority stuff done

well, since I started a bunch of bus dev stuff, my schedule is pretty packed with no chance for coding.

so, I am wondering if we can even attempt to pull in the schedule with moving ollie to WS stuffs.

it doesn't really sound like its going to really help. at all.

how about this?

The schedule being the current taskload on jira?

that is all up for question right now.

hi

Well, if we narrow it down it should be good

what if we do this: instead of moving ollie to WS, we keep warp on RE & WS/2.

ollie works on his beta2 tickets and takes some from warp.

and then we say beta 2 comes in 5 weeks?

ollie: what are the other things you need to get done for beta2?

ollie: anything that can wait?

do we need the browse stuff for beta2 ?, could we finish the rest of the webservice for beta2 and do browse for beta3 and put it into that

ijabz: interesting point.

warp: how much time do you need to finish the changes portions of the ws/2 without implementing browse?

because I dont like the idea of having a load of stuff not going in to beta2 and then going straight to final, so I think we need a beta 3 anyway

ruaok: I estimated browse as 1 week, so that saves 1 week out of the 3 weeks I estimated for /ws/2.

warp: plenty

ijabz: its looking like there might be a beta 3 at this rate. :(

But the other high priority stuff would be the NGS edits

ruaok: let's call it rc1, sounds more positive ;)

lol.

IMO Final should just have things that were overlooked in beta, not extra stuff we ddnt have time to write for beta deadlines

ok, RC1 in 4 weeks. complete edits (including NGS edits?), WS/2 done except browsing, and a working RE

that doable?

ijabz: agreed.

and I am thinking that we ought to scap the dashboard, timeline and statistics for the NGS final release.

and work hard to get those back for the first post NGS release.

ruaok: yeah, sounds fine.

anything that is not critical, even perhaps auto editor elections, should be dumped for now.

otherwise we'lll never finish.

warp: fine on RC1 in 4 weeks or dumping non-core features?

ruaok: rc1 == beta3. beta2 should just be called beta2.

ok.

beta2 in 4 weeks?

ollie: what could you get done in that timeframe?

a release candidate should be more or less feature complete IMO.

ruaok: yes, 4 weeks sounds fine.

ollie: ?

ruaok: I think I could tighten up and bug fix every feature we have atm

but not add any real new stuff

(soryr, eating dinner and trying to host the couchsurfer :))

how about NGS edits?

yea, I'd hope so

ok, its a plan then.

we often go months without any auto-editor elections so I don't think those are critical, but if we're going to drop that to post-ngs, we should probably let the automods list know

nikki: sounds fair.

ok, beta2 delayed 4 weeks.

but we're pushing this one out the door. no more schedule slips.

do we have a date?

and we'll promise an RC1 as well.

(i'm away june 28th-july 10 remember)

that's monday june 21st, right?

yep.

ok, that's really perfect.

ollie finishes before vacation.

:D

june 21 it is.

ok, I'll put up a blog post to that effect.

in hindsight

I think we struggled with this beta because it was just too big

300 odd tickets (mostly non trivial) is a lot

I'd like some clarity on what needs to be done, install-wise, on/before that date.

so hopefully breaking it down into 2 more should work a lot better

yeah. and we tackled really big thiings. and back-tracked on really big things.

I think your lists were too ling making it hard to prioritise

long

ruaok probably meant ' djce: realistically nothing. since we're only rolling it out to test.musicbrainz.org '

djce: realistically nothing. since we're only rolling it out to test.mb.org

ok

I like having clear goals-with-specs, like I have now for beta2 :)

ijabz: agreed. like I said I am looking forward to working with much more concrete milestones post NGS

ok, lets review last week then.

warp: you first?

yes

I started off last being quite frustrated with HTML::FormHandler, and in general being stuck on creating the wizard.

with a bit of help from aCiD2 and gshank in #formhandler those issues were resolved

so that now I have a basic working release editor wizard. (no artists, no javascript).

oooh!

do you feel like its time to get more feedback now?

I have started adding javascript bits today after lunch, a very early track parser is working now.

I have no easy way to give people access to my dev-machine.

can't it be pushed to test?

:80 is not really being used for anything atm (seeing as we're not launching a beta today)

I'd be up for that. this is important enough to detour test

test has next, with the previous attempts at revamping the release editor.

yea, but that can change, np

warp: push your change to test plz.

or you just merge your stuff into next?

i mean, the point of it is to track the next work :)

ollie: I'm afraid merging into next will give me heaps and heaps of conflicts.

ollie: though I haven't tried.

then lets not worry about it now.

just push your working branch to test.

I really want to give people *something* in lieu of a beta.

ollie: any chance you could work on that once warp goes to bed?

fair enough, that's no big problem

can we reboot next to the current master?

ruaok: pushing the branch out?

ollie: get the RE on test by any means possible.

If warp leaves it pushed to warp.git and tells me the branch name, I'll do the rest of the heavy lifting

great.

please do that. once you're done I'll put up the blog post.

ollie: other than you're edit branches there's nothing interesting in next which isn't in master, is there?

Ok, it might be late eveningish, but I'll get it done

s/you're/your/

warp: that's what I'm thinking

so long as you haven't added anything recently

ollie: no, I've been working on my own branches for the past few weeks.