#musicbrainz-devel

/

      • MBJenkins
        Ian McEwen: Use cmp_bag in Controller::RelationshipEditor test, since attribute order is not consistent across machines.
      • Yippee, build fixed!
      • Ian McEwen: Re-add improperly-removed space in a qw() for import
      • ianmcorvidae
        yay :D
      • misterswag joined the channel
      • chirlu` has left the channel
      • Gentlecat joined the channel
      • itshim joined the channel
      • rvedotrc joined the channel
      • zas joined the channel
      • reosarevok joined the channel
      • ijabz1 joined the channel
      • bandtrace joined the channel
      • Freso
        Gentlecat ianmcorvidae: I'm not a fan of the "karma" of a review resetting when the review is altered. That could be one way to "game" the system: if a review gets more negative feedback then positive, go in and change a comma and whoosh, karma is reset.
      • ianmcorvidae
        nobody thus far has proposed that as an option, so I imagine that's good news :P
      • Gentlecat
        :)
      • rvedotrc joined the channel
      • nikki
        not reseting it is also a way to game it, write a positive review then when you have enough positive feedback, edit it to say it sucks :P
      • Gentlecat
        I guess that's more about community
      • ianmcorvidae
        mostly I'd like it to be possible to say something to the effect of "this review has been edited since some votes were cast, go look at the differences"
      • and/or be able to alert people that something they've voted on has been revised
      • whether you hated a review or loved it, you're likely to be interested in the changes!
      • ijabz1 joined the channel
      • ijabz1
        hi bitmap im looking for this chnage to sql re ordering attribute
      • ianmcorvidae coudnt get stabke internet conection last night
      • ianmcorvidae
        ijabz1: there's little to no actual change, it's just fewer things being inserted to various tables, such that all series are marked as the same ordering attribute
      • things went well after they started working, I have a PR up for the MBS changes that need to happen
      • ijabz1
        Hi, as you say instrument description is missing I'll add that
      • ianmcorvidae
        yeah, that's the main thing
      • ijabz1
        ordering attribute is missing from output but should be searchable, so do we want that
      • ianmcorvidae
        I'm not sure re: ordering type, since ordering attribute will in the newest version always be the same that shouldn't be needed (and we can change it later if we reinstate the situation with several attributes)
      • ijabz1
        ordering type is also missing (was never requested in 1st place) so I'll leave that
      • ianmcorvidae
        I'd say ordering attribute isn't useful to put in. I'm not sure about ordering type (which is a value determining if a series is automatically edited by way of the 'number' ordering attribute, or if it's ordered manually by users)
      • bitmap
        I didn't change the schema for ordering_attribute at all, but I did remove it from the /ws/2 output since it's no longer meaningful
      • ianmcorvidae
        ah, if it was left out initially then I'd say it's fine
      • ijabz1
        ah, that was probably why I didnt add it to output
      • ianmcorvidae
        do we have series type? that's actually useful, though I guess I didn't see it displayed in the search
      • bitmap
        and I didn't request ordering_type because I couldn't think of a scenario where it'd be useful
      • ijabz1
        yes that should be there
      • ianmcorvidae
        yeah, I couldn't really think of one either, hence being unsure
      • ah, yeah, it is there
      • we need to fix the MBS template to not list ordering attribute/ordering type for display then, probably, but that's not a hard fix
      • I can put that in my branch
      • bitmap
        which MBS template?
      • ianmcorvidae
        results-series.tt
      • bitmap
        ah, right
      • ianmcorvidae
        you approved that PR anyway though, so I should merge it
      • but those are removed, anyway
      • chirlu` joined the channel
      • rvedotrc1 joined the channel
      • MBJenkins
        * Ian McEwen: Search fixes: /search/editor doesn't exist
      • * Ian McEwen: Don't force direct search for editor/instrument
      • * Ian McEwen: Fix release-group to release_group before calling type_to_model.
      • * Ian McEwen: Don't show ordering attribute/ordering type in series search, since they aren't useful
      • bandtrace joined the channel
      • Project musicbrainz-server_schema-change-2014-05 build #72: FIXED in 10 min: http://ci.musicbrainz.org/job/musicbrainz-serve...
      • Ian McEwen: Fix Controller::Search::Direct test to actually specify direct search for editors rather than relying on the default
      • chirlu` finds more issues so bitmap doesn’t run out of work. ;-)
      • nikki
        job security
      • ianmcorvidae
        haha
      • you say as though we'd ever run out of work with the state of our ticket tracker :P
      • (now, focus/figuring out what to work on next, maybe, but...)
      • chirlu`
        Actually, JIRA doesn’t look *that* bad if you restrict the view to issues of type Bug.
      • For Improvement and New Feature requests, well …
      • ianmcorvidae
        of course, we don't have anyone whose job is "fix bugs" alone :)
      • chirlu`
        Anyway, enough issues found for the time being.
      • chirlu` has left the channel
      • bandtrace joined the channel
      • MBJenkins
        Project search_server build #21: SUCCESS in 2 min 22 sec: http://ci.musicbrainz.org/job/search_server/21/
      • Also added missing Instrument comment and Xml tests
      • * Paul Taylor: SEARCH-265:Editor search remove filtering if confirm date null
      • rvedotrc joined the channel
      • bandtrace joined the channel
      • ijabz1 joined the channel
      • ijabz1 joined the channel
      • JonnyJD_ joined the channel
      • bandtrace joined the channel
      • ijabz1 joined the channel
      • Nyanko-sensei joined the channel
      • bandtrace joined the channel
      • ruaok joined the channel
      • bandtrace joined the channel
      • outsidecontext joined the channel
      • outsidecontext
        hi. does anybody know if the first track in a CD TOC actually can have a number other than 1?
      • sampsyo joined the channel
      • alastairp
        hi all
      • hi sampsyo
      • ruaok
        outsidecontext: no, its always 1
      • hi alastairp
      • Freso
        outsidecontext: Though there can be audio before track 1. ("HTOA" (Hidden Track One Audio))
      • outsidecontext
        ruaok: thanks. i just wondered because the method discid_put in libdiscid requires one to sepcify the first track no. and I wondered if that can make sense
      • JonnyJD_
        outsidecontext: from what I remember it doesn't
      • outsidecontext
        actually libdiscid currently does not deal well when you set this to anything else than 1, but I will submit a patch
      • JonnyJD_
        a patch to check that this is 1?
      • outsidecontext
        JonnyJD_, sure, it does. the signature is int discid_put(DiscId *d, int first, int last, int *offsets)
      • JonnyJD_: that's why I asked. either a patch to make sure it is one or to allow values other than 1
      • JonnyJD_
        from what I remember only 1 makes sense. Maybe you find an old ticket about that
      • outsidecontext
        thanks. I will have a look.
      • I found this issue because I have a test in ruby-discid that actually checks if values > 1 lead to plausible results, but this fails with latest libdiscid due to the input checking
      • JonnyJD_
        either way, there are different reasons why you would think the first track might not be 1, but even with a data track up front, lots of pregap etc. it is always 1
      • outsidecontext: http://tickets.musicbrainz.org/browse/LIB-17 (related, but not *it*)
      • outsidecontext
        JonnyJD_, interesting, but that indicates that there can be discs with the first no. > 1
      • zas joined the channel
      • JonnyJD_
        but not necessarily that they are "valid"
      • in term of standards
      • outsidecontext
        not sure if this matters. but at least we should be consistent how those discs are handled.
      • make things a bit more complicated. i thought just fixing discid_put would be sufficient
      • JonnyJD_
        outsidecontext: "The track numbering shall start with the value 01 and shall increment by one"
      • outsidecontext
        JonnyJD_, where have you found that statement?
      • Freso casts his vote-of-no-special-significance on making libdiscid conform "strictly" to the standard for now, until someone complains about a disc with first track !=1, and then keeping that disc's TOC around for testing purposes in the future.
      • JonnyJD_
        BS EN 609008 1999 british standard does it say in the PDF
      • that is the closest I found to a standard (difficult to come by.. old.. cost money.. etc.)
      • outsidecontext
        yep
      • at least we should make sure that reading the TOC with an external tool and using discid_put should get the same results as directly using discid_read
      • JonnyJD_
        yep
      • outsidecontext
        not sure how discid_read currently would react on such a disc
      • JonnyJD_
        and as it goes for copy protected CDs that don't follow any standard: these are difficult either way. I tried my best to make some of these work, but some are just plain broken.
      • bandtrace joined the channel
      • Mineo
        JonnyJD_: aren't you still a student? we have access to some standards databases over here
      • JonnyJD_
        Mineo: we also have access to *some* standards. I didn't try for this one.
      • anyways, what I found is good enough. From what I understand this is some version of that "red book", though not the most current one
      • travis-ci has left the channel
      • actually, it might even still be the current standard
      • alastairp
        hi guys
      • MBS-7303
      • mb-chat-logger
      • kepstin-laptop__ joined the channel
      • alastairp
        bitmap: do you know what's going on here?
      • (with the knowledge that it's release week this week), we would like to see a solution :)
      • "The edit was made in the old release editor, so I'm hopeful it's not possible anymore.", so how do we get the data into a nice state?
      • make another edit?
      • reosarevok
        Yes
      • Freso
        I would say so, yeah. And close the ticket if it's not possible to replicate the bug in the new editor.
      • alastairp
        ok. we're going to do the edit again
      • though, since we have no idea what caused the bad edit, we don't know if it's "fixed" if the new RE works
      • ijabz1 joined the channel
      • Freso
        And there's only one way to find out.
      • ruaok
        alastairp: and even if the bug was reproducible we woulnd’t be able to do anything about it.
      • its schema change release week.
      • alastairp
        you mean you couldn't do antyihg about it because you're busy, or because once the schema changes you can't do stuff with edits made on an old schema?
      • ruaok
        busy.
      • but we can see that we can get it done in the next two weeks
      • rvedotrc joined the channel
      • alastairp
        yeah, I completely understand taht
      • moha just re-did the edit, anyway
      • http://musicbrainz.org/edit/27717453 one more vote would be nice ;)
      • ruaok
        not that I can really just that that is correct, but hey. :)
      • alastairp
        ;)
      • nikki
        alastairp: what format is "other" supposed to be?
      • alastairp
        cassette -> mp3 -> archive.org