15:02:19 <siretart`> #startmeeting
15:02:19 <MeetBot> Meeting started Thu Dec  3 15:02:19 2009 UTC.  The chair is siretart`. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:19 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:02:20 <lool> If the meeting hasn't started yet, I'd like to thank edrz for helping setup the meeting  :-)
15:02:30 <lool> Eh started now
15:02:46 <edrz> lool: glad to be of service.
15:02:49 <siretart`> First of all, a big thank you to every one who has managed to attend this meeting
15:03:04 <siretart`> and a big thanks to edrz of course for organizing
15:03:21 <free> yeah, that was awesome
15:03:23 <siretart`> I guess since this is our first meeting we should start with a short introduction round
15:03:32 <siretart`> #topic introduction round
15:03:44 <siretart`> who wants to start?
15:03:54 * edrz suggests the DDs go first.
15:03:55 <siretart`> edrz: perhaps you would?
15:04:09 <edrz> ok. i'm edrz.
15:04:21 <lool> hey, I'm Loïc Minier, I'm a DD since ~ 2004 and work for Canonical in the Foundations team; I used to do mostly GNOME for Debian, but less so nowadays
15:05:09 <lool> siretart`: Who are you anyway?
15:05:10 <edrz> my debian involvement thusfar has been mostly in helping the DebConf videoteam (not yet a DD)
15:05:41 <siretart`> I'm Reinhard Tartler, I'm a DD since 2005 and work at the university of erlangen as researcher
15:05:56 * lool (thinks this is IRC and we can all introduce at the same time and read the backlog)
15:05:58 <free> so, me? I'm Free Ekanayaka, work for Canonical as well (Landscape), I used to be the developer of 64 Studio, a Debian-based multimedia distro, but not really anymore, DD since 2004
15:06:19 <siretart`> I'm also an active ubuntu developer and try to minimize divergence in multimedia applications between these two distros
15:06:27 * edrz thinks free should mention also DeMuDi/Agnula.
15:06:49 <free> edrz: oh, what is *way* back :)
15:06:56 <free> s/what/that/
15:07:00 <siretart`> LucidFox: around?
15:07:08 <LucidFox> Yes
15:07:31 <siretart`> Fuddl wanted to attend as well, and he was sitting next to me a few minutes ago. oh well
15:07:42 <bdrung> hi, I am Benjamin Drung, a computer engineering student at TU Berlin, a DM (intend to become DD) and a Ubuntu Developer (since a half year), i maintain the audacity package and doing some merges
15:08:11 <fsateler> well, I'm Felipe Sateler, I've been involved in Debian since ~2006, but I'm not a DD yet. In real-life, I'm an Engineer student (and wannabe guitar player :p)
15:08:25 <edrz> we had Linux Audio Conference in ... um,  2007 at TU Berlin.
15:08:27 <LucidFox> I'm Maia Kozheva, a volunteer Ubuntu developer who contributes Ubuntu changes back into Debian whenever possible. I maintain the smplayer and smplayer-themes packages in the project.
15:08:40 <helmut> I'm Helmut Grohne, no DD, maintaining two packages, japa inside -multimedia, mostly reporting bugs on any part of debian, and not attending this meeting, because I gotta go.
15:08:58 <free> ouch
15:09:11 <lool> Do we have an URL to the agenda?
15:09:14 <helmut> (and not likely to be present on any of the suggested places)
15:09:23 <siretart`> lool: http://wiki.debian.org/DebianMultimedia/Meetings
15:09:23 <bdrung> edrz: in 2007 i was only an user and not a developer
15:09:23 <free> helmut: would another day time be better for you?
15:09:26 <lool> thanks
15:09:33 <siretart`> lool: but I think we should change the order a bit
15:09:49 <siretart`> so I currently count 4 DDs (fuddl is the forth one) and 5 non-DDs in this meeting, right?
15:09:57 <helmut> free: well. as the topic is about rl meeting, it won't help me at all, since I most likely cannot attend.
15:10:04 <siretart`> I know that we have some more non-DD members active on the mailing list, though
15:10:44 <free> yeah, Mira for instance (I think he's not here)
15:11:03 <siretart`> or Fabian Greffrath (not ircing at all in general)
15:11:06 <edrz> helmut: we're talking about more than the reallife meeting, and i think free meant is there another time that's better for you for IRC meeting ...
15:11:22 <edrz> that is a topic at the end of this meeting.
15:11:23 <free> edrz: that's it
15:11:38 <free> okay, let's keep on track
15:12:00 <edrz> so, end of introductions, onto first topic?
15:12:01 <siretart`> okay, so that would have already been point 6 on the agenda, now we know who is DD
15:12:07 <adi> Adrian Knoth, no DD, researcher for high performance computing at Jena University. I've been involved in digital media production for years, run a small recording label, play the piano and guitar, do a lot of music production right now.
15:12:15 <helmut> edrz: ok. I'll keep here for a little longer than intended.
15:12:28 <edrz> helmut: great
15:12:44 <siretart`> let's discuss sponsoring the non-DDs, okay?
15:12:56 <siretart`> #topic sponsoring and spreading the load among DDs
15:13:24 <siretart`> in general, I think that I'm a fairly regular uploader, but I know that there is still quite a backlog for packages
15:13:46 <free> indeed
15:13:57 <siretart`> espc. for jack related packages, as I'm not really confortable with reviewing them. mostly because I don't use jack and am not familiar with these packages
15:14:14 <siretart`> do other's feel the same?
15:14:21 <siretart`> any ideas how we can improve the situation?
15:14:29 <lool> I personally almost never sponsor these days; mostly due to lack of time, and also because I'm reluctant to upload without testing and to test things I don't use regularly -- I know it's not ideal :-/
15:14:39 <bdrung> is there someone, who uses jack?
15:14:47 <free> I've been very close to jack for years
15:14:49 * adi uses it every day
15:14:56 <edrz> once I get at least a minimal studio settup again (hopefully within the next week or two) I can help more with reviewing adi's work.
15:15:01 <free> I feel comfortable with it, but I lack time for uplaods, as lool
15:15:24 <lool> siretart`: One related issue is that the spectrum of packages in pkg-multimedia is widening rapidly
15:15:28 <free> adi: btw, thanks again for the wonderful job :)
15:15:47 <fsateler> lool: that's probably a side-effect of the merge of the multimedia teams
15:15:54 <lool> True
15:15:54 <free> lool: we're also getting some new forces though
15:15:54 <siretart`> lool: indeed, I'd like to discuss this as next point: 'package lifecycle and scope'
15:15:58 <edrz> so, i think one of the priorities needs to be getting more of us as DDs or DMs
15:16:15 <lool> siretart`: Ah perfect, thanks
15:16:15 <free> edrz: I agree
15:16:16 <adi> edrz: Has a DM the rights to upload something?
15:16:19 <fsateler> I'm already in NM
15:16:22 <lool> adi: yes
15:16:22 <siretart`> but the topics seem pretty related.
15:16:29 <lool> adi: Only the packages which are flagged as such though
15:16:36 <bdrung> adi: yes (but only his own packages)
15:16:37 <siretart`> adi: yes, a DM can upload package he is a registered co-maintainer for
15:16:46 <edrz> adi: i think that's the point of DMs, right? upload rights, but not voting rights.
15:16:49 <siretart`> adi: a DM cannot sponsor, though
15:16:54 <edrz> ah
15:16:55 <free> adi: so for instance I could register you as uploader for ardour and jack
15:17:00 <lool> I think we can define a couple of best practices to help sponsoring
15:17:23 <free> becoming DM is a way lighter process than becoming DD
15:17:26 <siretart`> as for sponsoring in general, I'd really apprciate if sponsorees would explicitly state that and how they have tested the changes in the to be uploaded package
15:17:27 <helmut> lool++
15:17:28 <lool> One thing I care about when sponsoring is being able to easily understand and review individual changes
15:17:35 <free> and I guess for many of us non-DD would suffice
15:17:40 <siretart`> this way I would feel much more comfortable with uploading packages
15:17:41 <lool> I really care about high quality changelogs and whenever possible fine grained commits
15:18:10 <siretart`> lool++
15:18:18 <bdrung> lool++
15:18:20 <lool> I often get large debdiffs with a new upstream version in the middle of random packaging updates; this makes it hard to review
15:18:34 <lool> Using a Vcs is of course recommended
15:18:49 <edrz> lool: that is pkg-multimedia policy, now.
15:18:49 <siretart`> does anyone volunteer to compile such a 'best practice/guidelines' document?
15:18:51 <free> I think we have a policy of only uploading packages in git right?
15:18:59 <siretart`> I think wiki would be fine
15:19:02 <lool> I much prefer bzr/git here because I can quickly diff all commits; I can live with SVN, but when reviewing commits it's painfully slow
15:19:07 <free> siretart`: hhm, I have it already basically?
15:19:10 <fsateler> but what would be missing from the guidelines in the wiki?
15:19:12 <free> s/I/we/
15:19:27 <edrz> siretart`: i do. i'll go back through the logs and do my best to translate to the wiki, request comments/review/additions/corrections, etc
15:19:30 <siretart`> free: link?
15:19:51 <siretart`> thanks
15:19:52 <fsateler> http://wiki.debian.org/DebianMultimedia/DevelopPackaging
15:20:05 <siretart`> fsateler: ah right, of course
15:20:18 <free> siretart`: http://wiki.debian.org/DebianMultimedia/FAQ
15:20:26 <edrz> #action edrz agrees to update wiki with stuff agreed in this meeting.
15:20:38 <siretart`> that list is rather about general recipes for packaging
15:20:57 <siretart`> I think lool meant more some sort of checklist, or at least a more terse document?
15:21:09 <fsateler> perhaps what needs to be done is reorganizing the information
15:21:12 <free> siretart`: if you see the FAQ, it basically says we upload only packages under git
15:21:24 <lool> siretart`: Yup
15:21:31 <lool> Will be http://wiki.debian.org/DebianMultimedia/Sponsoring
15:21:34 <free> fsateler: it has grown a bit messy indeed
15:21:34 <lool> [link] http://wiki.debian.org/DebianMultimedia/Sponsoring
15:21:39 * lool slaps bot
15:21:44 <siretart`> heh
15:21:54 <edrz> fsateler: i agree. there is good info on the wiki, but in general it needs some attention.
15:22:05 <edrz> to reorganize, update, etc.
15:22:05 <siretart`> fsateler: any idea how we can reorganize our wiki space?
15:22:38 <bdrung> should we recommend the new source format 3.0 (quilt)?
15:22:55 <siretart`> I guess this is a really hard task, and I don't really have a good idea how to approach it
15:22:56 <helmut> I'd be agains 3.0, because it makes backporting harder.
15:22:59 <edrz> lool: MeetBot uses command of the form #<command>.
15:23:04 <bdrung> with single patches having a DEP-3 header?
15:23:16 <edrz> lool: proper urls should get picked up automagically.
15:23:38 <fsateler> no, not really. I'm still not quite sure what classes of information we need in the wiki
15:23:43 <siretart`> bdrung: I tried format 3.0 (quilt) for one package, and I noticed that there are still quite some rough edges in git-buildpackage
15:24:00 <siretart`> bdrung: for this reason, I'd prefer to wait with mandating it for all packages
15:24:07 <bdrung> siretart: you can use debiuld instead (for example audacity)
15:24:18 <helmut> can we delay  recommending format 3.0 until squeeze is stable?
15:24:36 <siretart`> bdrung: true, that was the workaround. still not exactly what I'd expect from tools :/
15:24:41 <lool> I see no hurry in going to 3.0/quilt
15:24:44 <fsateler> helmut: why? lenny does support 3.0
15:24:57 <helmut> fsateler: lenny is oldstable then. ;-)
15:25:01 <lool> The immediate win I can see is avoidance of timestamp skews, that's all
15:25:03 <fsateler> oh ok
15:25:04 <edrz> siretart`: has a bug for that been filed on git-buildpackage?
15:25:37 <siretart`> edrz: I haven't yet with the issue I've noted, I want to do some deeper analysis first
15:25:40 * fsateler thinks we have strayed from the topic
15:25:44 <siretart`> indeed
15:25:56 <helmut> fsateler++
15:25:59 <siretart`> the current topic would be
15:26:06 <siretart`> #topic improving packaging guidelines
15:26:26 <siretart`> lets summarize that we'd like to mandate DEP-3 headers and defer switching to format 3.0?
15:26:33 <siretart`> then we could move on to the next topic :-)
15:26:35 <helmut> siretart`++
15:26:40 <fsateler> agreed
15:26:43 <bdrung> siretart++
15:26:50 <edrz> #agreed  we'd like to mandate DEP-3 headers and defer switching to format 3.0
15:26:55 <siretart`> excellent
15:27:07 <siretart`> #topic Package lifecycle and scope of the team
15:27:25 <free> so what does the topic mean exactly?
15:27:32 <siretart`> we already mentioned this before, some feel that the scope of our team is too broad
15:27:33 <lool> Sorry back to packaging: do we recommend any of dh 7 or CDBS?
15:27:57 <free> siretart`: the scope or the number of packages involved?
15:28:10 <lool> I think the world is moving to "dh" at this point; I've started using it and it's great; I wouldn't go out of my way to repack existing CDBS stuff, but I do repack some dh_* stuff into dh
15:28:12 <free> I'd prefer dh 7
15:28:18 <siretart`> lool: good question. I think it is a matter of preference. but TBH, I think it helps if it matches the preference of the uploader/sponsor :-)
15:28:19 <bdrung> i would recommend debhelper (>= 7)
15:28:40 <edrz> lool: there is not currently a policy, but, in disucssing earlier with siretart` it came out that most likely DDs only review/sponsor stuff managed w/ helpers they use themselves.
15:28:41 * siretart` prefers debehlper (both pre and post 7) over cdbs
15:28:46 <free> I fee the same as lool
15:28:55 <lool> I'm fine sponsoring non-crazy packaging, but I see that people make less mistakes with CDBS or dh 7, even if they might not understand the low level details
15:28:57 <free> s/fee/fell/
15:28:58 <helmut> I'd prefer letting this choice for the one maintaing a package.
15:29:10 <siretart`> helmut: maintaining or uploading?
15:29:19 <helmut> siretart`: maintaining, not uploading.
15:29:34 <adi> Huu? I found cdbs pretty useful, it took care about changed files like autoconf. If dh would provide this, too, then I'm fine with it.
15:29:39 <helmut> siretart`: of course the choice may have impact on the number of uploaders. ;-)
15:29:46 <siretart`> helmut: exactly
15:29:49 <free> adi: dh 7 does it
15:30:01 <lool> I'm fine leaving room to the maintainer, but I see the same mistakes over and over every time I sponsor and have to train people every time, it's really a waste of time when compared to picking a higher level abstraction    :-/
15:30:02 <free> but no need to rush for dh 7, IMHO
15:30:06 <bdrung> letting the maintainer decide between dh 7 and debhelper (recommending a clear rules file)
15:30:16 <helmut> siretart`: then a summary of which sponsors support which tools would be helpful.
15:30:46 <lool> Let's list it on the sponsoring page
15:30:49 <siretart`> okay, I already stated my preference. What about other sponsors/uploaders?
15:30:54 <edrz> perhaps the team can adopt a reccomendation of one or 2 (perhaps dh7, cdbs) but, not mandate it?
15:31:01 <free> I'll list mine
15:31:07 * lool just edited the page
15:31:47 <edrz> great
15:31:54 <siretart`> ah, excellent
15:31:57 <free> look which one exactly?
15:32:04 <siretart`> http://wiki.debian.org/DebianMultimedia/Sponsoring
15:32:12 <lool> At this point, I also feel more confortable with packages using debian/patches rather than committing changes directly in the git repo
15:32:17 <free> oh okay
15:32:33 <edrz> #action DDs will list their packaging tool preference on http://wiki.debian.org/DebianMultimedia/Sponsoring
15:32:40 <free> lool: I think that's a guideline we have
15:32:43 <siretart`> lool: I'd like to amend this with recommending or even mandating quilt over other patch systems
15:32:52 <lool> siretart`: +1
15:32:59 <fsateler> siretart`++
15:33:02 <helmut> siretart`++
15:33:03 <edrz> siretart`: quilt is already mandated, yes?
15:33:15 <edrz> #agreed quilt is mandated.
15:33:20 <fsateler> its a "should"
15:33:23 <lool> I see "#"
15:33:24 <lool> Packages should use git, as mentioned above. Desirable is being able to use git-buildpackage.
15:33:28 <siretart`> I believe not explicitly, but I really hope that we don't have too many packages with other patch systems than quilt
15:33:29 <lool> #
15:33:30 <lool> quilt should be used for patch management, and the master branch should only differ from the upstream branch in files inside the debian/ directory. This means no direct changes to the source in the master branch.
15:34:19 <fsateler> maybe we should define "should" and "must"s in the team policy
15:34:25 <siretart`> how is "format 1, maintained with git with quilt is strongly recommended, exceptions may be made if the regular sponsor/uploader agrees"?
15:34:43 <lool> siretart`: Sounds good
15:34:50 <free> siretart`: cool
15:34:50 <adi> A general note here: I always try to lower the amount of debian specific patches. Though this cannot work for all packages, I find it way easier to let upstream correct the code. ;)
15:35:06 <helmut> siretart`: what about existing packages deviating from this? do they have to be converted for the next upload?
15:35:17 <bdrung> do we recommend lintian (-iIE --pedantic) clean packages?
15:35:21 <fsateler> siretart`: s/strongly recommended/required/
15:35:34 <lool> Oh we could require usage of the DEP on patch-descriptions
15:35:44 <lool> As well as submitting patches upstream before you upload a package with them
15:36:12 <lool> This is an idea which came up after the openssl issue, and also when we looked at avoiding some delta between Ubuntu and Debian
15:36:19 <siretart`> lool++
15:36:30 <bdrung> lool++
15:37:13 <fsateler> are there any tools for working with DEP-3 yet?
15:37:27 <siretart`> fsateler: I remember a patch for lintian is being discussed for this
15:37:32 <bdrung> git-format-patch or something like that?
15:37:45 <lool> bdrung: lintian > sounds like a sponsor-thing I think
15:37:54 <bdrung> lintian complains about a missing patch header
15:37:59 <siretart`> ah no, that was for DEP-5 (copyright files). anyway, lintian sounds like the correct place for this
15:38:14 <edrz> #info require DEP in patch-descriptions, submit patch upstream before upload.
15:38:21 <lool> Could someone take action to update policy?
15:38:51 <fsateler> I'll edit DevelopPackaging
15:38:52 <siretart`> I can try this.
15:38:59 <siretart`> ah, excellent, fsateler was faster :-)
15:39:09 <lool> I added lintian to the sponsoring best practices
15:39:13 <edrz> #action siretart` fsateler agree to update DevelopPackaging on wiki
15:39:26 <siretart`> great
15:39:31 <siretart`> shall we move on? :-)
15:39:36 <bdrung> lool: recommend to check with "-iIE --pedantic", too
15:39:39 <lool> Yes, time is running out
15:39:42 <adi> We could also think about automated package testing. Not instantly, but I think something like "debian/rules test" would be good to catch common errors
15:39:50 <lool> bdrung: I'm using different flags and I think other sponsors will do as well
15:39:51 <edrz> siretart`: we didn't quite address the scope of team issue.
15:39:51 <siretart`> adi: out of scope for first meeting
15:39:55 <adi> ACK
15:40:00 <siretart`> right
15:40:04 <lool> bdrung: For instance I also list overrides and am not intersted in the pedantic tags
15:40:20 * lool uses lintian -I -E --show-overrides --color auto
15:40:34 <helmut> please move on
15:40:38 <siretart`> Thre reason why I added the topic are teh following question:
15:40:50 <siretart`> which requirements has a new propsed package to be adopted by the team
15:40:52 <siretart`> and
15:41:01 <lool> siretart`: Please secure at least the last 5 minutes to discuss next meeting
15:41:09 <siretart`> under which situations do we want to consider orphaning or removing the package from the team and/or debian
15:41:25 <siretart`> lool: OK
15:41:55 <lool> Would it make sense for at least 2 people to agree to maintaining the package in the team before adding packages as "team maintained"
15:42:10 <bdrung> i recommend to have one person, who is the contact partner for the package
15:42:10 <lool> Also, at least one DD should be ok to sponsor the package in the two maintainers aren't DD
15:42:25 <helmut> bdrung++
15:42:33 <lool> One person sounds like this will allow for people to push their pet packages in the repo without limit on team-useful packages
15:42:44 <bdrung> we may have a wiki with this information
15:42:51 <siretart`> I like lools idea. if we agree on this, I think we should document this fact by adding the two persnos in the Uploaders field in the package
15:43:14 <fsateler> lool: I think the real problem is "what kind of packages are acceptable for the team"
15:43:37 <free> do we have packages that we feel are border-line, ATM?
15:43:40 <fsateler> requiring 2 people creates a problem with an understaffed team like ours
15:43:51 <lool> fsateler: It's kind of the intended goals
15:43:54 <siretart`> fsateler: lool suggestions works around answering this question by testing interest of team members. I actually like this
15:44:08 <lool> fsateler: Do packages which are only relevant to a single person belong in the team?
15:44:15 <siretart`> the thing is, how do we deal if the people listed start to lack interest in the package?
15:44:30 <edrz> siretart`: is the definition of "team member" people with alioth accounts added to the team?
15:44:30 <fsateler> hmm, it depends on the goals of the team
15:44:35 <edrz> or something else
15:44:42 <lool> edrz: That would be ok I think
15:45:03 <siretart`> edrz: I agree with look. accounts are granted pretty easily, after all
15:45:10 <lool> fsateler: Yes, but if a single person is interested the package can be pushed to e.g. collab-maint and similar effects as the pkg-mm team can be achieved
15:45:41 <free> lool: I'm not sure non-DD can write to collab-maint
15:45:51 <siretart`> free: they can apply for the collab-maint team
15:45:52 <bdrung> free: they can
15:45:53 <edrz> #info a team member is a person with an alioth account who has been added to pkg-multimedia-maintainers team
15:45:53 <lool> They can but need to be added
15:47:20 <siretart`> so does the idea to use the 'Uploaders' field to list the regular sponsor and at least one supporter has potential to reach consensus?
15:47:49 <bdrung> i am unsure if the 'Uploaders' field is the right place.
15:48:03 <siretart`> bdrung: why?
15:48:23 <bdrung> there can be people, who are inactive in the list
15:48:45 <siretart`> inactive people should be removed from the list as soon as we are aware of that fact
15:48:57 <siretart`> but that's a general rule AFAIUI
15:49:08 <bdrung> k
15:49:11 <siretart`> we should enforce it then, though
15:49:32 <siretart`> free, lool, what do you think?
15:49:53 <lool> I'm fine with uploaders
15:50:01 <free> enforce is a bit tough IMO
15:50:02 <lool> it's just for lintian and maintainers anyway
15:50:13 <bdrung> i suggest to have your proposed rules plus an wiki page with one contact person
15:50:18 <free> but if the majority agrees, I'm fine
15:50:21 * fsateler thinks my packages will have to move away from the team repo :(
15:50:23 <bdrung> for each package
15:50:28 <lool> I think we don't need very strict rules to handle MIA maintainers and abandonned packages
15:50:36 <siretart`> free: let's discuss the "enforcment" (we haven't had that part yet)
15:50:37 <lool> We can have a list discussion to cover these when we discover them
15:51:00 <edrz> lool: ++
15:51:10 <siretart`> I imagine that if a package has less than two interested people, we note the package on a 'red list'
15:51:11 <lool> This is no different than random packages in the archive, we should adapt to each situation, depending on whether the package is important or not etc.
15:51:26 <siretart`> if the package is on the list longer than N months, we consider orphaning/removing it
15:51:39 <siretart`> as N I would suggest something like 6 or so
15:51:50 <fsateler> s/orpahning/moving to collab-maint/
15:52:06 <siretart`> oh, that sounds great as well!
15:52:11 <fsateler> if there is still 1 person intersted
15:53:00 <edrz> so, then can we state and agreement?
15:53:05 <edrz> *an
15:53:14 <lool> Fine with me
15:53:15 <lool> 7 minutes left
15:53:16 <siretart`> anyone who disagree or has concerns?
15:53:34 <lool> Let's move to discussing the next meeting date/time/location after this topic
15:53:42 <bdrung> two interested people = two people listed as uploader?
15:53:43 <free> I'm fine with the N months solution
15:54:07 <siretart`> undiscussed agenda items: debimedia and  pulseaudio promotion. do I miss something?
15:55:07 <siretart`> the closing of the abandoned 'debian-multimedia' alioth project can be carried on the mailing list, I think. I believe its uncontroversial
15:55:28 <siretart`> okay, how regular do we want to do these meetings?
15:55:32 <siretart`> how does monthly sound?
15:55:43 <edrz> #info topics postponed to next meeting: debimedia, pulseaudio, mentoring sessions.
15:55:54 <free> monthly sounds good to me
15:56:10 <edrz> yup
15:56:12 <free> or even two weeks in the first period
15:56:13 <siretart`> okay, the next meeting would be then early january
15:56:28 <edrz> shall I set up a new poll on doodle?
15:56:32 <siretart`> I'd suggest that we use doodle again for the first two weeks in januar to find a time?
15:56:36 <fsateler> I think that meeting policy should be related to the amount of items to discuss
15:56:45 <bdrung> two weeks, if we have not enough to discuss, we can make it monthly
15:56:54 <siretart`> fsateler: do you suggest an earlier meeting?
15:57:48 <fsateler> siretart`: at least to cover the items we have postponed
15:58:11 <siretart`> I believe that before christmas, it might be difficult to find a time, but we can of course try
15:58:24 <edrz> i was going to say something similar.
15:58:49 <edrz> if it were a different time of year i might agree with fsateler + bdrung
15:58:59 <free> so let's make it in january
15:59:03 <siretart`> agreed
15:59:09 <free> I agree this is an unfortunate period of the year
15:59:16 <siretart`> edrz: can you setup the doodle poll again?
15:59:17 <bdrung> agreed
15:59:38 <fsateler> true
15:59:50 <siretart`> if not, no problem, I can take over
15:59:50 <edrz> #agreed edrz will create a new doodle poll for next meeting polling for dates/times in first 2 weeks of 2010.
15:59:55 <siretart`> excellent
16:00:16 <siretart`> well, then let's adjorn the meeting, Thanks to all again for attending!
16:00:28 <lool> who's going to FOSDEM?
16:00:35 <siretart`> aaah, right that's important
16:00:36 <edrz> siretart`: can you tell meetbot?
16:00:40 <siretart`> #stopmeeting
16:01:01 <siretart`> lool: I'm still strongly considering
16:01:10 <edrz> siretart`: it's endmeeting
16:01:11 <siretart`> but I have no ticket and hotel yet
16:01:23 <siretart`> #endmeeting