IRC Meeting 2007 01 08 Minutes

Status

Who	DONE	TODO	BLOCKED	DISCUSS
tru	Slacking	Collection manager in esperanza
dangertools			waf
DraX		finish collections in objc bindings	confusion on a few points	better collections documentation
nano	win32 porting asx	xmms2 cli win32	lastfm ws2.0	airplay jack songlength doxygen portal
puzzles
theefer	C++ bindings (collections)	collparser regression tests (for 1339 + others) coll pattern syntax documentation coll dev documentation nyello improve pshuffle C++ bindings implem of custom_coll_parser		Collection doc
eleusis	gitweb update recently	get up to date with collections improve client list on wiki (sortable table columns) merge gitweb with mainline
anders	Py colls py refactoring Basic (neuros)OSD client http://git.xmms.se/merge	Py coll docs	(neuros)osd mainloop crap

Topics

Waf progress

Action:None

TOPIC: Waf progress dangertools: you mentioned that you were blocked on waf? yeah, rafl was/is working on javabindings+waf he had quite some problems and less time objc+waf is going to be a nightmare afaik he's also in contact with the waf-guy ita is on vacation DraX: Why? nano-: will basically have to reimplement the GNUStep makefiles and GNUStep.sh in python nano-: and then will have to somehow make it work on OS X too DraX: are you going to do that by yourself? eleusis: yeah i guess k once i get back to school I can work on the OS X part too rafl thought the same about swig+waf ~1.5 months ago ;) puzzles: do you know much about how the waf work has progressed so far? as in, what customisations we've made to get it to work with the xmms2 code tree, what's still missing, etc.. eleusis: i can't say much, all i know is we've ironed out most of the major features we had with scons eleusis: and there are some residual issues with wafadmin and crap, though svn waf is smarter now righto who are the main people working on waf integration atm? eleusis: i think it went danderson -> tru -> rafl -> all other plugin developers

Request for pull mailbot

Action:Anders to improve http://git.xmms.se/merge

TOPIC: Request for pull mailbot has anyone done anything on this, since the last time it was discussed? :) my code got trashed on the Great Harddrive Crash of '06, does that count? After the creation of http://git.xmms.se/merge/, is it really worth it? That page gives a very clean view over what exists in the diffrent repositories. nano-: how is that related? i mean.. how does git.xmms.se/merge fit into the workflow? theefer: It gives a very clear view of what changes exists in the repositories. i really don't understand how git.x.s/merge is any real help ok, there are 2 issues here 1) how does the merge status page fit into the workflow 2) how does it override the bot idea 3) isn't the rfp mailbot intended to facilitate blessing patches? I am not particularly in favour of a pull mailbot (except that they do it at Google, sort of ;-) ), but it's not exactly the same thing IMHO what does google do? gxs/merge provides a clear overview of status ; the pull mergebot was supposed to encourage review, at least that's how I understood it yeah, that's how i see it too.. with the mailbot, people get to review patches before they are sent to mainline eleusis: each commit needs to be peer-reviewed for approval (using a system semi-integrated with their perforce) before it's merged ; it's just a policy, not a tech requirement. 1) people who merge changes to -devel check that page if there are anything interesting in the repos, if there are, they pull it. it takes just a second to see changes in all the repos. 2) it doesn't override the idea, but the gain of a pull mailbot is smaller after the introduction of that page. The mailbot idea the following problem: you had to bother tru or anders to merge stuff in -devel. yes, exactly with the merge status page, we can pull whatever we want, but we still have to get tru or anders to do the real work <anders_> git.x.s/merge is driven by the developers. <anders_> Wheras RPF mailbot is driven by developers. <anders_> oops. <anders_> git.x.s/merge is driven by the integrators. ok, so integrators periodically check merge status? <anders_> Yes. but IMHO, the integrators still need to ask people if they should pull people's trees I might have unstable stuff in mine for instance <anders_> But as a side effect it is easier for developers to see what they are providen. whereas with the mailbot, people advertise when stuff is ready Has there been any work on the mailbot yet? I knew puzzles begun writing something in ruby? Is it from that the mailbot is supposed to build on? anders_: so what happens to the mailbot idea, then? :) <anders_> theefer: Yes. The plan is to have a "for-integration" branch in trees. <anders_> But what merge status shows is what the mailbot would include in its mail. is anyone planning to do some work on the mailbot in the near future? (or has done some work on it recently) <anders_> I will improve git.x.s/merge, which will share code with mailbot.

