MOTU_2006-02-15
[21:18:18] <raphink> ok well let's begin
[21:18:22] <sistpoty> welcome ladies and gentlemen to just another motu-meeting... :)
[21:18:25] <raphink> I'm first on the agenda
[21:18:38] <dholbach> hey sistpoty
[21:18:41] <raphink> I've been spamming the list and irc with this
[21:18:44] <sistpoty> hi dholbach
[21:18:50] <raphink> but just for the people who have not heard about it yet
[21:19:06] Joindre LaserJock has joined this channel (n=LaserJoc@ubuntu/member/laserjock).
[21:19:13] <raphink> I wanted to introduce revu-tools, which is a set of tools based on siretart's revu-build
[21:19:24] <raphink> to be initialy included in REVU, but that can be used on other machines
[21:20:08] <raphink> to say it short, this is a collection of scripts that automatize review tasks, such as comparing the upstream tarball with the orig one, run build tests, etc.
[21:20:12] <raphink> and generates a full report
[21:20:49] <raphink> the idea now is maybe to use mdt in it to make is more complete, checking for example for the presence of the package in debian or in older versions of ubuntu
[21:21:02] <raphink> any mdt dev is present?
[21:21:45] <sistpoty> lucas: around?
[21:21:48] * raphink feels everybody is sleeping already
[21:21:49] <raphink> ...
[21:22:07] <LaserJock> looks like lucas is 3 hrs idle. don't know if he's around
[21:22:09] <Riddell> what is mdt?
[21:22:17] <LaserJock> multi-distro-tools
[21:22:19] <raphink> Riddell: mdt is Multi Distro TOols
[21:22:34] <raphink> it's a set of tools created by some MOTUs (not sure about who exactly)
[21:22:35] * Riddell none the wizer
[21:22:37] <stratus> raphink: I would like to suggest revu-tools package inclusion in the distro.
[21:22:39] <raphink> that is useful for merges mostly
[21:22:45] <LaserJock> https://wiki.ubuntu.com/MultiDistroTools
[21:22:48] <sistpoty> stratus ++
[21:22:51] <raphink> stratus: it's in NEW already, has been for a week
[21:23:02] <stratus> raphink: oh, great!
[21:23:03] CTCP Requête de version reçue de Gyuszk vers le canal #ubuntu.
[21:23:04] <raphink> stratus: i've pinged elmo several times about it, but I have no news yet
[21:23:11] <sistpoty> raphink: what do you think you'll gain from merging with mdt?
[21:23:12] <Riddell> raphink: what's it written in?
[21:23:26] <Riddell> NEW is generally slow this week, soyuz stuff
[21:23:28] <raphink> sistpoty: being able to check for the presence of the package in Debian/Ubuntu already
[21:23:32] <raphink> sistpoty: mostly
[21:23:36] <stratus> raphink: do you plan to move from svn to bzr ?
[21:23:39] <LaserJock> I use mdt for MOTU Science lists like http://tiber.tauware.de/~laserjock/all_list.html
[21:23:52] <raphink> stratus: well so far it's in the REVU svn
[21:24:24] <stratus> raphink: i know, i know, i asked about the possibility of a move in the near future.
[21:24:40] <Riddell> raphink: what's it written in?
[21:24:47] <jpatrick> Riddell: bash
[21:24:50] <raphink> stratus: well this is a small project, aimed to fewpeople
[21:24:52] <raphink> thanks jpatrick :)
[21:24:54] <Riddell> oh, lovely :)
[21:25:13] <LaserJock> mdt is also bash with a little ruby mixed in
[21:25:15] <raphink> although I hope to target DDs too
[21:25:21] <Riddell> raphink: does it check for all copyright contributors being in debian/copyright?
[21:25:27] <raphink> not yet Riddell
[21:25:30] <raphink> that could be a nice thing
[21:25:36] <LaserJock> how would it do that
[21:25:42] <Riddell> LaserJock: grep :)
[21:25:43] <raphink> Riddell: I'm wondering if that feature wouldn't be better in lintian or linda though
[21:25:45] <stratus> raphink: np
[21:25:56] <Riddell> raphink: probably too unreliable
[21:25:58] <LaserJock> Riddell: grep what? COPYING?
[21:26:00] <sistpoty> Riddell: you are almost as extreme with ideas what a script can do as ajmitch ;)
[21:26:05] <raphink> LaserJock: grep the headers
[21:26:08] <stratus> btw, what's up with the REVU wiki articles? Just search for REVU in the wiki.
[21:26:15] <jpatrick> LaserJock: grep -i copyright
[21:26:38] <stratus> two articles (almost same content) in different urls and a broken redirect
[21:26:46] <LaserJock> jpatrick: compare to what?
[21:27:15] <raphink> stratus: no there is only one REVU page on the wiki
[21:27:26] <raphink> stratus: and I take note of the broken redirect
[21:27:34] <jpatrick> LaserJock: then compares debian/copyright and the src files?
[21:27:52] <LaserJock> jpatrick: ok, I can kinda see that
[21:27:53] <raphink> stratus: and correct it immediatly ;)
[21:28:01] <stratus> raphink: heh :-)
[21:28:23] <sistpoty> raphink: iirc revu2 also has some stuff to find out, if a sourcepackage is in debian or ubuntu... so you could also take a look at this
[21:28:50] <raphink> sistpoty: indeed I'd like to try to embed revu-tools in revu2 more
[21:28:59] <sistpoty> raphink: so imo it depends, whether you want revu-report integrated into revu2 or standalone...
[21:29:01] <raphink> sistpoty: including being able to run them from the web interface for reviewers
[21:29:15] <raphink> sistpoty: I'd like two branches
[21:29:16] <LaserJock> sistpoty: btw, is there an ETA on REVU2?
[21:29:17] Quitter lucas has left this server (Read error: 110 (Connection timed out)).
[21:29:30] <raphink> sistpoty: because I don't think DDs will use REVU2 very soon
[21:29:40] <raphink> sistpoty: but I think we'd benefit from DDs using revu-tools
[21:29:53] <sistpoty> LaserJock: should have been done for a long time... no honestly, we don't have an ETA right now :(
[21:30:03] <LaserJock> ok
[21:30:20] <sistpoty> raphink: ok
[21:30:39] <raphink> any more questions? or shall we move on?
[21:30:44] <sistpoty> raphink: I basically think, you should discuss inclusion to mdt with lucas, since he wrote it
[21:30:53] <sivang> what was a motu meeting?
[21:31:03] <raphink> sivang: the meeting is not done ;)
[21:31:15] <raphink> s/done/over/
[21:31:31] <sivang> ah
[21:31:40] <raphink> ok well if there's no questions anymore, sistpoty you go :)
[21:31:49] <sistpoty> ok, let's move on
[21:31:56] <sistpoty> first item: allegro4.1 to 4.2 transition
[21:32:01] <sivang> whose hosting the meeting?
[21:32:09] <raphink> sivang: hosting?
[21:32:17] <sistpoty> sivang: the motu's do
[21:32:18] <sivang> err, directing :)
[21:32:32] <raphink> sivang: seems I'm doing it so far
[21:32:32] <raphink> ;)
[21:32:34] <dholbach> sivang: sistpoty and the meeting is running atm
[21:32:40] <sivang> in previous ones ogra_ibook or dholbach did that :)
[21:32:46] * sivang shuts up
[21:32:51] <sistpoty> dholbach is uber_host ;)
[21:32:55] <sistpoty> back to topic
[21:32:57] * dholbach hands sistpoty the Mic back.
[21:33:01] <raphink> :)
[21:33:15] <sistpoty> has everybody read my mail to -motu about allegro4.1 -> 4.2?
[21:33:21] <sistpoty> (or anybody)?
[21:33:31] * raphink hides
[21:33:33] <stratus> nobody cared, but considering we did, move on :-)
[21:33:33] * dholbach has another quick look. :)
[21:34:02] * LaserJock saw it
[21:34:11] <raphink> sistpoty: what is allegro ? *blush*
[21:34:18] <sistpoty> just for reference: debian unstable ships with allegro4.2 (and 4.1)... most of the games have deps on 4.2 now, since there are bugs filed against packages which depend on 4.1
[21:34:55] Joindre lemsto has joined this channel (n=salim@ANantes-154-1-59-188.w81-53.abo.wanadoo.fr).
[21:34:58] <raphink> sistpoty: oh so this is not like a very big transition
[21:35:07] <sistpoty> raphink: a library mostly for games
[21:35:10] <stratus> yes, and for those who care it's sound related, so go figure..
[21:35:13] <sistpoty> raphink: no, just some rdeps
[21:35:30] <raphink> yep
[21:35:42] <dholbach> do the games/allegro have bugs on them already?
[21:35:49] <dholbach> does it seem sane, like stable?
[21:35:56] <raphink> (btw: OT, the automake1.6 is not yet fully achieved)
[21:36:06] Quitter ogra_ibook has left this server (Connection timed out).
[21:36:12] <raphink> (automake1.6 transition)
[21:36:16] <sistpoty> dholbach: haven't seen any till now, and since it's there for quite some time, I consider it stable
[21:36:28] <stratus> there are just 7 games in Debian that depends on allegro 4.2
[21:36:49] <raphink> sistpoty: what does it bring?
[21:36:49] <stratus> checking for bugs...
[21:36:54] <sistpoty> one good thing about the transition is, that we could undo it, since allegro4.2 and allegro4.1 would be present (different sourcepackages)
[21:37:05] Joindre ogra_ibook has joined this channel (n=ogra@ubuntu/member/ogra).
[21:37:10] <sistpoty> raphink: being closer to debian
[21:37:19] <raphink> k
[21:37:23] <dholbach> and something supported
[21:37:33] <dholbach> "supported", since closer to upstream
[21:37:40] <sistpoty> thus, if bugs occur, we would be quite sure that they are in debian as well and could join the efforts on fixing
[21:38:01] <raphink> sistpoty: so using allegro4.1 | allegro4.2 in Depends should be quite fine I guess
[21:38:31] <raphink> sistpoty: ++
[21:38:48] <sistpoty> raphink: erm... no... we should use liballegro4.2-dev as build-depends
[21:38:58] <raphink> ah
[21:39:19] <sistpoty> (so I'm not quite sure if liballegro-dev | liballegro4.2-dev will work as well, since liballegro4.2-dev replaces/conflicts liballegro-dev... anyone a clue?)
[21:39:46] Quitter mruiz has left this server ("Adiós / Goodbye").
[21:39:46] <stratus> FYI, there are no bugs involving allegro 4.2 in Debian packages that depends on it.
[21:39:54] <sistpoty> thx stratus
[21:40:06] <stratus> there are just bugs asking for allegro 4.2 transition, made in 7 of them already
[21:40:30] <raphink> ok
[21:40:40] <sistpoty> (well and I'm quite sure I could work a little bit in debian-games, since at least one game ftbfs currently, which i believe is in debian-games)
[21:40:40] <raphink> seems good :)
[21:40:56] <sistpoty> dholbach: what's your opinion about the transition?
[21:41:20] <dholbach> If we have both library source packages in, we should run into no risk, if we can get rid of one of them, even better.
[21:41:34] <raphink> +1
[21:41:48] <sistpoty> we will have both sourcepackages :)... so any objections from anyone?
[21:42:30] <sistpoty> ok, then I call it decided, we'll go for the transition :)
[21:42:36] <sistpoty> shall we move on?
[21:42:36] <raphink> ok
[21:42:43] <raphink> sistpoty: do you want to create a transition page on the wiki?
[21:43:09] <raphink> https://wiki.ubuntu.com/MOTU/Transitions
[21:43:37] <stratus> raphink: which content exactly? information about ongoing transitions?
[21:43:53] <raphink> yep, as done with other transitions there
[21:44:00] <sistpoty> raphink: actually I want to testbuild the whole transition before doing it... if I'm finished with these steps I already have all changed packages at hand...
[21:44:13] <sistpoty> raphink: so if noone objects, I would care for this transition
[21:44:14] <raphink> sistpoty: you can use mdt for that :)
[21:44:19] <raphink> sistpoty: sure :)
[21:44:22] <stratus> raphink: i see
[21:44:34] <raphink> ok then
[21:44:40] <sistpoty> raphink: mdt for what? I use apt-get in my unstable chroot :)
[21:44:54] <raphink> sistpoty: mdt for reverse dep and build all
[21:44:55] <sistpoty> next item?
[21:45:01] <LaserJock> sistpoty: for listing dependent packages, etc.
[21:45:22] * sistpoty will try it
[21:45:31] <raphink> ok let's move on :)
[21:45:46] <sistpoty> ok, next item is coordination of current work...
[21:45:56] <raphink> huhu
[21:46:15] <sistpoty> actually, I must admit, that I'm beginning to loose overview of who works on what package and what syncs are already requested
[21:46:27] <lfittl> wiki page seems like a good idea to solve that
[21:46:47] <sistpoty> and I believe that we might start to do duplicate work, if we don't organize a little bit :)
[21:46:51] <raphink> stratus: you've the one who made a wiki page for the UVF status right?
[21:47:03] <stratus> raphink: yes
[21:47:03] <LaserJock> sistpoty, more than SyncRequests and UVFStatus provide?
[21:47:13] <sistpoty> LaserJock: is syncrequests current?
[21:47:17] <LaserJock> yes
[21:47:30] * sistpoty looks
[21:47:40] Partage heno has left this channel.
[21:47:50] <LaserJock> dholbach had me make last week I think
[21:48:04] <dholbach> had you make? :)
[21:48:13] <sistpoty> LaserJock: I don't think it is current... (at least I need to insert my syncs there *g*)
[21:48:53] <stratus> oh, wait
[21:48:55] <sistpoty> LaserJock: imo we need also a table who is doing work on a package right now
[21:48:59] <LaserJock> sistpoty: well, people have to use it ;-)
[21:49:11] <LaserJock> sistpoty: what kind of work?
[21:49:16] <sistpoty> LaserJock: and to know of it's existance :)
[21:49:22] <LaserJock> sure
[21:49:23] <stratus> the UVFStatus and SyncRequests lack a better explanation about why there aren't just one page
[21:49:40] <sistpoty> LaserJock: for example work on a package with unmet dependencies
[21:49:42] <stratus> SyncRequests does a better job informing that 'this is not used for merges...'
[21:49:44] <LaserJock> stratus SyncRequests isn't for UVF exceptions
[21:50:10] <LaserJock> sistpoty: what we could really use is a list like we used for merging on tiber
[21:50:19] <stratus> LaserJock: yes, i know. I'm just thinking about the 'foo' wiki reader.
[21:50:26] <LaserJock> wiki pages aren't great for that kind of work flow tracking
[21:50:40] <raphink> LaserJock: yes
[21:50:41] <sistpoty> LaserJock: grml... (means work for me *g*)
[21:50:55] <raphink> sistpoty: means more work in the beginning, less in the future
[21:51:05] <LaserJock> stratus: I see, it was more for people who already knew what they were doing, but yes it isn't very discriptive
[21:51:09] <stratus> LaserJock: entire work flow tracking no, but just for current status it's, IMHO.
[21:51:19] <LaserJock> sistpoty: maybe you need to delegate ;-)
[21:51:32] <LaserJock> stratus: current status of what?
[21:51:35] <raphink> sistpoty: delegate your work ... to elmo for example :)
[21:51:41] <sistpoty> LaserJock: well if s.o. is willing to create s.th. I wouldn't mind at all :)
[21:51:51] <LaserJock> raphink: lol, nooooo
[21:51:55] <stratus> LaserJock: you said that wiki pages aren't great for "that kind of work flow tracking".
[21:51:59] <raphink> LaserJock: ;)
[21:52:09] <sistpoty> LaserJock, raphink: on the left of the merge-web-tool is the link to it's bzr-repo ;)
[21:52:45] <sistpoty> does anyone know how usable the search-function of malone is up to now?
[21:52:59] <LaserJock> for what?
[21:52:59] <raphink> sistpoty: depends
[21:53:01] <dholbach> sistpoty: what do you want to know?
[21:53:10] <raphink> sistpoty: it often crashes and is not very reliable imo
[21:53:12] <sistpoty> maybe we could also (ab)use malone-bugs and the search function to create a list who is doing work on a package
[21:53:43] <raphink> sistpoty: a list on _a_ package??
[21:54:29] <sistpoty> raphink: idea is: if you work on a package, you file a (specific) bug to malone...
[21:54:31] <LaserJock> basically, I think a question is should we be opening bugs for everything we do?
[21:54:43] <sistpoty> raphink: then you could search for all these bugs to know which packages are worked on
[21:54:57] <raphink> I get the idea sistpoty, just as for merges
[21:55:17] <dholbach> Hm, I don't see the problem to fix. Can somebody help me?
[21:55:19] <sivang> sistpoty: using the autmatic merge bug filer right?
[21:55:21] <sistpoty> LaserJock: if it provides us with s.th. to handle the workflow in a good matter, I don't see a problem with it
[21:55:40] <sistpoty> sivang: eventually
[21:55:43] <raphink> sistpoty: since merges are not done normally during UVF, why not use motu-mergers for that?
[21:56:28] <sistpoty> raphink: hm... that is quite confusing but would give us what we want :)
[21:56:36] <dholbach> Which workflow are we trying to fix for which reason?
[21:56:47] <LaserJock> maybe we need at motu-workflow LP team that would go to a motu-workflow list? kinda like a svn commit ML
[21:56:50] <sistpoty> dholbach: that two persons doing work on the same package
[21:57:03] <raphink> dholbach: we are trying to find a way to work properly on UVF exceptions I think, not duplicating the work
[21:57:05] <dholbach> like in "bug fixing"?
[21:57:07] <raphink> dholbach: from what I understood
[21:57:17] <sistpoty> dholbach: or in fixing unmet deps, yse
[21:57:30] <dholbach> assigning the bug to people should be way to go
[21:57:31] <sistpoty> raphink: no, I'm not talking about UVF exceptions here
[21:57:34] <LaserJock> well, there is lots of work, bug fixing, unmet deps, FTBFS, merges, syncs
[21:57:36] <raphink> sistpoty: oh ok
[21:57:43] <dholbach> and subscribe MOTU so they still get the mails on universe-bugs, no?
[21:57:53] <raphink> sure dholbach
[21:58:05] <LaserJock> dholbach: do we want to create that much noise on universe-bugs?
[21:58:14] <sistpoty> dholbach: actually I'd like to see a list of which packages are currently worked on
[21:58:38] <dholbach> LaserJock: If you're going to fix a bug that's in Malone, you SHOULD assign it to you - that's not more noise than there is anyway atm.
[21:58:43] <sistpoty> (imo that would be very easy to look up, before I start working on a package)
[21:59:06] <dholbach> Untriaged bugs and Unassigned bugs is a good way atm.
[21:59:11] <LaserJock> dholbach: i'm talking about opening a bug for every upload, syn request, etc.
[21:59:14] <dholbach> We should step back from assigning bugs to MOTU
[21:59:29] <sistpoty> dholbach++
[21:59:50] <dholbach> subscribing motu or getting motu on the default subscribers list is a good idea
[21:59:55] * raphink assigns bugs to himself or to people he knows to be specialized in something
[22:00:12] <dholbach> assigning = commiting to work on it
[22:00:19] <dholbach> is that a definition we can live with?
[22:00:20] Partage lemsto has left this channel ("Quitte").
[22:00:30] <sistpoty> dholbach: sounds good to me
[22:00:34] <LaserJock> raphink: really, I was under the impressions that we didn't want to assign anything to a particular person only MOTU
[22:00:39] * raphink I can't live commited to doing work :p
[22:01:21] <dholbach> LaserJock: But we do uploads for a reason - it's better to look at reasons/use-cases (like bug, update, ...) than at uploads
[22:01:38] <sistpoty> well, I think I could rape^Wreprogram the current merge list quite fast, to be able to handle unmet deps... do you think this might be worth a try?
[22:01:48] <LaserJock> ok, but I think the questions remains, should we be using Malone for tracking MOTU work?
[22:02:23] <dholbach> LaserJock: for which use-cases?
[22:02:26] <sistpoty> LaserJock: *if* it provides us with what we need, why not use it?
[22:03:01] <dholbach> aren't unmetdeps mostly something for saying "I poke <package xy>" in #ubuntu-motu?
[22:03:04] <LaserJock> I'm talking about tracking all MOTU (basically everything we do and upload for) whether it is really a "bug" or not
[22:03:22] <LaserJock> all MOTU activity, that is
[22:03:43] <sistpoty> dholbach: I'm sometimes working on a package when I'm not online...
[22:03:43] <LaserJock> if I want a package synced, should I open a bug
[22:03:44] <dholbach> LaserJock: please try to break it up in use-cases - it's easier to discuss separate issues
[22:03:52] <dholbach> sistpoty: right
[22:04:04] <sistpoty> dholbach: and you don't know, if somebody started working on it, but didn't finish yet (if it takes longer)
[22:04:08] <LaserJock> if I have a fix for an unmet dep should I open a bug?
[22:04:17] <dholbach> the problem with locking on stuff is that some stuff keeps being locked
[22:04:34] <sistpoty> dholbach: yes, good point...
[22:05:04] <dholbach> but for important thigns (which *are* problems) we should probably have a bug
[22:05:05] <sistpoty> maybe bug filing might help us with this, since we know the date s.o. started working on it?
[22:05:10] Quitter ogra_ibook has left this server (Success).
[22:05:22] <stratus> well guys, i need to go now
[22:05:28] <sistpoty> cya stratus
[22:05:40] <raphink> ciao stratus
[22:05:43] Quitter stratus has left this server (".").
[22:06:07] <LaserJock> I think moving work workflow off the wiki is a good thing but I'm unclear as to what I (and other MOTU Wannabes) are supposed to do.
[22:06:34] <LaserJock> in the case of a bug fix it is clear
[22:06:58] <sistpoty> ok, got a proposal: I empty the merge-list and for every package with unmet deps, a bug "package is uninstallable in dapper" should be filed, if s.o. starts working on it
[22:07:01] <sistpoty> what do you think?
[22:07:21] <sistpoty> then we have both a list for fast lookup and bugs in malone...
[22:08:01] <sistpoty> in the bugs, we could state, if the package is to be synced (and also list it in the wiki) or close it, once a new version is uploaded
[22:08:24] <LaserJock> and for FTBFS? "package does not build from source"?
[22:08:46] <psusi> fails to build from source
[22:09:01] <sistpoty> a bug with "package FTBFS" or something... then it could also be handled by the list
[22:09:19] Joindre poningru_ has joined this channel (n=poningru@n128-227-34-184.xlate.ufl.edu).
[22:09:26] <dholbach> guys, I'll be out for a walk now, sorry.
[22:09:27] <dholbach> bbl
[22:09:32] <sistpoty> cya dholbach
[22:09:34] <raphink> later dholbach
[22:10:12] <sistpoty> let's try to summarize the options we have... and vote for the best one
[22:10:21] <sistpoty> (a) no coordination necessary
[22:10:24] <sistpoty> (b) wiki-page
[22:10:29] <LaserJock> cya dholbach
[22:10:32] <sistpoty> (c) bugs in malone
[22:10:49] <dholbach> a 'motu' poll!
[22:10:55] <sistpoty> (d) bugs in malone with merge-list abused as list who works on a package
[22:11:04] <sistpoty> any other option?
[22:11:15] <raphink> in the past I have gone for b+d, since it's still quite hard to search on malone
[22:11:20] <raphink> sorry
[22:11:22] <raphink> b+c
[22:11:23] <raphink> hehe
[22:11:36] <LaserJock> sistpoty: could we rename the list to workflow or something?
[22:11:47] <raphink> I made myself a wiki page to coordinate the list of things to be done, and filed bugs for each
[22:11:51] <sistpoty> LaserJock: sure, whatever you want ;)
[22:11:55] <raphink> reporting the bug numbers to the wiki page
[22:12:22] <sistpoty> (e) wiki-page and bugs as raphink just stated
[22:12:32] <sistpoty> anything else?
[22:12:34] <LaserJock> I think (d) is great if we can get away with it ;-)
[22:13:06] <sistpoty> ok, if we have nothing more, then let's start voting :)
[22:13:30] <raphink> ok
[22:13:38] * raphink votes for e obviously :)
[22:14:04] * sistpoty is unsure
[22:14:10] <LaserJock> raphink: really?
[22:14:39] <raphink> hmm sure
[22:14:46] * sistpoty votes for (e)
[22:14:50] <raphink> and so far I'm the only one to vote anyway
[22:14:52] <raphink> ah no :)
[22:14:55] <raphink> we're two :)
[22:15:13] <LaserJock> I think wiki pages are very difficult for the number of items we are talking about
[22:15:16] <sistpoty> (imo (e) is not as error-prone as (d)) *g*
[22:15:25] * lfittl also votes for e
[22:15:40] <LaserJock> woah, ok maybe I'm not understanding e then :(
[22:16:15] <raphink> LaserJock: example of what I mean by (e) : https://wiki.ubuntu.com/MOTU/Transitions/Automake
[22:16:41] <LaserJock> we would have 1 wiki page that has a list of every package being touched and the corresponding bug?
[22:17:09] <raphink> yes
[22:17:11] <raphink> that's the idea
[22:17:18] <LaserJock> I mean for personal use it seems great but for the MOTU as a whole it seems a bit clunky
[22:18:06] <raphink> depends on the amount of things that are gathered on this page I guess
[22:18:23] <LaserJock> I'm talking package that is being touched
[22:19:13] <raphink> you mean any touched package
[22:19:37] <sistpoty> well, we had used the wiki for breezy... imo it's not perfect but at least does the job
[22:19:45] Quitter pef has left this server (Read error: 110 (Connection timed out)).
[22:19:49] <raphink> yes
[22:20:00] <raphink> I think some people even automatize wiki pages
[22:20:13] <raphink> they make scripts that generate lists and put them on the wiki iirc
[22:20:36] <raphink> not sure about that though :S
[22:20:44] <raphink> huhu
[22:20:46] <sistpoty> oh, nice... only thing I had seen was a generated (but static) list in the wiki
[22:21:05] <sistpoty> ok, any other votes?
[22:21:30] <sistpoty> 3...
[22:21:31] <sistpoty> 2...
[22:21:32] <raphink> lol
[22:21:33] <sistpoty> 1...
[22:21:36] <sistpoty> poll closed :)
[22:21:42] <sistpoty> the winner is (e)...
[22:21:45] <raphink> it seems so
[22:21:50] <raphink> barely, but still ;)
[22:21:51] <raphink> lol
[22:21:59] <sistpoty> next question is who will create the initial wiki-page?
[22:22:30] <raphink> hmmpf
[22:22:41] <sistpoty> if nobody goes for it, I will take care
[22:22:45] <raphink> among the people who are still alive on this channel ....
[22:23:09] * Nafallo is not :-P
[22:23:32] <sistpoty> ok, then I'll do it ;)
[22:23:42] <raphink> thanks sistpoty
[22:23:53] <raphink> ok I think if we're done with this, the meeting is over
[22:23:58] <sistpoty> any other topics that aren't on the agenda?
[22:23:59] <raphink> unless someone has something else to say
[22:24:15] <sistpoty> raphink: we still need date/time for next meeting
[22:24:19] * raphink shakes the dead body around to try and get an answer
[22:24:28] <raphink> s/body/bodies/
[22:24:45] <sistpoty> seems like everybody has fallen asleep *g*
[22:25:12] <raphink> yes :(
[22:25:24] <sistpoty> ok, when do we want to meet again?
[22:25:26] <raphink> sistpoty: ok when do you and me meet around for a meeting?
[22:25:48] <Nafallo> lol
[22:25:53] <sistpoty> hehe... /me checks fridge for upcoming events
[22:26:15] * raphink check fridge for food to cook
[22:26:52] <raphink> sistpoty: I think this was the last MOTU meeting before FF
[22:27:04] <sistpoty> yes
[22:27:36] <raphink> so ...
[22:27:41] <sistpoty> what about 28. Feb?
[22:27:48] <raphink> or the first week of march
[22:28:05] <raphink> I'm fine for the 28th Feb
[22:28:16] <sistpoty> first week of march is fine for me as well
[22:28:54] <raphink> sistpoty: shall we meet in a bar or so ? this is more convenient than IRC if we're 2 or 3 people ;)
[22:29:05] <raphink> sistpoty: any date is fine by me, so just choose :)
[22:29:06] <sistpoty> hehe
[22:29:38] <sistpoty> we could choose 28. Feb... and have the time be discussed on motu-ml, what do you think?
[22:29:45] <raphink> yep that's good
[22:29:52] <raphink> let's go for the 28th of feb for now
[22:29:57] <sistpoty> ok
[22:30:08] <sistpoty> --> meeting over :)MeetingLogs/MOTU_2006-02-15 (last edited 2008-08-06 16:35:27 by localhost)