#musicbrainz-devel

Hm.

Anyone here?

no

:-)

:)

Just out of interest, is there a release date set for CAA?

not afaik.

Ok cool.

Wondering when I should consider getting Debian packaging for libcoverart underway.

with enough time to make it into the next stable release :)

Next stable release freezes in mid-June, so we've almost certainly missed that.

really?

I imagine so, we haven't officially released libcoverart yet. No point trying to package a Beta up for Debian.

Plan was to officially release libcoverart when CAA is announced.

I mean, the freeze in june. I am subscribed to debian-devel-announce, where I assume such stuff would be posted to.

I have seen it somewhere, one sec

ah, it was announced on debian-devel-announce around the time of my flight back to .nl

CAA will be annonced on Oct 9.

announced even.

Ok, that gives me an idea of when to schedule things.

Hopefully we can get libcoverart into Debian without the last minute rush that happened with libmb4/5

Something else that occurred to me. If libmb5 ever gets to v5.0.9, what should the next release number be if it is only minor bug fixes?

Is 5.0.10 acceptable generally? (we do that here at work)

adhawkins: acceptable to who? it certainly is acceptable to me :)

Just wondered if there was a generally accepted scheme for this.

If it were just major.minor, 5.1 and 5.10 are numerically identical

adhawkins: there are a few different standards which you can choose to follow if you want.

adhawkins: http://semver.org/

there may be more.

Erk, we've already 'broken' semver

"Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. "

:)

However, point 12 effectively says all number between the '.' are considered independantly. Major first, then minor, then patch.

I wouldn't consider 5.1 and 5.10 to be identical when used as software versions.

Ok.

Sounds like in future 'schema' changes should cause a minor version bump, not a patch version as I've been doing.

That might complicate packaging some more :)

adhawkins: if you choose to follow semver. you also make your own statement about what all of it means.

+can

Yeah.

but I guess following semver would be appreciated by some groups of packagers and users.

But the apache one is similar. Patch level versions are for pure bug fixes only. New functionality should increase minor version.

I'll have to see how that affects things like Debian.

For example would libmb5 and libmb5.1 be different packages, or still called libmb5?

I have no idea. I know very little about debian packaging.

Ok.

adhawkins: still libmb5 unless you break api/abi and want those to be parallel-installable

(which you don't want)

"Google scores victory: judge rules APIs not copyrightable"

Guess that's good news, since less legal BS tends to be

teuf: I think I agree there.

reosarevok: yes, that definitely is good (though not unexpected) news.

reosarevok: I was more worried about the patent phase, but google won that as well.

adhawkins: using the 2nd number to tag schema changes, and the last one for bug fixes would be nice

adhawkins: but anything will do imo

Yes, that's what I think we'll do moving forward.

Just trying to work out how that fits into Debian etc.

reosarevok: so I think the oracle vs. google case is now over (apart from some formalities).

adhawkins: don't worry too much about that ;)

teuf: Well, Debian is what I use so it'd be nice to handle it properly!

I still use Debian on two machines. but the slow release cycle is now starting to annoy me, so I'm considering switching everything over to Ubuntu.

My main server is debian (firewall, routing, DNS, NTTP, SMTP, POP3 etc). I like the fact that I know it's just going to keep working.

I don't really need new versions mostly.

adhawkins: development cycles have speed up in recent years.

Yeah

as a webdeveloper doing javascript it is convenient that I can just 'sudo apt-get install nodejs' on ubuntu to get a working javascript prompt

(even though I don't care about node.js as a platform)

stuff like that being available faster is making ubuntu quite tempting, even on servers.

adhawkins: what I mean is that debian doesn't really care about how you version your module

Yeah, just been asking that on a debian channel, and as long as the SONAME stays the same, the package name should too.

So in future, if there's new functionality (schema changes and hte like) the minor version will get bumped. Pure bug fixes will just increment the patch version

hi everyone

bitmap: boo!

bitmap: how are you doing with your gsoc stuff?

I wrote the log sanitizing script

Does anybody want to see?

Has anyone been working on a semi-automated bot for uploading artwork to CAA? I heard a rumour there was one in the works.

Rumours, all!

Righto

Thanks Reo

I'll go git my lunch

Ooops I mean get

:D

fork... lunch... ? It should be trivial.

but yeah, the awesome thing about gitting someone else's lunch then by forking it is that they still have their lunch :)

got to love digital non-scarcity.

so, is it intentional that people aren't allowed to log in to classic.musicbrainz.org?

I wanted to look at the pre-ngs-conversion edit history for something for comparison purposes

but I couldn't, since login is disabled.

warp: so far so good, though I realized the javascript is a bit annoying because it involves template-y stuff that jquery doesn't do well on its own (i.e. adding/removing/changing relationships and then updating the UI)

if I could I would use something like http://knockoutjs.com/ but I realize that's departing a lot from the rest of the MB js

me uses json-template on http://people.scs.carleton.ca/~cwalton3/temp/mb... - it's kind of a neat javascript template library, that doesn't pull in any junk :)

http://people.scs.carleton.ca/~cwalton3/temp/mb... - yey, templates.

luks: thanks for furiously merging my trivial Picard patches :D

(and bitmap too)

mostly luks :)

bitmap: ah, don't know knockout

I used it in a previous project and it's pretty awesome

bitmap: ocharles and I have discussed templating before. I would really like a solution where we can use templates on both client and server.

that'd be nice, since relationship_editor.tt needs the same template as the js to display the initial relationships

bitmap: I would be inclined to render that with javascript as well, especially if server and client-side do not share templates.

bitmap: http://wiki.musicbrainz.org/User:kuno/Templates

warp: at first I was thinking about encoding all of the relationships as json into the js, and have it render them