diff options
author | Mart Raudsepp <leio@gentoo.org> | 2009-10-16 23:14:33 +0000 |
---|---|---|
committer | Mart Raudsepp <leio@gentoo.org> | 2009-10-16 23:14:33 +0000 |
commit | c6c582bb1913db4004770d2ceb3564a6b8fc816d (patch) | |
tree | d7be728dcd4060b53d02215396ba9e8571767db3 /meeting-logs/20091012.txt | |
parent | Add summary for September\'s meeting. (diff) | |
download | council-c6c582bb1913db4004770d2ceb3564a6b8fc816d.tar.gz council-c6c582bb1913db4004770d2ceb3564a6b8fc816d.tar.bz2 council-c6c582bb1913db4004770d2ceb3564a6b8fc816d.zip |
Add log from October 12th meeting on behalf of tanderson
Diffstat (limited to 'meeting-logs/20091012.txt')
-rw-r--r-- | meeting-logs/20091012.txt | 331 |
1 files changed, 331 insertions, 0 deletions
diff --git a/meeting-logs/20091012.txt b/meeting-logs/20091012.txt new file mode 100644 index 0000000..508048a --- /dev/null +++ b/meeting-logs/20091012.txt @@ -0,0 +1,331 @@ +18:00 <@Betelgeuse> rollcall +18:00 <@dertobi123> <- here +18:00 <@leio> here +18:00 <+tanderson> <--- here +18:00 <@lu_zero> here +18:00 <@Betelgeuse> weaver, solar +18:00 <@Betelgeuse> ulm: +18:00 < weaver> here +18:00 <@ulm> here +18:01 <@Betelgeuse> !seen solar +18:01 < Willikins> Betelgeuse: solar was last seen 44 seconds ago, saying "araujo: not really. But the EAPI mess they created in system is to be frowned upon." +18:01 -!- ssuominen [n=ssuomine@gentoo/developer/ssuominen] has joined #gentoo-council +18:01 <@Betelgeuse> He should be around soon then. +18:02 < likewhoa> Betelgeuse: he's currently active in #gentoo-ten, letting him know now. +18:02 <+tanderson> he's active in #-dev too +18:03 -!- jlec [n=jlec@ip-62-143-31-170.unitymediagroup.de] has joined #gentoo-council +18:03 <@solar> damn I hate UTC. I figured it was not for another hr +18:04 <@lu_zero> ^^; +18:04 <@leio> date -u :) +18:04 < weaver> everyone needs to just switch to utc +18:04 <@Betelgeuse> Ok let's start with item 1. +18:05 <@Betelgeuse> I propose it's the duty of the meeting chair to post any follow up and the secretary should remind him if it's not done when summaring is being approved. +18:05 <@Betelgeuse> Then we don't have to wonder whose job things are. +18:06 <@leio> That sounds reasonable when we are rotating chairs +18:06 <@Betelgeuse> yes +18:07 <@Betelgeuse> When someone accepts chair for a meeting they should be prepared to follow up too in the future. +18:07 <@lu_zero> ok +18:07 <@ulm> fine +18:08 < weaver> sounds good +18:08 <@dertobi123> i disagree - imho those who want things to be discussed should be the ones getting the discussion going on +18:08 * solar seconds dertobi123 +18:08 <@leio> that sounds reasonable too... +18:08 <@dertobi123> i.e. of Calchan wants to discuss some glep39 stuff, i expect him to show up on the meeting and also to get discussion going +18:08 <@dertobi123> s/of/if +18:09 <@leio> then again, we should be proactive as a team and follow up on these things collectively and get them concluded +18:10 < weaver> dertobi123: i think the point was if the council makes an actionable item, someone needs to be responsible for acting on it +18:11 <@Betelgeuse> dertobi123: I have no problem with someone else taking responsilibity but the chair should do it if they don't. +18:11 <@Betelgeuse> Otherwise nothing happens. +18:11 <@ulm> dertobi123: if you take the "PMS/EAPI committee" example of last meeting, who should have acted on it, in your opinion? +18:11 <@dertobi123> weaver: and the ones being responsible are those who want to see things happen - not necessarily the council itself which decided further discussion on that matter is necessary +18:11 <@dertobi123> ulm: hrm, you? +18:12 < weaver> the flexible solution i think is for every item on the agenda that the council decides to act on, to designate the person responsible +18:12 < weaver> don't you guys do that already? :P +18:12 <@lu_zero> better if there is one or more volunteers +18:12 <+tanderson> I think if an actionable item is delayed, put one person in charge of that item +18:12 <+tanderson> It's been done in the past and should work fine +18:12 <@ulm> dertobi123: I disagree, because I had made two propositions +18:13 <@ulm> dertobi123: the ones who voted for "something different" should have followed up with something concrete here +18:13 <@solar> fine. dump it all and go back to eapi=0 +18:13 <@dertobi123> ulm: but then you want a decision, so it's your interest to get the discussion started +18:13 <@dertobi123> solar: agreed. +18:14 <@Betelgeuse> solar: let's stay on the topic at hand +18:14 <@solar> that is my follow up. +18:14 <@lu_zero> ulm so far the "kill pms for good" seemed to be the best solution =) +18:15 <+tanderson> assigning someone for each item(and noting it in the summary) seems fine... +18:15 <@Betelgeuse> So let's say: People volunteer to follow up but if there's none the chair takes care of it and also reminds the volunteer. +18:15 -!- antarus|home [n=antarus@gentoo/developer/antarus] has joined #gentoo-council +18:15 <@lu_zero> seems good +18:16 <@ulm> also ok +18:18 <@dertobi123> if there are no volunteers that specific topic is dead +18:18 <@dertobi123> no one interested in getting things discussed, no important topic +18:19 <@Betelgeuse> dertobi123: And what about purely administrative topics like slacker handling? +18:20 <@dertobi123> Betelgeuse: what needs to be followed or discussed on such topics? +18:21 <@Betelgeuse> dertobi123: Last time people did not vote on my slacker handling during the meeting so follow up was needed, not the best example +18:21 <@Betelgeuse> Any way please vote so we can move to the next topic. +18:21 <@leio> Vote on what? +18:22 <@Betelgeuse> leio: 18:15 <@Betelgeuse> So let's say: People volunteer to follow up but if there's none the chair takes care of it and also reminds the volunteer. +18:22 <@dertobi123> Betelgeuse: at the end of our last meeting it was clear you won't get a slacker mark, nothing to follow up (besides a summary being wrong in that aspect) +18:22 <@solar> I have no input either way. Do whatever you guys feel is right +18:22 <@leio> and additionally note in the summary as agreed +18:23 <@lu_zero> seems balanced +18:23 <@leio> (I suggest action points like, ACTION: description (volunteer), and noting down on top who was the chair) +18:24 <@Betelgeuse> weaver: around? +18:24 < weaver> yes +18:24 <@Betelgeuse> weaver: your opinion? +18:25 <@ulm> leio: that's a detail, do you think we must vote on it? +18:25 <@leio> no +18:25 < weaver> I vote on: <Betelgeuse> So let's say: People volunteer to follow up but if there's none the chair takes care of it and also reminds the volunteer. +18:25 <@leio> I'll just bend tanderson arm to do it like that :) +18:25 <+tanderson> bahaha, usually works too =) +18:26 <@ulm> I vote yes, too +18:26 <@leio> I votes yes, to be clear +18:26 <@dertobi123> no, obviously +18:26 < weaver> ok, let's move on then +18:26 <@Betelgeuse> So yes: Betelgeuse, ulm, leio, weaver neutral: solar no: dertobi123 +18:27 <@Betelgeuse> Topic 2 +18:27 <@Betelgeuse> zmedico: Are you here? +18:27 <@dertobi123> uhrm, what abou lu_zero? +18:27 <@Betelgeuse> damn counted like it was seven but failed +18:28 <@solar> moot. Majority rule? +18:28 <@leio> we have four yes already though, but I didn't see a clear vote from weaver +18:28 < weaver> yes +18:28 < weaver> ^ vote +18:28 <@Betelgeuse> Please be more active than every 5 minutes +18:28 <@lu_zero> I already voted long ago... +18:28 <@lu_zero> anyway yes +18:29 < weaver> ok, zmedico is not here to give us an EAPI 3 report? +18:29 <@Betelgeuse> My guess is that no progress has been done. +18:30 <@Betelgeuse> But it's just a guess. +18:30 <@leio> When I inquired on #gentoo-dev a few days ago, he said that he wants to get a 2.1.7 release out before working on EAPI 3 +18:30 <@Betelgeuse> I don't remember reading any bug spam related to EAPI 3 +18:30 < antarus|home> the 2.1.7 release was this past weekend +18:30 <@dertobi123> well, 2.1.7 is out ;) +18:30 <@leio> I didn't ask if EAPI 3 work will follow immediate after that or not ;p +18:30 <@ulm> If bug 273620 is accurate, then there are still several things missing +18:30 < Willikins> ulm: https://bugs.gentoo.org/273620 "[TRACKER] sys-apps/portage EAPI 3 implementation"; Portage Development, Core; NEW; s.mingramm@gmx.de:dev-portage@g.o +18:31 <@Betelgeuse> ulm: and they are the actually time taking parts +18:31 -!- reavertm_ [n=reavertm@83.27.157.92] has joined #gentoo-council +18:31 <@ulm> Betelgeuse: yes, looks like :( +18:32 -!- Tommy[D] [i=bnc@gentoo/developer/tommy] has joined #gentoo-council +18:32 <@Betelgeuse> Maybe we could offer a bounty for EAPI 3. +18:33 <@Betelgeuse> But that's to discuss with trustees. +18:33 <@lu_zero> I'd let another month pass and then think about it seriously +18:33 <@leio> We could get an update very soon from Zac outside meeting time and post it in an e-mail for everyone to read +18:34 <@dertobi123> we *should* +18:34 <@Betelgeuse> So who volunteers to ask him? +18:35 < antarus|home> why not just send him an email? +18:35 <@Betelgeuse> antarus|home: email can be used to ask? +18:35 <@ulm> well, if noone else volunteers... I can ask him +18:36 <@Betelgeuse> ok +18:36 <@Betelgeuse> I don't see anything further we can do for point 2 so let's move to case 3. +18:37 <@Betelgeuse> Let's discuss 5 minutes and vote. +18:37 <@Betelgeuse> I think if we open the list then we will have others requesting the same. +18:37 <@solar> I'll vote right now that it should be left up to the respective PM's on how they want to deal with it. +18:37 <@Betelgeuse> When energy could be better spend getting EAPI 3 out and work on EAPI 4 to be faster. +18:37 <@leio> We can demand an implementation to exist +18:37 <@solar> as mtimes can not be counted on in the first place (think compressed file systems) +18:38 <@ulm> solar: that's exactly what we shouldn't do because it will result in breakage +18:38 <@lu_zero> I second that +18:38 <@lu_zero> ulm exactly how? +18:38 <@ulm> there's good reason why portage preserves them +18:39 <@ulm> lu_zero: see http://bugs.gentoo.org/263387 as one example, but there are several others +18:39 <@solar> sure there is. But it can't be counted on. But can't be enforced properly ever +18:40 <@leio> I don't see why a PM should mangle what the build systems make install does +18:40 < weaver> I don't have an opinion as I'm not informed of upsides and downsides of mtime modification +18:41 <@ulm> leio: right, it should try to preserve as much as possible when merging D to ROOT +18:42 <@solar> there are valid reasons. But why are we going outside of the ebuild syntax and into behaviors that are best left up to the programmers coding the respective PM's ? +18:42 <@solar> seems an overstep of the council +18:42 <@ulm> solar: because the ebuild cannot do anything if the PM decides to mangle mtimes +18:42 <@leio> We seem to be involved because paludis PM disagrees with portage and pkgcore PM +18:43 < weaver> the PM spec is not just for syntax of the ebuilds +18:43 <@Betelgeuse> Vote: Reopen EAPI 3 for mtimes? +18:43 <@Betelgeuse> I vote no. +18:43 <@solar> then perhaps they can duke it out? +18:43 <@ulm> solar: see <http://bugs.gentoo.org/83877#c36> for horrible "solutions" on the ebuild level ;) +18:43 <@leio> and because it is asserted it's an EAPI feature +18:44 -!- reavertm [n=reavertm@gentoo/contributor/reavertm] has quit [Read error: 110 (Connection timed out)] +18:44 <@leio> I vote yes +18:44 <@ulm> I vote yes, obviously +18:44 < weaver> hmm +18:44 < weaver> I understand that calchan would vote yes +18:44 <@ulm> weaver: calchan requested the feature for portage, btw ;) +18:44 < weaver> so, I vote yes +18:44 <@dertobi123> i vote yes, too +18:45 <@lu_zero> yes also for me +18:46 <@ulm> solar? +18:46 <@Betelgeuse> yes: leio ulm weaver dertobi123 lu_zero no: Betelgeuse ?: solar +18:47 <@Betelgeuse> Then we need the wording. +18:47 <@solar> ulm: I'm not sure right now. Majority rule. +18:48 <@Betelgeuse> ulm: So do you have a short pros and cons to give about the options? +18:49 <@ulm> Betelgeuse: Obviously A is the simplest and gives all control to the ebuild +18:50 <@ulm> B will optionally allow the PM to update "old" time stamps +18:50 < weaver> i'm sorry, where are the A/B/... described? +18:50 <@ulm> and C will make that updating mandatory, but please note that C is not "zero cost" for Portage +18:51 <@ulm> weaver: http://bugs.gentoo.org/264130#c26 +18:51 < weaver> ok thanks +18:51 < weaver> what's the definition of an "old" mtime? +18:52 <@leio> what do you mean under optionally in option B? PM can freely choose to do that or not, or the ebuild instructs it with some variable? +18:52 <@ulm> weaver: time before the build process of the package started +18:52 <@ulm> leio: PM can freely choose +18:53 -!- lxnay|two [n=lxnay@host-78-14-152-87.cust-adsl.tiscali.it] has joined #gentoo-council +18:53 <@ulm> leio: i.e. most likely Portage and Pkgcore would just preserve mtimes +18:53 <@ulm> Paludis would update "old" ones +18:53 < weaver> would that break stuff? +18:53 -!- few [n=few@port-ip-213-211-233-28.reverse.mdcc-fun.de] has joined #gentoo-council +18:54 <@ulm> weaver: hopefully not, but i've checked for lisp, python, and ghdl only +18:54 <@Betelgeuse> zmedico prefers A +18:54 <@ulm> right +18:54 < weaver> then let's go with A +18:55 < antarus|home> ulm: the intention is to prevent rebuilds with build systems based on mtime? +18:55 <@ulm> antarus|home: the intent is more directed at runtime +18:55 <@Betelgeuse> Please vote on a A|B|C and let's see if we get a majority (if not ready please note): +18:55 <@ulm> antarus|home: e.g., .py vs .pyc or .lisp vs .fasl +18:55 <@leio> A +18:55 -!- Zorry [n=zorry@fu/coder/zorry] has joined #gentoo-council +18:56 <@lu_zero> A +18:56 < weaver> A +18:56 <@dertobi123> A +18:56 <@ulm> B +18:57 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council +18:57 <@ulm> (but I can live with A too) +18:57 <@Betelgeuse> I am neutral between A and B. +18:57 <@dertobi123> (i can live with b, too - but prefer A) +18:58 <@leio> I understand B is the same as A in case of portage and pkgcore +18:58 <@ulm> leio: right +18:58 <@Betelgeuse> leio: yes +18:59 <@Betelgeuse> A: leio, lu_zero, weaver, dertobi123 B: ulm A|B: Betelgeuse ?: solar +18:59 < weaver> is there a specific option that ciaran/paludis is objecting against? +18:59 <@ulm> weaver: he (they?) prefer C +19:00 <@ulm> and paludis complies to none of the options presently +19:00 < weaver> ok +19:00 <@ulm> s/to/with/ +19:00 < weaver> I understand we have a majority on A, so let's move on then? +19:01 <@Betelgeuse> The hour allotted is up. Anyone need to go or can we have some time for open floor? +19:01 * leio has time +19:02 * weaver has time +19:02 * lu_zero has time +19:02 * ulm has time +19:02 <@Betelgeuse> Tommy[D] wanted us to talk about the multilib stuff. +19:02 <@Betelgeuse> I havent' had much time to look into it. +19:02 <@Betelgeuse> In the thread zmedico was saying it needs EAPI changes. +19:02 * dertobi123 has some minutes +19:02 <@Betelgeuse> So most likely EAPI 4 and as such would take time. +19:02 <@leio> me neither, I hope to dig into that, have had various thoughts about that on my own, would be nice to see what they have done there +19:03 -!- dabbott|work [n=david@gentoo/developer/comprookie2000] has quit ["Heading home"] +19:03 <@lu_zero> I used myself the multilib overlay and is quite interesting (and useful) +19:03 < Tommy[D]> Betelgeuse: did you also read my reply to him? +19:04 <@Betelgeuse> Tommy[D]: it wasn't immediately evident from that +19:05 < Tommy[D]> Betelgeuse: so optional, additional features would require EAPI, but not the basic functions +19:05 <@ulm> Tommy[D]: would that require to change ebuilds lateron? +19:05 <@ulm> i.e. when the "optional, additional features" have been implemented +19:06 -!- antarus|home [n=antarus@gentoo/developer/antarus] has left #gentoo-council [] +19:06 < Tommy[D]> ulm: i use multilib-portage with main tree, if the ebuilds and build system respects the env, no changes are needed +19:07 < weaver> i have no opinion on this +19:07 < Tommy[D]> the only place, where you either need to depend a specific portage version (with multilib support) or an EAPI, which requires PM with multilib support, is the *DEPEND on libs/packages with additional 32bit libs +19:07 < weaver> and i'm not aware if Calchan does +19:08 <@Betelgeuse> For me I would like zmedico to first fogus on EAPI 3 before this stuff +19:08 <@Betelgeuse> Of course he does what he wants with his time. +19:08 < weaver> yes I believe eapi 3 needs to be pushed out ASAP +19:09 < weaver> it's been delayed and it has a bunch of useful features +19:09 < Tommy[D]> i did implent the current version of multilib-portage, based on previous work done by other people and i would continue working on it, so the main work would be a code review by zmedico +19:09 <@Betelgeuse> Tommy[D]: Sure but it's a major feature to Portage +19:10 <@Betelgeuse> Tommy[D]: Testing etc would slow down EAPI 3 to stable +19:10 <@Betelgeuse> Tommy[D]: If it stays in trunk, then fine. +19:10 < Tommy[D]> the main issue is that zmedico once got a council warning because of some changed or additional feature, thats why i request the discussion and later decision here +19:11 < Tommy[D]> Betelgeuse: i would not mind, if it stays in 2.2_rc* for now, while EAPI-3 could go into 2.1.* +19:11 <@Betelgeuse> Tommy[D]: Yes he did change EAPI 0 behavior without our blessing. +19:11 <@Betelgeuse> Tommy[D]: Before I can vote on this it needs to be clear to me whether this does that. +19:12 <@Betelgeuse> Tommy[D]: I think PMS currently says phases can run only once. +19:12 <@Betelgeuse> I don't know what that is based upon. +19:12 < Tommy[D]> it violates current PMS in at least 1 point: execute every phase at max once +19:12 < weaver> this sounds like something we should intentionally delay until after EAPI 3 is out +19:12 <@lu_zero> I think that could be relaxed +19:13 <@lu_zero> still it could be done in parallel and make push it as the main part of eapi 4 +19:13 < Tommy[D]> my implementation would require something like "preserve none-default env vars in filesystem between phase switches" +19:13 <@Betelgeuse> We can do an EAPI 4 that is fast for zmedico to implement. +19:13 <@Betelgeuse> for needs in this +19:14 <@Betelgeuse> and other fast stuff +19:14 < weaver> as long as the people involved are sure it won't delay EAPI 3 +19:14 * leio has no opinion about this until some research +19:15 <@solar> Till our devs learn how to use the existing EAPI's properly I have no desire to introduce another eapi +19:15 <@Betelgeuse> solar: devs beside direct Portage deps should always use the latest +19:15 < weaver> solar: how are they used improperly? +19:15 < Tommy[D]> multilib-portage itself can be added without any additional EAPI +19:15 <@solar> weaver: system. There is no clean upgrade path. +19:15 < NeddySeagoon> Betelgeuse solar is that a reason to depreciate and remove old EAPIs ? +19:16 <@Betelgeuse> NeddySeagoon: the stay in vdb +19:16 <@leio> portage oralready requires EAPI-2 :9 +19:16 <@Betelgeuse> NeddySeagoon: We can make repoman require latest EAPI for new ebuilds +19:16 <@Betelgeuse> NeddySeagoon: But only after discussion +19:16 <@solar> that is sick +19:17 < weaver> sick as in good or bad +19:17 <@solar> bad and in evil and a dumb idea +19:17 <@Betelgeuse> solar: there's fatal and warning repoman levels, this would fall in the latter +19:17 < weaver> i don't see why not, as long as revisions are allowed in older eapis +19:17 < Tommy[D]> Can multilib-portage inclusion be added to agenda of next meeting? And i would like to see comments, requests and discussion about it until then +19:17 < NeddySeagoon> Betelgeuse, that would be good. PMs have to be capable of removing old stuff ... but we should encourage the use of the current/latest EAPI +19:17 <@solar> Betelgeuse: there is no clean upgrade path in that +19:18 <@Betelgeuse> solar: You only need an upgrade path for direct Portage deps +19:18 <@solar> I'm in favor of reverting lots of system packages back to EAPI=0 +19:18 <@Betelgeuse> solar: So you can get to new Portage +19:18 < weaver> solar could you elaborate on what the problem is, I'm not familiar with it +19:18 <@solar> weaver: take a box from 2008 and try to upgrade it. You can't +19:18 < weaver> what happens? +19:18 <@Betelgeuse> python +19:18 < weaver> oh +19:19 < Tommy[D]> weaver: old portage, which doesnt know EAPI-2 cannot upgrade because newer portage requires newer python, but all pyhton packages have EAPI-2 +19:19 <@Betelgeuse> python people decided for all to break upgrade path without warning. +19:19 <@solar> gotta give it to bonsaikitten for one time. He had the right idea on how to allow a mix. You always keep one ebuild at EAPI=0 +19:19 < weaver> oh. can't we roll a transitional verison of portage that would deal with this issue specifically? +19:19 <@Betelgeuse> I am not opposed to forcing them to add EAPI 0 upgrade path back. +19:20 <@Betelgeuse> weaver: We don't need to. +19:20 <@solar> this means you need a python-2.6 and eselect* at 0 +19:20 <@Betelgeuse> Just need python people to do their job. +19:20 < weaver> i guess... +19:20 <@Betelgeuse> They can't make decisions like that for everyone. +19:21 <@Betelgeuse> solar: Could you take responsibility on working with them trying to get EAPI 0 back there? +19:21 <@ulm> solar: hm? eselect is still at EAPI 0 +19:21 <@Betelgeuse> If it doesn't work out, we can put it on the agenda nexttime. +19:21 <@ulm> solar: with good reason +19:22 <@Betelgeuse> Who wants to chair next time? +19:22 <@solar> Betelgeuse: I'm not sure I'm nice enough to work with them (I have much anger about this topic). +19:22 <@leio> and take care of the agenda +19:23 <@ulm> solar: sounds like you're the right person for it then :p +19:23 <@solar> leio: I would second this for the next round then. 07:19PM <Betelgeuse> I am not opposed to forcing them to add EAPI 0 upgrade path back. +19:24 <@solar> ulm: I do much better work when I'm happy. Gentoo 10 was a hit +19:24 < weaver> should I volunteer Calchan to do this? :] +19:24 <@Betelgeuse> weaver: probably not +19:25 * ulm can take it +19:25 <@leio> lets say I can look with solar into the upgrade path business +19:26 <@Betelgeuse> ulm: chair or upgrade path? +19:26 <@ulm> Betelgeuse: chair +19:26 <@Betelgeuse> ok ulm chair and leio EAPI 0 +19:26 <@solar> leio: that would work. TeamWork++ +19:26 <@Betelgeuse> I call this meeting done. Thanks everyone. +19:26 < weaver> thank you +19:26 <@solar> thanks Betelgeuse +19:26 <@ulm> question of understanding: followups are for the _previous_ chair, right? +19:27 <@Betelgeuse> ulm: I would follow up from today. +19:27 <@ulm> Betelgeuse: k +19:27 <@Betelgeuse> I will make sure leio does. +19:27 <@Betelgeuse> And you ask zmedico. +19:28 <@lu_zero> please let's try to use more the council alias +19:28 <@Betelgeuse> private is bad +19:29 <@lu_zero> we have also the council ml +19:29 <@Betelgeuse> better +19:29 <@lu_zero> still both of them are quicker and easier to follow than -dev +19:29 <@Betelgeuse> following -dev comes with the job +19:30 -!- reavertm_ is now known as reavertm +19:30 <@solar> the alias is proper for some things. +19:30 <@solar> Not going to send a personal reminder to the entire list just to make sure ppl don't get the slacker mark. +19:30 <@Betelgeuse> sure alias is fine for that +19:30 <@Betelgeuse> but not discussing technical stuff etc +19:31 <@solar> nod +19:31 <@Betelgeuse> I am off to write a short essay that's due today. +19:31 <@solar> well unless you don't want input from some ppl. +19:31 <@solar> anyway cya. +19:31 * dertobi123 nods +19:32 * lu_zero runs away as well +19:32 <@lu_zero> nite ^^ +19:33 < weaver> have fun people |