XMMS2Forge

Action:Sham to investigate further

TOPIC: XMMS2Forge anders_: you should create tools or at least bash functions to do the work on multiple trees <anders_> theefer: Yes. <anders_> eleusis: It would be nice if it just magically appeared :) http://repo.or.cz is what we should be telling people to use <anders_> I was just about to suggest repo.or.cz the main issue is admin overhead, i guess i.e. who's going to be responsible for running the show <anders_> eleusis: The plan longterm is to lower admin overhead. however, i don't think there's great demand for something like xmms2forge.. anders_: yeah <anders_> eleusis: To avoid setting up git repos manually, and copying ssh keys and stuff. i think i'll investigate it a bit further next weekend <anders_> No, there is no great demand, but I would be nice to have it in place before there is.

Clients development progress

Action:None

TOPIC: clients development progress Eclipser: mind telling us about what you've been doing on your client(s)? then there's the yet unnamed cover manager have you got the source for that somewhere? cover manager? it's not really usable yet My personal opinion is that most people want to manage that from their regular client, not a dedicated one. maybe so yeah, but that depends on people coding their 'regular clients'.. if it's to be done properly, it's not really that trivial :) And stuff should be shared as much as possible among clients, e.g. finding/retrieving the covers/proposing alternatives (did someone say service clients? ;p) theefer: you mean libraries, etc? theefer, I'm interested service clients! no, service client :) A "thing" that you ask to find covers for media X and that just does. theefer: we already have that, xmms2covers sets the cover and alternatives. nano-: yes but it's not formally usable by other clients, is it? theefer: and a client creates a view for swithcing between the alternatives. nano-: xmms2covers would be a service client nano-: yes, but in my mind it's not a service client (*yet*) because there is no "API" to use it from other clients alright, looks like we've generated a bit of discussion with the cover art stuff.. can we get back to this later, and go through some of the remaining agenda items for now? <anders_> I'd like xmms2covers to be a standalone application. Communicationg on stdin/out no mediaplayer agnostic. Matching the xdg-coverart stuff. dangertools: progress on your client(s)? http://crosswidgets.sourceforge.net/index.php/content/view/48/47/ <-- latest screenies/changes in x4x theefer: progress on your client(s)? x4x is a qt client now as well btw eleusis: working on a nyello rewrite, currently stuck on the command parser lib, but I have a pretty clear idea of how it will look like and coll integration.

Windows port

Action:None

TOPIC: Windows port nano-: want to tell us more about this? Yes, it's done. Now we can forget it. ;) binary should be made available somewhere I belive all changes for xmmsclient and xmms2d are in -devel.git now. It should compile out of the box. But the waf transition went well, and now it builds out of the box. Thus it's much more accessible to future development.

Neuros OSD

Action:None

TOPIC: Neuros OSD <anders_> eleusis: My OSD now allows listing the playlist and shows currently playing song on my tv. :) anders_: what's the mainloop problem you're having? <anders_> eleusis: I'll need to decide if I should include DrHouse or DrJekyll in their svn. <anders_> DraX: The nano-x mainloop used is crappy.

Collections client bindings

Action:Provide better documentation for Collections-related client bindings

TOPIC: Collections client bindings anders_, DraX: how is that progressing with python? <anders_> eleusis: done i'm going to be doing the ruby ones RSN, so if anyone has issues with that, speak now C# are almost done, lags a bit behind C++. anders_: just need to get the doc page done on the wiki? <anders_> eleusis: Just needs documentation (inline+wiki). <anders_> eleusis: (I have some refactoing of pythonapi available for preview in http://git.xmms.se/?p=xmms2-anders.git;a=shortlog;h=pythoncleanup) maybe I should go through collection bindings just to make sure everything looks sane ;) theefer: C++ collections? :P <anders_> theefer: They have in my refactored tree. anders_: I will have a look So, C++ collections are done, except for documenting the Coll class tree and the custom coll parsing function since rafl still isn't here, i guess we'll skip over the perl bindings..