#musicbrainz-devel

Hey, quick request for info: does anyone here understand this commit? http://bugs.musicbrainz.org/changeset/12168

Specifically I'd like to know how to test it: what URL to request from the search server, and what response to expect.

thanks for any help :-)

I think it's /ws/1/track?type=track&fmt=html&query=xxx

and the tagger link should contain the same UUID as the release link

currently it uses the track UUID, which is wrong

ok thanks

hmm not quite, the responses don't contain tagger links at all

oh

sorry

add &tport=8000 to the url

ah, tport

yup

bingo. Thanks luks :-)

almost!

:)

hello!

hi warp!

anyone else here? :)

got your captain hat on today?

aCiD2: if the captain hat means being able to set the topic, then no.

lol

<BANG>

hello everyone, ruaok is in the middle of a conference and can't be here for this meeting.

I do have some updates from him I'll start off with

then I assume aCiD2 will be able to tell us something about his week

I'll touch on the style guidelines

do we have anything else ?

I wouldn't mind discuss what to do about "stuck reviews"

ok

so, imagine we have a topic which contains: review (ruaok), review (acid2), style guidelines, stuck reviews.

i'll just copy/paste from his e-mail:

- was sick for a couple of days :(

- worked on updating the relax NG schema for the XML 2.0. I'll finish it up and put it up for review on Wednesday.

- worked on hosting with Dave. We are working to rearrange some servers to expand our overall capacity.

sounds like an ok week for rob :)

Pcworld.com is ready to publish another Picard Pcworld.com is ready to publish another Picard Dave is working on this today/tomorrow.

shame about the illness creaping in again

(I've been somewhat ill these past few days too, which is annoying).

hm, that paste went wrong.

copy/pasting from mutt is also annoying :)

Pcworld.com is ready to publish another Picard review, but I want to hold them off until we have these changes in place.

Dave is working on this today/tomorrow.

- worked on streamlining paying Oliver, but dealing with banks takes too much time. :(

that's it for ruaok, any questions on this you'll have to ask him yourself when he's back

:)

cool

want me to take over?

cool indeed, it's fun when the press mentions us :)

yes, please take over.

ok

my week was a bit slower than I really wanted... I carried on chipping away at the release editor, but I'm really hitting a blocking point until I get the reviews through

nontheless, here's where we are:

we have editing for overlays, the label lookup is "complete" to the best of my knowledge, I've also rewritten the track/medium arranging code to just do it manually, and it happens to work a treat

the artist credit editor is in a semi-finished state locally, but I don't really want to work on that until the label lookup works

well, is shipped even

Still to be done is creating new tracks/mediums, and then I think it's done though :)

pronik: yay!

aCiD2: want to continue on to the stuck reviews?

sure

basically, these reviews have been waiting for a final ship it or more feedback for a few days now, so I see to options. we either wait, or we ship as is

it depends on what our view on reviews is actually for -- is it to guarantee complete functionality, or is it to prevent small bugs in individual commits?

are you waiting for ruaok, luks, either, or both of them to review these commits?

anyone really, just a final nod of approval

I'd say ship it if they've stayed in queue for longer than a couple of days

if we're using reviews for the latter, I think we may be ok with a "expiry" date on reviews

it just starts to get annoying having to juggle work that depends on 2 branches, and having to constantly merge all sorts of stuff on changes, which is why it's slowing me down

I think it's ok to ship them

great

I'm sorry for not reviewing the patches, but I've been quite busy lately

if I can ship them I can move them into more testing with #mb people too

aCiD2: I'm not an MB developer ofcourse, but from seeing you people use them I would say most of the benefit is in catching design flaws early

aCiD2: does this solve your reviews issue, or are there multiple reviews waiting, some of which you think need to actually be reviewed?

no, I think the reviews have had the most pressing issues ironed out now

ok :)

I wouldn't ship without any feedback, but the ones I'm waiting on have at least had that

so that clears that up! thanks

out of curiousity

luks, aCiD2: what will you be working on this week?

release editor for more, maybe picking up some small perl tasks if I get bored

nothing mb-related, I'm afraid

oh, I should add in - uni starts again now for me (started today), so i'll be back to fitting work in between

luks: ok

aCiD2: ah, right. how many hours on average will you be able te spend on mb?

going back to scheduling 16 a week

at least

ok, I think that's it for all the actual development stuff

regarding the style guidelines,..

I probably won't do much MB development this month

this is the last month at my current job, also I'm working on my thesis so that I can finally finish the school

ah, right.

nice

With the help of nikki I've put together a table-of-contents for the post NGS styleguidelines

good luck luks :) will you still be around just for little discussions for time to time?

(some of you probably know this already :)

I was hoping brianfreud could have a look at them before this meeting too, but I haven't seen him around much.

aCiD2: yes

warp: are they online?

One of the things I want to do to the style guidelines is not just improve the content

aCiD2: my toc.txt is only on my computer at home ( http://frob.nl/~warp/toc.txt ), as it was for now just intended for this group here.

aCiD2: but I'll post it to mb-style soon to get more feedback there.

ok

But, I also want to improve our presentation of the guidelines, to make it more accessible to new users, etc..

for this, I need some help :)

pronik: can I poke you with some ideas after the meeting?

warp: yeah, np

also, does anyone here happen to know anything about what currently drives the transcluded pages on musicbrainz.org/doc ?

how do you mean?

how is that rendered, is it screenscraped from mediawiki? or are we called their renderer, or do we have our own renderer with a subset of wiki-syntax?

s/called/calling/

and as far as I know, that gets embedded in the page

ah, ok

yea

There's an argument you can add to an article URL and it gives you just the html of the article, than we have a separate css file that formats it.

Same as moinmoin, basically

ok, so if we want to customize that look, we can very easily muck with the .css, but anything else will be much more work.

If you change the html in the article, that change will be reflected on /doc as well, so it's not too hard.

I'm not sure how the new /doc will work though.

pronik probably meant ' iirc we still don't have fixed version transclusion, i.e. musicbrainz.org/docs shows the latest wiki version, right? '

iirc we still don't have fixed version transclusion, i.e. mb.org/docs shows the latest wiki version, right?

same type of thing navap

pronik: No that was fixed.

oh, must have missed that

different code, same procedure though

aCiD2: But the css in /doc is not the same as on wiki.

So making changes will be harder because it will look different in bth places.

What do you mean?

oh right

but we have that problem now anyway

Curently the css is about 99% the same in both places, so what you see in wiki is what you should see on /doc.

I don't think that's too much of an issue. if /doc looks significantly better for example, we just need to point people at the /docs version everywhere -- and consider the wiki versions just as the backend for mb-style.