<bmon> lets get started <lewing> ok so, you guys set this up what order do you want to take things in <bmon> I figured as we listed them unless there was some other preference * rubenv approves silently <bmon> #1 is code commitals <lewing> Ok, sounds good <bmon> Right now Larry/Gabriel are the only ones with commit <bmon> and it can end up being a bit of a bottleneck if they are busy or not around <lewing> well everyone with a gnome-cvs account could commit <lewing> just to be clear <bmon> What does everyone think about the proposed idea of having commit by committee? <abock> rubenv: did you get your cvs account? * sde agree * bengt agree <rubenv> I'm not sure that's a good idea, having a sherrif (look at what abock does in banshee) is a good thing <lewing> so what number are you thinking of for X? <rubenv> given good response time <rubenv> abock: http://cia.navi.cx/stats/author/rubenv <ajmitch> bmon: explain how it'd work, please <bmon> Lets say I write a patch <massis> i agree with rubenv <ajmitch> would all members need to sign off on a patch for it to commit, or would this just be a trusted group of committers? <bmon> then I would need X other devs to review and ok it before it went it <bmon> I was thinking X=2 * rubenv does like the group review process that was started for the XMP import process (though I didn't follow it closely because I had to work) <bmon> but that would be something we would need to decide <massis> lewing: do you see yourself getting up to speed again after you return from vacation * massis thinks the commit pace was pretty good some months ago <lewing> massis: http://cia.navi.cx/stats/author/lewing <lewing> that isn't exactly bad * bengt likes this group review, especially for bigger patches <lewing> considering guadec a week of vacation and a week of meetings this month <massis> so the answer is yes ;) <gabaug> lewing: the month break back in April/May was ;) <bmon> I think we want group review for big patches whether or not commit by committee happens <lewing> gabaug: were it only a break <sde> but e.g., for the XMP import thing, when 3 guys will say 'it's ok to reach CVS', who will take the final decision ? <ajmitch> bmon: even with group review, there has to be someone who will commit, rather than thinking the other guy will <wjbaird> bmon: I'm a bit confused --- what's the difference between group review and "commit by committee"? <lewing> sde: me <bmon> wjbaird: I took group review to be that we all need to be reviewing patches <sde> lewing: nice. <sde> lewing: that's what I thought. <lewing> ok let me start with what I would like to see * rubenv prefers having lewing as a steering dictator, design by committee leads to crap :-) * sde agree with rubenv <bmon> ajmitch: correct, either Larry/Gabriel would commit, or one or more would be given commit rights, with the understanding they are only to be used for this * bengt says good point rubenv <lewing> I would like to see the small clear cut fixes have a couple of eyes look at them and they go in without anything from me <bmon> I don't really see it as design by committee necessarily <rubenv> trivial bugfixes & oneliners? <bmon> we all should be on the same page from the meetings <abock> lewing: yeah, that's what I tend to do, and I think it's been working well <abock> rubenv, gabaug, trick are all good about keeping the patches reviewed, and getting the simple stuff committed <abock> and larger patches we review more strictly, and I'll do throrough testing, and commit <lewing> I would like to see bigger patches reviewed and tested by as many people as possible and then we discuss the implications on the bug with those of you who are active weighing in <rubenv> offcourse he doesn't mention that we're scared to death of breaking things, we don't want to upset abock <lewing> and I make the final call <bmon> lewing: that sounds reasonable to me * rubenv approves <wjbaird> lewing: I agree. * massis agrees * bengt approves <lewing> if I'm not around for a long period you can get on my back again <sde> sound greats <massis> lewing: looking forward to that ;) <bmon> lewing: I, and some others we're getting worried that patches we're building up <lewing> bmon: I understand <lewing> and some have been, but a lot are going in too * abock likes <lewing> we just need to pick up the pace <rubenv> let's do a bug & pending patch cleaning first then <bengt> A lot of the patches starts to depend on other patches... <bmon> Assuming you have the time to handle it, I think it should be fine <lewing> I've been incredibly happy with all the organization you all have been doing lately <wjbaird> can we add as 'reviewed by' field to bugzilla? make it easy to find all bugs with reviewed patches? * rubenv would like to deprecate all of his patches (but more about that later) <lewing> so I've stayed out of the middle of it <gabaug> wjbaird: you can mark bugs are reviewed if you have the right permissions <bmon> OK, so trivial stuff to go in after having a couple people look at it <rubenv> I have the habit of marking reviewed patches as accepted_commit-now as a signal to abock <lewing> yeah marking bugs as "accepted commit now" could be a good way of indicating I need to take the last step or add feeback <bmon> big stuff reviewed by as many as possible but lewing does final commit <sde> bmon: for small fix, it's already the case, larry is quick with those ones. <bmon> rubenv: can anyone do that? or just those with commit access? <wjbaird> gabaug: cool --- can we add those privs to everyone in the review committee? Then lewing and others can easily search for small stuff that's been approved? <rubenv> I think you need the editbugs permission in bugzilla <bengt> bmon: You need bugzilla rights... <massis> sde: but lewing would like to get rid of those it seems :) <sde> bmon: everyone with write access to bgo <gabaug> part of the problem for me has always been the big patches/changes...it's often much better to get multiple people working on them, but then that's a pain w/ e-mailing patches back and forth <bmon> sde: The idea is to take as much work off of lewing's plate as possible <lewing> gabaug: agreed <abock> lewing: yeah, I take that as a hint <bmon> so he can dedicate his time to the more important things <lewing> gabaug: have any thoughts on to how to make that esier? <rubenv> I use bzr branches on my laptop to maintain big patches <sde> flame on: what about switching to svn ;);) <abock> I think (hope) there's an unspoken rule that if a patch *is* marked as such, it's meant for me <ajmitch> rubenv: yes, that's made easy with the launchpad import/cvs conversion to bzr <abock> but that it has had good review and testing <rubenv> abock: I consider it as such <abock> yeah * bengt dreams of svn... <lewing> sde: gnome keeps trying and failing to switch I keep waiting and hoping <ajmitch> we could get into endless discussions about the right vcs <sde> yes, I know, that's why I typed those smileys... <lewing> ah :) <lewing> anyone here used git much? <ajmitch> a bit <lewing> opinions? <ajmitch> it's fast, but I still prefer bzr for usability <wjbaird> lewing: Nope - but we switched to svn where I work a while back, and we're pretty happy with it... <bmon> ajmitch: are you maintaining a bzr tree for the ubuntu package? <ajmitch> currently maintaining the debian/ubuntu packages in bzr, with various patches from cvs in bzr branches <gabaug> lewing: does the flat directory structure and existence of old, unused files bother you as much as me? I've been so dissapointed by the failed switches to SVN b/c I really want the f-spot source reorganized.. <lewing> ok, so for now switching repos is still on hold, but trust me when I say I would like to switch just as much as the rest of you * sde also switched to svn. and it's easy for cvs users... <rubenv> gabaug: YES! <lewing> gabaug: bothers me daily <gabaug> I didn't notice it too much before working on banshee more :) <lewing> there shouldn't be any dead files still, are there? <rubenv> there's a lot of dead code though <lewing> well other than the mail stuff <abock> lewing: you'd consider moving away from gnome version control? <gabaug> lewing: there were months ago (at least in my copy)...I'll let you know if I find any <bengt> We covered the first point on the agenda I take it, <bmon> Are we ready for item #2> <rubenv> bengt: abock still had a good question :-) <lewing> abock: if something doesn't change soon I'm going to reach my breaking point <abock> as am I <sde> lewing: about dead code: yes, some <abock> I have been blocking for weeks on the migration, now most are saying post 2.16 <gabaug> isn't is pretty easy to copy the svn repo back into gnome once they finally switch? <bmon> #2 What should the review procedure be for submitted code? <rubenv> bmon: not so fast! <lewing> yeah definitely some dead code, and because of the cvs thing a lot of classes that should be split into separate files <lewing> I just hate making or remving files in cvs, such a pain :( <abock> yeah, I have tons of files that need splitting, reorganizing, etc... not possible with cvs without a ton of work and loss of history <lewing> exactly <abock> a lot of the reorg I want to do should help both f-spot and banshee <lewing> yeah <abock> in terms of (cue: rubenv) a common class library * rubenv wants to bring up the point of banshee <-> f-spot code sharing too <abock> yeah <rubenv> i'd call it libcoolness until someone invents an ever cooler name ;-) <gabaug> abock: hmm....sounds familiar...;) <rubenv> *even * sde jsut ported the banshee plugin code to f-spot <rubenv> anyway, abock has made some really nice classes in banshee (like the QueuedSqliteDatabase) <abock> last night I wrote a scheduler that might be useful * gabaug laughs <rubenv> and more related to what I was making lately: a jobscheduler <abock> haha <rubenv> abock: http://bugzilla.gnome.org/show_bug.cgi?id=337724 <gabaug> I definitely like the idea of shared app functionality..I was pushing it with abock/lewing months ago <rubenv> abock: look for src/JobScheduler.cs in that patch <bmon> agreed <sde> so, about code refactoring: wainting for svn.gnome.org ? <bmon> it could be a big win for both, plus any other mono apps in the future that want to use it <gabaug> I think we should switch...assuming it isn't hard to move the svn repo back to gnome servers once they switch <ajmitch> or another vcs - if we want to go down that road <lewing> sde: for some things, but refactoring where the repo doesn't get in the way is fine <bmon> ok ready for #2? <rubenv> abock: but most of that need a second look, much crack in there <sde> bmon: ready <bmon> #2 What should the review procedure be for submitted code? <rubenv> didn't we just cover that? <massis> that's more or less tackled, no? <rubenv> someone posts a patch in buzilla <rubenv> we pick on it until the author cries and the patch shines like gold ;-) <bmon> someone wanted it added to the list to maybe come up with a more formal way, but I'm fine with the informal <bmon> ok #3 then <wjbaird> and then...? how do we track offical reviewer approvals... <sde> I'm not in favor of having too formal things <rubenv> wjbaird: do we need a strict procedure at this point? <bmon> sde: I tend to agree, thats more for work :) <gabaug> wjbaird: you make a comment on the bug <lewing> 1) scan patch for obvious problem, 2) apply patch 3) test that patch fixes problem 4) read patch more carefully, check to make sure that any changes might break existing functionality 5) think if the patch is really the right way to solve the problem <rubenv> in the end larry calls the shots, it's not like it can run out of control <wjbaird> well - it'd be good for lewing et al to be able to quickly find anything that's ready to check in... <bmon> lewing: sounds good <massis> and small fixes get the accepted-commit-now tag to ping lewing --- zbowling is now known as zbowling-zzz <lewing> if you find a problem at any step in the process add a comment and mark the patch appropriately --- zbowling-zzz is now known as zbowling <gabaug> lewing: it looks to me (http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate) that it is very doable to move a SVN repo from one server to another <bmon> #3 Overall direction of the project <sde> lewing: what about patches that will never ends up in CVS ? <lewing> sde: ummm.... never is a long time :) <bmon> This I guess is more directed at lewing, but I'd guess he'd like input as well <gabaug> In terms of development, my priorities are 1) reorganize the source tree 2) move to UIManager 3) add plugin support <sde> when I say never: it's for un-reasonable enhancement requests <lewing> sde: honestly I don't know what the best thing to do about those is <sde> lewing: my guess, close the bug as WONTFIX... <bmon> WONTFIX is kinda harse <bmon> but I'm not sure just leaving it there is much better <bmon> harsh <bengt> or re-prioritize as enhancement/low <rubenv> ah, we have that problem with banshee too <lewing> sde: before that, perhaps try to encourage the person to look at the problem in a different way <rubenv> there's too much crack floating around <bengt> and if the concensus is still the same 6/12 months down the track... wontfix. <lewing> and mark it low priority for sure <wjbaird> bmon: It's not that harsh if it's accurate... and it's better to have them not cluttering up the bug lists... <lewing> ok for #3 see http://f-spot.org/Goals <lewing> which is by no means official, or by priority <rubenv> Track ids for flickr and picasa to map back to the original. <bmon> I guess there are two things <lewing> just a rough cut of the things I'd like to see fixed <rubenv> that's my secret roadmap! <bmon> 1) is it kept up to date? <lewing> or added <lewing> bmon: that page? I wrote it 20 min ago :) <bmon> OK, perfect :) <bmon> hot off the presses <lewing> you'll be able to tell by the wording and typos :) <bengt> :) <bmon> 2) Do we have a mission statement anywhere? <bmon> to give a more general view I guess? <massis> lewing: duplicates detection? <wjbaird> Personally, I'm interested in more strategic info... Are we aiming at 'my mother' / technically advanced amateur/semi-pro/pro/etc? <lewing> massis: eep! * bengt don't see the resize email in the goals :( :) <lewing> bengt: also on the list high up <lewing> like I said, that is a brain dump, let me add those <bmon> Maybe in meeting #2 we could work out some priorities for the goals? <sde> do you have plans to implements plugins in f-spot <sde> ? <gabaug> massis: the same alg. for doing dupe detection is used to "reconnect moved images" <bmon> after everyone has a chance to comment on the list and its more complete <gabaug> I assume.. <bengt> Would it be possible to come up with a list of goals to try to have implemented before next release of Gnome? <sde> bengt: good point <bmon> Are we going to try to match Gnome release schedule now? <massis> gabaug: what do you mean? detecting files that have moved? is there a patch for that? <rubenv> urgh no, no long freezes! <lewing> gabaug: indeed <gabaug> massis: no, just saying they are related.. <lewing> rubenv: absolutely <lewing> so let me say, to all of you <bengt> Not long freezes... but try to have some stable releases along gnome <lewing> I'm twice as pissed about the length of this freeze as I suspect you are <lewing> and I sincerely appologize for it * bengt realizes sun is coming up here.... <ajmitch> bengt: I know what that's like :) <ajmitch> lewing: we understand <bmon> bengt: when do you need to leave? I remember your schedule allowed until 21:30. * bengt not working today :) :) <bmon> lewing: its not your fault <bmon> bengt: nice :) <lewing> there was just no way I could open thing up and continue to merge bugfixes into both branches given the schedule I was on <bmon> f-spot is still in early dev stages, its not really appropriate to have long freezes <gabaug> 3 years old in november... <ajmitch> what is the current branch state? 0.1.x is maintenance-only, but will get more fixes & releases? <bmon> gabaug: yeah, but its still got a lot of rough edges :) <wjbaird> bmon: Unfortunately I have to agree... <rubenv> there's plenty of magic that could be implemented before freezing it <bengt> lots of nice patches in bugzilla also.... <lewing> anway, I hate freezes <bmon> do we have to freeze? <bmon> we aren't part of gnome proper anyway <gabaug> heh <lewing> not for a long time as far as I'm concerned <lewing> exactly * bengt seem to recall I only mentioned having some kind of release with Gnome... not that we should freeze... <gabaug> bmon: that's not why we froze as far as I know.. <lewing> and sled11 is a long way away <gabaug> lewing: thank god! <bmon> maybe a couple of conservative releases around that time for the distros to pick up <bengt> bmon: precisely... <rubenv> release every two weeks <lewing> also on the good side, we will have real qa resources <rubenv> like abock used to do with banshee <rubenv> that way it's not bad if things break <lewing> so if people see bugs from eric ward, be happy <gabaug> rubenv: lewing releases every couple of days some times :) <rubenv> :-D <lewing> I like to mix it up <lewing> :) <gabaug> lewing: he is Novell SQ? <gabaug> er <gabaug> QA <lewing> yeah <bmon> lewing: so that means we don't have to test anymore now right? :) <eward> bmon: wrong <gabaug> ha <gabaug> hi eward <lewing> see like magic :) * bengt realizes... 36 users in this channel... :) Wow... <eward> gabaug: hello <gabaug> yeah, almost as many as Banshee :) <lewing> but of so much more fun than banshee ;) <gabaug> haha <bmon> ready for #4 then? <abock> definitely <sde> no <bmon> sde: what would you like discussed? <gabaug> lewing: so how does it work w/ getting updates out to SLED? are you maintaining the separate branch for it's life and we can add new stuff to HEAD/future releases? <sde> about those goals, which of them will be the ones implemented in the next release ? <rubenv> sde: probably the ones we make patches for <bengt> :) <bmon> sde: I'd like to dedicate the second meeting to that <rubenv> and plenty of them if possible <sde> ok, go to #4 <bmon> prioritizing the goals <lewing> gabaug: the details aren't entirely decided yet, but we can definitely start working on head <bmon> #4 Short term goals <bmon> #4.1 Status of Goal 1 <gabaug> lewing: can you try to post on your blog or the list more frequently to let us know what you're up to wrt f-spot? <bmon> bug #342137 XMP imports <bmon> I'm not really involved <bmon> anyone want to talk about how its going? <sde> also known as the most discussed lately <gabaug> w/ no releases, if you don't check CVS commits, you might think the project is dead <lewing> gabaug: I will honestly try <bengt> To me it looks quite ok... but sidecar is not fun. <bmon> bengt: and the process? Everything seems to be going smoothly? <lewing> I've looked over a couple of the patches, not the latest yet, it is really shaping up <bengt> anyway, the patch as it is, handles sidecar and xmp tags nicely. It has been tested by numerous people in various stages <gabaug> lewing: are you considering moving to SVN on an external server as a real possibility? I think it would be good..for my morale if nothing else :) <sde> for me, si quite ok also, I did a lot of review on that <bengt> main problem I think. If you cancel the import and uses links (not copy) F-Spot modifes the photo and adds the tags to it. <lewing> sde: yeah your review has been great <sde> lewing: I also made some with bengt on jabber... <lewing> excellent <bengt> Also, not sure what to do with the sidecar, should we just read it, and drop it. F-Spot is not copying the sidecar with the photo <sde> holiday time at work... <lewing> bengt: we can figure out a solution for that <lewing> for both really <lewing> ewards photos http://www.flickr.com/photos/a4gpa/ <wjbaird> bengt: I'm not sure the photo mod is a showstopper... and I don't think we should be copying the sidecar... not if we're copying the info out of it into the photo... <bengt> As it is, I took a middle way, and manually created a new tag to indicate a sidecar had been used.... easy to remove and all * bengt have really appreciated the various reviews anyway, and testing that this patch has gotten. Been great <lewing> ok, for the XMP source issue what I'm thinking about doing is adding a little more structure to the XMP so you can tell where it came from (XMP sidecar, XMP embedded, IPTC, EXIF etc..) <lewing> then we can resolve the duplicates and do the right thing <lewing> but that isn't super high on my list yet <bengt> not to easy to resolve duplicates... since you do not know which one is master. need a gui for that, and with 300 photos... * rubenv votes for code refactoring first <lewing> rubenv: exactly <wjbaird> lewing: sounds great --- but I don't think it should block this patch... <rubenv> and possibly switching to gmcs + adding generics <lewing> wjbaird: ragreed <lewing> gabaug: I'm definitely considering it <lewing> gabaug: I don't want to move if I can help it though <sde> we will reach the due date for that goal !!!! <bengt> refactoring? <bengt> sde: :) Perfect :) <ajmitch> do we have any fixed dates for features? <sde> ajmitch: no, it was a social experiment on the mailing list <lewing> my boring immediate plans are "make import not suck, add unit tests to images, refactor image loaders, clean up editing" * bengt thinks we can keep on modifying some stuff after it has been committed to head, instead of delaying a working patch... or? <wjbaird> bengt: I completely agree... <lewing> roughly in that order <lewing> I'll look over the XMP import patch again tonight <lewing> and add some comments <bmon> #4.2 What should be the short term goals? IE, what should we be focusing on for the next 2-3 weeks (or month, if we are going to do monthly meetings) <lewing> or commit, depending :) <bmon> XMP import obviously being one of them <bengt> lewing: Thanks :) <bmon> but I think we should highlight various things <wjbaird> I'd love to see the query branch merged to head... Searching is one of my major pain points... <bmon> big, small, whatever that we want to focus on between meetings <lewing> ok one vote for query * sde is ok to test and review the query branch * bengt thinks query is long overdue... <lewing> gabaug: how much does query change the db these days? <sde> I'd like to have lossless croping fixed <wjbaird> I'll gladly do more testing and review of the changes on that branch... <sde> and in the same field, the quality guessing code <gabaug> lewing: the query branch? <lewing> sde: yeah I haven't had a chance to debug the quality bit <lewing> gabaug: yeah <gabaug> I didn't think it changed it at all..let me check <bmon> I'd like to see the shrink images for email <sde> lewing: and the jpegtran with lossless croping is ready also, just need an ui <lewing> sde: I write the code to use it whiule saving then realized it was wrong and backed off * bengt also likes the last imported rolls... <lewing> wow that was garbled <bengt> next goal would be query, plus possible one or two more or? <bmon> OK so XMP and Query branch seemed to get the most support <rubenv> urgh, my next focus is sleep <sde> gabaug: the query patch is still uptodate ?? * bmon is starting to get tired too <massis> sde: don't count on that one ;) <lewing> ok, so everyone review the query stuff <gabaug> sde: not at all <lewing> hard <sde> everyone agree on finishing the goal #1 (XMP) this week and the full focus on the query ? <bengt> that would be a bit diffult review then... <gabaug> I will work on getting it up to date..probably rewriting some of it <-- trichards has quit (Chatzilla 0.9.74 [Firefox 1.5.0.5/2006071912]) <bmon> OK the only thing left are the bits and pieces at the end <bengt> gabaug: How long time do you think you need? <sde> If you're happy with that, I can write the mail for goal #2 and trying to have a max of persons involved, as I did for goal #1 ??? <wjbaird> was there a tag created when the query branch was made? Is there an easy 'cvs diff -r ..." that'll show us the changes on the query branch? Or an existing patch file to review? <massis> sde: it worked well the previous time, let's try it again i'd say <gabaug> wjbaird: yes, it's a branch, F_SPOT_QUERY <bmon> #5.1 Moderator status for IRC channel? Who, how etc? * massis doesn't like moderators <bengt> We have moderators now :) <bengt> They can set title ... :) <rubenv> is there a problem with the IRC channel? <lewing> I can get ops whenever we need it <lewing> so no worries <bmon> rubenv: Just going by what people added to the list <bmon> #5.2 With which interval should we have the meetings? * bengt wanted to set the title in this chatroom, but could not, and no moderators.... <bmon> and I would add, do we want to rotate times to try to capture more people? * bengt this time is ok for me... (knowing it is a pain to get a good time anyway...) <gabaug> I wouldn't mind it being later <lewing> well as most of you know, I'm gone for 3 weeks starting Wednesday, I'll be checking in and trying to keep up with mail, but meetings would be hard <bmon> gabaug: how much later? <rubenv> 22:30 is already later then it should <gabaug> this time is fine <gabaug> (I mean, we don't need to change it) <rubenv> so if it's going to be later, make it 10hours later or so <bmon> ok so keep the time for now? <gabaug> sure <massis> i like the time as it is <bmon> bengt, ajmitch, and those who couldn't make it would be the ones with the most to complain <wjbaird> that's fine... I may or may not be able to attend, depending on work, but I understand the difficulties... <bmon> ok, so we'll keep it how it is for now <ajmitch> lewing: sorry to ask - any 0.1.12 plans, or shall I pull patches from the branch into edgy? <lewing> ajmitch: if you want a 0.1.12 for edgy I'll do it asap <bmon> Every 2 weeks? Every month? <massis> every 2 weeks sounds fine to me <sde> every 2 weeks, so everybody can attend once a month <bengt> 2 weeks <bmon> k * rubenv won't be able to attend every time when university starts again / the girlfriend returns <ajmitch> lewing: it'd be great :) <bmon> Last but not least, someone added the bugzilla stats, any comments? <rubenv> but I do not consider my opinion important enough to let that influence the schedule ;-) <bengt> Since lewing will be gone for 4 weeks... perhaps one more patch to review or is that overkill? <sde> we can have a meeting in 2 weeks <bmon> bengt: I think we should still meet, even if lewing can't make it <lewing> yeah, even if I can't make it you guys can meet <sde> to set the next goal, and discuss a lot of other things <bmon> the more face time we have the better <bengt> bmon: But the prioritization of the goals might not be the best to do if lewing is not here <lewing> if you log it I will definitely read it <bmon> as far as pulling in the same direction goes --> auk (~scott@h-69-3-128-55.lsanca54.dynamic.covad.net) has joined #f-spot <bmon> bengt: yeah, ok we'll delay that for when he returns <lewing> anybody have anything they don't think we covered? <wjbaird> but perhaps discussing the state of the query code? <sde> lewing: yes, 2 <bengt> Discuss the query, and finding a new patch as next goal.... <sde> 1) who'll write a short abstract of this meeting <bmon> wjbaird: yeah, status of old goals, and make new ones as necessary <lewing> not it! :) <bmon> sde: Correct <sde> and 2) who'll be responsible of inviting for the next one <bmon> someone willing to post the log on the Meetings page? <lewing> sde: you seem to be pretty on top of things <sde> if we can't keep trace, it's worthless to do meetings <lewing> sde: can you handle it? <bengt> I can fix the Meetings page <bmon> and maybe put the conclusions from each part so people dont have to read the whole log? <bmon> bengt: thanks <sde> lewing, I don't have access to the wiki, and it'll be better if an english guy do it <bengt> that rules me out... <bengt> :) <bmon> me too :) <lewing> haha <rubenv> sde: awesome excuse * rubenv will have to remember that one <sde> ;) <bmon> I can announce the next meeting to the list <bmon> do we want to do it on Mon again? <lewing> bmon can do the meeting <sde> my vote for bmon as reminder ! <rubenv> anyway, I have to sleep & work in the day <bmon> lewing: bengt volunteered to fix up the wiki <lewing> ok bengt, you do the wiki <rubenv> If I didn't have a daytime job these days, I'd write up the notes * bengt created the Meetings page anyway... <lewing> abock: where should wiki account requests go? <bmon> bengt: might need to make it scale better <sde> rubenv: bengt will write that for the next time ;) <bmon> and have meetings be a list of the meetings <bengt> I will? <bengt> :) <rubenv> but for the next three weeks, I feel a bit too tired when I come home to write summaries <bmon> I'm hoping these things last for awhile <bengt> bmon: I know... on the plan... <bmon> bengt: cool <bengt> bmon: scale? <sde> bmon: are you doing the invitation thing again ? <bmon> Yeah, I'll send out the meeting reminder * rubenv has to get up early tommorrow <bengt> bmon: Wait with invitation until I fixed the MoM page... <rubenv> see you later guys! <massis> thx everyone <sde> see you <lewing> see you rubenv <bmon> bengt: yeah, I was going to wait at least a week <wjbaird> g'night... <lewing> thank you everyone for coming <bmon> ok good meeting all! <ajmitch> thanks lewing <massis> got to get some sleep too <tseng> yay f-spot. <sde> same for me, workday tomorow <-- rubenv has quit (Sleep) * bmon goes to sleep <bmon> Night all <massis> let's have a closing cheer * massis cheers for f-spot <lewing> woo! <massis> bye <bengt> Woo <bengt> Thanks guys... A very good start with this meeting :) Lets keep it up... <sde> I'm also very happy after this meeting, I'll attend the next one ;) <lewing> my thoughts exactly
This page was last modified on 1 August 2006, at 02:27. This page has been accessed 2,002 times.
