| *** blue-frog has quit IRC | 00:14 | |
| *** didymo has joined #schooltool | 02:03 | |
| *** jinty has joined #schooltool | 02:27 | |
| *** jinty has quit IRC | 03:27 | |
| *** povbot has joined #schooltool | 06:06 | |
| *** th1a has quit IRC | 06:43 | |
| *** ignas has joined #schooltool | 10:15 | |
| *** ignas has quit IRC | 10:52 | |
| *** PupenoK has quit IRC | 10:57 | |
| *** mgedmin has joined #schooltool | 11:38 | |
| *** jinty has joined #schooltool | 11:38 | |
| *** mgedmin is now known as mgedmin_had_no_b | 12:37 | |
| *** mgedmin_had_no_b is now known as mgedmin | 12:37 | |
| *** faassen has joined #schooltool | 12:51 | |
| *** thisfred has joined #schooltool | 13:35 | |
| *** ignas has joined #schooltool | 13:44 | |
| *** srichter has quit IRC | 13:46 | |
| *** didymo has quit IRC | 14:54 | |
| povbot | /svn/commits: * faassen committed revision 6128: | 15:07 |
|---|---|---|
| povbot | /svn/commits: Move table macros into a more reusable location. | 15:07 |
| povbot | /svn/commits: * faassen committed revision 6129: | 15:31 |
| povbot | /svn/commits: Move more generic table code into skin. | 15:31 |
| *** srichter has joined #schooltool | 15:45 | |
| povbot | /svn/commits: * gintas committed revision 6130: | 15:48 |
| povbot | /svn/commits: Added some preliminary documentation for the security policy. | 15:48 |
| *** alga has joined #SchoolTool | 15:52 | |
| *** th1a has joined #schooltool | 16:04 | |
| * th1a returns after the Memorial Day weekend. | 16:13 | |
| ignas | :) | 16:13 |
| ignas | th1a: could you try out the svn+ssh://source.schooltool.org/svn/schooltool/branches/new-security-policy branch | 16:14 |
| ignas | it is not completely finishred yet, though you could see the access control view | 16:14 |
| ignas | and look whether such model suits you | 16:15 |
| th1a | ignas: That's pretty much what I was imagining. | 16:28 |
| ignas | any notes, ideas for improvement ? | 16:28 |
| th1a | Uh... "Access Control" should be bold? | 16:29 |
| ignas | :) | 16:29 |
| ignas | the list is generated automatically, thus anyone adding a plug-in for schooltool will be able to add his own settings | 16:29 |
| th1a | Ah. That's good. | 16:29 |
| ignas | just 1 zcml directive and you get your configurable setting in the "access control" view | 16:30 |
| th1a | ignas: Isn't Zope 3 wonderful? | 16:31 |
| ignas | nah, not really | 16:31 |
| ignas | :D | 16:31 |
| th1a | OK, let's get started. | 16:31 |
| th1a | I'm sorry I didn't send out my usual little reminder/agenda. | 16:31 |
| * faassen waits for the gavel. | 16:32 | |
| faassen | and the shuffling of papers. | 16:32 |
| th1a | We went for a hike yesterday and I fell asleep yesterday. | 16:32 |
| * th1a shuffles some papers. | 16:32 | |
| faassen | you went for a hike yesterday and you fell asleep during the hike? | 16:32 |
| th1a | Fell asleep when I got back, I mean, earlier than usual. | 16:32 |
| *** PupenoK has joined #schooltool | 16:32 | |
| PupenoK | Hello. | 16:32 |
| th1a | Hi PupenoK. | 16:32 |
| alga | Hi all. | 16:33 |
| faassen | hey. :) | 16:33 |
| th1a | Anyhow, I also couldn't think of anything pressing we needed to discuss, aside from everyone's progress. | 16:33 |
| th1a | And if you're running into any particular issues we need to discuss. | 16:34 |
| th1a | So... shall we start with faassen? | 16:34 |
| faassen | uh, okay. | 16:35 |
| faassen | we did a lot of things. | 16:35 |
| th1a | :-) | 16:35 |
| faassen | Pupeno fixed the form layout and the display template layouts for formlib use. | 16:35 |
| faassen | I did quite a bit of work on utilities. | 16:36 |
| faassen | so it's easier to register local utilities. | 16:36 |
| faassen | the person object is now created using such a utility, so it's fairly easy to make different person objects be created (though I want to discuss issues with that later, see also my email to the list yesterday0 | 16:36 |
| faassen | anyway, that person factory caused some code to get simpler again and move away from demographics. | 16:37 |
| faassen | I almost wiped out the use of the custom datewidget. | 16:37 |
| faassen | and using zc.datetimewidget now (which is now an egg dependency along with zc.i18n) | 16:37 |
| faassen | there are some particularly funky cases in the recurrence form that I left in for now. | 16:38 |
| faassen | though if we can clean those up that means we can dump our whole datewidget implementation with a centrally maintained one. | 16:38 |
| faassen | the table of persons sorts now with the recent modified date on top by default, thanks to Pupeno. | 16:38 |
| faassen | we extended the search stuff. | 16:38 |
| faassen | so you can now search for people by parent and student id. | 16:39 |
| faassen | the sample data story was extended in demograhpics so parents are created. | 16:39 |
| faassen | it means that people can have two female parents, and such, according to the name, but who cares. :) | 16:39 |
| faassen | we use formlib now for the addform, which was an incredible amount of work. | 16:40 |
| faassen | as we needed to fix tests all over the place. | 16:40 |
| faassen | so we use the password widget we introduced, and we're in a better position to extend it. | 16:40 |
| faassen | (though that also ties in to the later discussion I mentioned just now) | 16:40 |
| th1a | In the email? | 16:40 |
| faassen | we're currently working on making the drop-down lists select from the list of teachers for mentor and such. | 16:40 |
| faassen | yeah, in that mail. | 16:40 |
| th1a | OK. | 16:41 |
| faassen | and some zc.table code has moved into schooltool.skin as it was reusable. | 16:41 |
| faassen | that's basically it. | 16:41 |
| faassen | as to status for a release. | 16:41 |
| faassen | there are a number of open issues. | 16:41 |
| faassen | the selecting of groups and teachers for the schooldata form. we'll get that done today I expect. | 16:42 |
| faassen | sorting by last name requires the last name to be required in the add form, which ties into the discussion again. | 16:42 |
| faassen | and we want to finally make the table view the default view for pesrons, and do away with the old index.html | 16:42 |
| faassen | this still requires some tweaks of various templates, to preserve all original functionality. | 16:43 |
| faassen | in particular, the default person display form needs to be integrated with the demographics. | 16:43 |
| th1a | Right. | 16:44 |
| faassen | also, I don't know whether this release needs evolution scripts, but if so, we will need to quite a bit of work on that, as we introduced catalog indexes which need to be installed and filled and such fun. | 16:44 |
| faassen | the main blocking thing is the whole add form discussion. | 16:44 |
| th1a | OK. We'll come back to that, then. | 16:44 |
| faassen | want to do the PoV report first and then go into a discussiona bout that? | 16:44 |
| faassen | okay. | 16:44 |
| faassen | oh, and in general: | 16:44 |
| faassen | it would be nice if someone looked at the UI and gave UI feedback. | 16:44 |
| th1a | OK. I will. | 16:45 |
| faassen | we keep running into stuff where we suspect things could be better, but we can not determine priority, and some of the work that could be better would be quite a bit of work. | 16:45 |
| th1a | Right. | 16:45 |
| faassen | and we probably miss stuff that could be better entirely that *could* be improved. :) | 16:45 |
| faassen | as another topic I'd like to discuss today is the release planning. | 16:45 |
| faassen | as the deadline for that is today. | 16:46 |
| faassen | and how we proceed from there as Infrae. | 16:46 |
| faassen | okay, done for now. :) | 16:46 |
| th1a | Thanks, faassen. | 16:46 |
| th1a | POV? | 16:46 |
| th1a | ignas? | 16:47 |
| ignas | yes | 16:47 |
| ignas | typing | 16:47 |
| ignas | Well, we added customisation interface for access control settings, fixed some functional tests, implemented a few cells in the permission table | 16:48 |
| ignas | added a self relationship and a membership relationship | 16:48 |
| ignas | at the moment i am converting the open office table into a plain text one | 16:48 |
| ignas | so it would be easier to track changes that we are making | 16:49 |
| ignas | as some parts like "changing password" will eventually need their own permissions | 16:49 |
| ignas | we can't really cover everything with edit / view permissions | 16:50 |
| ignas | gintas started working on the documentation for the security policy | 16:50 |
| th1a | I suspected that, but it made it a lot easier to get 80% there. | 16:50 |
| ignas | well, we will still need some testing from your side, just to be sure that users can see everything they need | 16:51 |
| ignas | and can't do anything they are not supposed to | 16:51 |
| ignas | as the table does not cover 100.0% | 16:51 |
| ignas | of the functionality | 16:51 |
| th1a | OK. | 16:52 |
| ignas | though extending the policy with new rules is a breeze | 16:52 |
| ignas | hope it's not because me and gintas have designed it from the bottom and know everything ;) | 16:52 |
| th1a | I hope so too. | 16:53 |
| ignas | that's it i think | 16:54 |
| th1a | Sounds good though. | 16:54 |
| faassen | cool! | 16:54 |
| faassen | I'm glad the new security policy story seems to be working out. :) | 16:54 |
| *** HL1 has joined #schooltool | 16:55 | |
| th1a | Hi HL1 | 16:55 |
| th1a | I'd like to introduce Helen King (HL1) | 16:55 |
| ignas | faassen: hope you will be as happy then you will see the code and ways of extending it :) | 16:55 |
| HL1 | Hi | 16:56 |
| th1a | She's the International Relations person at The Shuttleworth Foundation. | 16:56 |
| faassen | hi HL1. :) | 16:56 |
| faassen | what does that mean? | 16:56 |
| HL1 | Not sure why it is HL1 - supposed to be HLK | 16:56 |
| th1a | It means she's the person at TSF I talk to :-) | 16:56 |
| HL1 | but I can deal | 16:56 |
| HL1 | oh - I thought you meant the name! | 16:56 |
| th1a | And she flys around the world talking to bigwigs. | 16:56 |
| th1a | Sorry to interrupt the flow of things. | 16:57 |
| th1a | HL1 and I have some things to discuss after the meeting... in the meantime. | 16:57 |
| th1a | Should we return to faassen's email? Does everyone have that? | 16:58 |
| th1a | Does anyone not? | 16:58 |
| faassen | HL1: I didn't mean the name, but that's interesting too. :) | 16:58 |
| faassen | HL1: perhaps there's already a HLK here, I think often the software then replaces the last letter with 1 or something like that. | 16:59 |
| faassen | HL1: (somewhere on irc) | 16:59 |
| th1a | faassen: So the sticking point is that the way things are set up now we can't require last name? | 16:59 |
| faassen | that's the specific problem. the general problem is what belongs in person and what belongs in demographics. | 16:59 |
| th1a | I'm not in favor of a solution that would take a lot of time at this point. | 17:00 |
| faassen | when I start moving the table.html to become the index.html of person that will become even more important. | 17:00 |
| faassen | as table.html is defined in demographics. index.html is defined in person. | 17:00 |
| faassen | and I try to keep the two apart so that person can theoretically be reused. | 17:01 |
| faassen | but that's not really testable right now. | 17:01 |
| ignas | the hacky and fast way is to make last name an attribute of person.Person, and fix all the tests | 17:01 |
| faassen | ignas: well, fixing all the tests takes hours of work. | 17:01 |
| faassen | ignas: I just did it with the password change yesterday. | 17:01 |
| faassen | ignas: I guess it will be a trifle faster this time round, but it was a pain. | 17:02 |
| faassen | ignas: but yeah, that'd be the hacky way. | 17:02 |
| th1a | The reason there are so many tests to fix is that so many tests of other objects create persons? | 17:02 |
| ignas | the nice and slow way would be to (at last, we needed that a lot) to make functional tests test layers | 17:02 |
| ignas | like all ftests that involve timetables are in the timetable module | 17:02 |
| ignas | and any other module that does not depend on timetables | 17:02 |
| ignas | just can't see them in the user interface | 17:02 |
| ignas | though it would be a considerable amount of work | 17:03 |
| ignas | starting from person/person duality would be an idea ... | 17:03 |
| faassen | th1a: yeah, that's the reason, there's lots and lots of places, so each time that form is changed, all the tests break. | 17:03 |
| faassen | also it's just ..these conflicting pressures. | 17:03 |
| th1a | Gah. :-( | 17:03 |
| faassen | on the one hand you want stuff to be done quickly. | 17:03 |
| faassen | on the other hand we know we need to be able to quickly modify stuff n the coming months, when people start testing this. | 17:04 |
| faassen | and in addition, in september or so we know there will need to be alternative demographics screens. | 17:04 |
| faassen | and then there's also the "schoolbell needs to work!" issue. | 17:04 |
| ignas | faassen: another way is (not a nice but usable) to add functions that use REST interface into some testing module | 17:04 |
| ignas | and not use the real UI for creating persons | 17:04 |
| faassen | where I can't modify person so much that schoolbell will be hopelessly intertwined iwth demographics. | 17:04 |
| th1a | Don't worry about SchoolBell. | 17:04 |
| ignas | though that defeats the purpose of the functional testing in a way | 17:04 |
| faassen | well, the intertwined issue is relevant. | 17:04 |
| faassen | well, what I would prefer is a functional test layer taht includes the demographics layer. | 17:05 |
| faassen | and one without the demographics UI layer. | 17:05 |
| faassen | and then you can test both. | 17:05 |
| faassen | I'm talking about two concepts of layer here. | 17:05 |
| ignas | schooltool test runner doesn't have layers iirc :/ | 17:05 |
| faassen | a functional test layer and a skin layer. | 17:05 |
| faassen | ugh. | 17:05 |
| faassen | yeah, the special way schooltool does setup bit me. | 17:05 |
| faassen | and the special test runner did too (it makes moving eggs from Zope3/src into src impossible I think) | 17:06 |
| faassen | as the special test runner lacks a feature to run the egg tests. | 17:06 |
| faassen | when eggs are installed in development mode. | 17:06 |
| faassen | anyway, yesterday I was swearing at the heavy testing a lot. it really makes it harder to make what one would expect trivial changes. | 17:06 |
| faassen | expect to be. | 17:06 |
| faassen | of course it catches errors, but it's sapping agility too. | 17:07 |
| th1a | faassen: I wonder about that too. | 17:07 |
| faassen | anyway, of cousre we can hack in lastname. | 17:07 |
| faassen | and update all the tests. | 17:07 |
| faassen | someone in the future adding something else to this form | 17:07 |
| faassen | (and this is very likely to come up in the next months!) | 17:08 |
| faassen | will have to do the same. | 17:08 |
| faassen | at least if it's required. | 17:08 |
| ignas | faassen: not really | 17:08 |
| faassen | ignas: not really what? | 17:08 |
| th1a | Well, I think next time we fix it for real. | 17:08 |
| ignas | if i understand correctly, now we are very time constrained | 17:08 |
| ignas | and it is the ONLY reason why one would hack | 17:08 |
| ignas | something like this without a long term solution | 17:08 |
| faassen | well, I'll have to go through all the test a second time. | 17:08 |
| faassen | and if next week we think, oops, we want 'foo' as well being required in the add form. | 17:09 |
| faassen | then we'll go again. | 17:09 |
| ignas | and I hope that such things like sacrificing long term design for short term speed will not become a common thing | 17:09 |
| th1a | They might for the next four months or so. | 17:09 |
| th1a | If we're ever going to release a beta. | 17:09 |
| th1a | Then we'll have some time to refactor. | 17:10 |
| PupenoK | The main problem was sorting on last names, right ? | 17:10 |
| faassen | anyway, I make short term choices all the time, this one is just one where I see the right fix as not being that far awy from the hacky fix, if this happens a few more times. | 17:10 |
| faassen | PupenoK: yeah, if we want to do that, last name has to be required, and thus in the add form. | 17:10 |
| th1a | PupenoK: True. | 17:10 |
| faassen | we could drop the sorting on last name option, but I agree that it is silly to sort on first + last name. | 17:10 |
| th1a | We could also hack in a hacky heuristic to guess the last name. | 17:10 |
| ignas | faassen: an idea | 17:10 |
| PupenoK | what if we just generate the last name from the full name for the time being, that might be a good-enough-by-now solution. | 17:11 |
| ignas | faassen: listening ? | 17:11 |
| faassen | that won't even work probably for the testdata we have now, th1a..anyway, it's silly as we have a last name field and it *should* be easy to change that form. | 17:11 |
| faassen | ignas: yes. | 17:11 |
| ignas | faassen: what i see as the bigest problem with current tests is not that they are too brittle (they got a lot better with testbrowser) | 17:11 |
| faassen | PupenoK: lastnames and first names with multiple components will make this hard to do reliably, and it feels entirely wrong to me as we *have* a last name field. | 17:11 |
| ignas | faassen: but the amount of duplication | 17:11 |
| th1a | faassen, Oh yeah. We know the last name. | 17:11 |
| th1a | Well, if they don't have a last name, they're first in the sort? | 17:12 |
| th1a | How about that? | 17:12 |
| ignas | faassen: and the short term solution that i would bet on is - moving creation of a person into a function in some testing module (we did that with mongo timetable setup) and only fixing that 1 place instead of doing it in 20 functional tests | 17:12 |
| faassen | ignas: the amount of duplication is definitely the cause of lots of pain here. it's used in test setup code everywhere. | 17:12 |
| th1a | We need some DRY in ftests. | 17:13 |
| ignas | th1a: yes, exactly | 17:13 |
| faassen | th1a: I guess that's possible. we could expose lastname explicitly. | 17:13 |
| faassen | ignas: there's a function like that already, i'ts just not used in most places. | 17:13 |
| faassen | ignas: but yeah, that's what I thought of yesterday. | 17:14 |
| faassen | ignas: that would be an intermediate fix. | 17:14 |
| th1a | In reality, the particular problem that is hanging us up is not a big problem. | 17:14 |
| th1a | I mean, sorting by last names. | 17:14 |
| th1a | We're not testing in any country that doesn't use last names. | 17:14 |
| ignas | faassen: i think not just intermediate, if you have the functionality of adding a person in a single place, you can change the form all you want pretty painlesly | 17:14 |
| faassen | no, this is technically simple. though of course now the add form is in person and we want to add the last name in demographics and there's no way to override but a brittle ZCML override. | 17:15 |
| faassen | I really don't think this is the right solution on the long term, as the add form is *not* changing in schooltool core. | 17:15 |
| ignas | faassen: i even wanted to inherit from a base testbrowser class, so i could do manager = SchoolToolBrowser(); manager.createPerson(name="John") | 17:15 |
| faassen | it's going to change in extensions. and demograhpics pretends to be an extension. | 17:15 |
| faassen | whether that's a fiction or not I've gotten conflicting input about from the start. | 17:15 |
| faassen | ignas: you'll still have to make up a fake required last name as a default paramater, but yeah, that can work. | 17:16 |
| faassen | again, let's not focus on last name as the only story here. it's just the 50th time I run into the whole demographics, what is it? question. | 17:16 |
| ignas | faassen: we have a random name generator in sample data ;) | 17:16 |
| faassen | I'll run into it again and again, as I replace the table for instance. | 17:16 |
| ignas | faassen: moving functionality from schooltool test runner into zope3 testrunner and using zope3 testrunner was the plan, though no one actually implemented it yet :/ | 17:16 |
| faassen | right now, there are probably lots of tests for persons/index.html | 17:17 |
| faassen | once I use table.html there, which in demographics add columns, which could change, we have a related 'how do we test this scenaro' | 17:17 |
| faassen | I can of course punt on this for last name and I understand the consensus to be so, and we can make a createPerson function (or extend the existing one and put it into a reusable place) | 17:17 |
| ignas | faassen: not that there are many tests, there is a lot of duplication though, all the test follow the same pattern ... | 17:17 |
| faassen | but i's not the solution to all our problems. | 17:17 |
| faassen | anyway, the underlying problem is that we want to test person, and test demographics, independenty. | 17:18 |
| faassen | or not. | 17:18 |
| ignas | indeed, but devising a system that would allow to test schooltool in separate layers like (schoolbell layer, schooltool layer, demographics layer etc.) is not something one can do in 10 minutes :/ | 17:18 |
| faassen | if not, I can move demographics into person and just test that. | 17:18 |
| faassen | yes, of cousre not. | 17:19 |
| faassen | I'm just bringing it up as I bump into it over and over again. | 17:19 |
| PupenoK | Another idea for the tests. | 17:19 |
| ignas | and if i understand you don't really have the time required to implement it now ... | 17:19 |
| faassen | anyway, conclusions: we'll start using a reusable createPerson function for browser tests. | 17:19 |
| faassen | we'l put in a fake last name in there. | 17:19 |
| ignas | faassen: +1 | 17:19 |
| faassen | and modify everything. | 17:20 |
| faassen | I don't know what to do for the add form. | 17:20 |
| faassen | I mean, the browser test will implicity become aware of demographics. | 17:20 |
| faassen | but the core shouldn't know about demographics. or should it? | 17:20 |
| faassen | etc. | 17:20 |
| ignas | faassen: if you will encounter some other easily refactorable places and will be in a mood of fixing them ... ;) | 17:20 |
| faassen | do we override the addform in person in demographics? if so, how do we even *test* the add form in person? | 17:20 |
| ignas | faassen: the core is aware of timetables and pretty much everything | 17:20 |
| PupenoK | Why not having each module prefixing its name to the all the forms and pages and doing tests to its own functionality. And then ensuring the right extension is picked up by giving some generic names to those same pages. | 17:20 |
| ignas | so at the moment the core knowing about demographics is not making it that much worse | 17:21 |
| faassen | PupenoK: I think you're talking about test layers hacked up by prefix? | 17:21 |
| th1a | I agree with ignas. | 17:21 |
| faassen | ignas: yeah, I know. | 17:21 |
| faassen | but I am responding to rather strongly worded complaints. | 17:21 |
| faassen | remember I started modifying person? | 17:21 |
| faassen | and I also kept hearing, well, we'll need to customize this. | 17:21 |
| ignas | PupenoK: they are using a common ZCML for functional tests at the moment thus it is not really easy to unhook everything and make prefixes work | 17:21 |
| faassen | we're really going back and forth on this. | 17:22 |
| PupenoK | so demographicsAddForm.html is the demographics add form and personAddForm.htm is the person add form, and addForm.html is one of them (configurable somewhere) but it is never ever used for testing. | 17:22 |
| PupenoK | faassen: yes. | 17:22 |
| PupenoK | ignas: ok. | 17:22 |
| faassen | PupenoK: you can solve that prettily using skins. | 17:22 |
| th1a | faassen: It is the great dilemma of SchoolTool. | 17:22 |
| faassen | PupenoK: you simply have tw addForm.html, one for both skin. | 17:22 |
| faassen | PupenoK: and then you test each skin. | 17:22 |
| faassen | PupenoK: skins can also extend each other, etc. | 17:23 |
| faassen | th1a: yes. | 17:23 |
| ignas | it is the dilemma of - whether we want a cleanly extensible core, or a working beta :/ | 17:23 |
| faassen | well, I vote working beta too. | 17:23 |
| faassen | but in that case I'll give up demographics independence from person for now. | 17:23 |
| faassen | I suspect I have to anyway. | 17:23 |
| faassen | to replace bits of the UI. | 17:23 |
| th1a | OK. You have my blessing. | 17:23 |
| th1a | I'll protect you from mgedmin and srichter. | 17:23 |
| faassen | I still believe I have pieces in place to refactor this relatively easily to reusability. | 17:24 |
| faassen | in a few months. | 17:24 |
| * mgedmin puts down his crossbow quietly | 17:24 | |
| faassen | okay, good, thanks. | 17:24 |
| faassen | I mean, I am frustrated by it, not so much by mgedmin or srichter | 17:24 |
| faassen | it's that I want this to be customizable, so I go back and forth in my mind too. | 17:24 |
| faassen | the benefit is that I have lots of ideas and I think we can make this work while still not making it insanely hard to program. | 17:24 |
| th1a | That is good ;-) | 17:25 |
| faassen | but I'll worry about that later. | 17:25 |
| faassen | mgedmin: why a crossbow by the way? how that is going to help against my unobtanium shielding? | 17:25 |
| th1a | It seems like a classic Lithuanian weapon. | 17:26 |
| mgedmin | I have irresistable force bolts ;) | 17:26 |
| mgedmin | your unmovable unobtainium shielding has no chance | 17:26 |
| faassen | oh, good. | 17:26 |
| th1a | Lithuania was at its military peak in the 14th century, so that's about right for crossbows. | 17:26 |
| mgedmin | well, at least the tickets will sell good | 17:26 |
| faassen | crossbows make for better movies? | 17:27 |
| faassen | mgedmin, vampire hunter? | 17:27 |
| th1a | Or are crossbows later? | 17:27 |
| faassen | I think crossbows were around then. | 17:27 |
| faassen | wikipedia has them entering european warfare around 800. | 17:28 |
| faassen | AD | 17:28 |
| ignas | th1a: crossbows were too hight tech for lithuania, mostly there were clubs, and perfect knowledge of the terrain (99% woods and unpassable swamps) ;) | 17:28 |
| faassen | of course the chinese had been using them 50 million years before already, using paper money arrows. | 17:28 |
| th1a | And the best horses in the world. | 17:28 |
| alga | why crossbow? | 17:29 |
| faassen | anyway, Pope Urban II banned the use of the crossbow against christians in 1097. | 17:29 |
| alga | elves use normal bows | 17:29 |
| alga | http://www.akl.lt/alga/photos/Draugai/gd2004/show/elfas.jpg | 17:29 |
| faassen | I'm sure lots of people obeyed that order. | 17:29 |
| faassen | well, mgedmin is a high tech elf. | 17:30 |
| th1a | Scary. | 17:30 |
| th1a | And with that, our hour is up. | 17:30 |
| * th1a bangs the virtual gravel. | 17:31 | |
| th1a | Have a good week, folks! | 17:31 |
| faassen | okay. the demographics package willl weaves its evil tendrils all into schooltool. | 17:31 |
| faassen | sucking its life energy from it. | 17:31 |
| ignas | faassen: http://www.eccentricgenius.ca/Products4.htm ;) | 17:31 |
| th1a | Yes. | 17:31 |
| faassen | th1a: thanks | 17:32 |
| faassen | th1a: anyway, release? | 17:32 |
| faassen | th1a: I thought we were going to wrap up stuff for an alpha today? | 17:32 |
| faassen | th1a: or something like taht? | 17:32 |
| th1a | faassen: When you're ready. | 17:32 |
| faassen | okay, I'll try to be ready by tomorrow or thursday. | 17:32 |
| th1a | This is an arbitrary deadline, as opposed to the real deadlines we'll start having soon. | 17:33 |
| faassen | I'll send a mail to the list then. | 17:33 |
| th1a | OK. Thanks. | 17:33 |
| faassen | well, I have to do some other stuff too here, planningwise. | 17:33 |
| th1a | faassen: Yes. | 17:33 |
| faassen | oh, by the way, next week monday is another holiday here, ascension day. | 17:33 |
| faassen | luckily pupeno can proceed. | 17:33 |
| faassen | oh, we should give him svn access. | 17:33 |
| faassen | who should we contact for the keys to the svn? | 17:33 |
| th1a | Essentially, you'll be blocked by srichter for the month of June. | 17:33 |
| faassen | th1a: okay. | 17:34 |
| th1a | Oh... mgedmin or alga, I believe. | 17:34 |
| faassen | okay. | 17:34 |
| faassen | I'm okay with reviewing his patches for now. | 17:34 |
| th1a | faassen: Plan on some SchoolTool time in July, please. | 17:34 |
| faassen | anyway, we'll contact them later this week. | 17:34 |
| faassen | and get it arranged. | 17:34 |
| th1a | And it will be much less deep voodoo. | 17:34 |
| th1a | Hopefully ;-) | 17:34 |
| faassen | th1a: okay, i'll try, though my vacatino is also planned into july, and europython into early july. | 17:35 |
| mgedmin | faassen: just email the ssh public key and a preferred username | 17:35 |
| faassen | mgedmin: okay, I'll have him do that. | 17:35 |
| faassen | PupenoK: you hear that? mail that to mgedmin. :) | 17:35 |
| PupenoK | ok. | 17:35 |
| PupenoK | mgedmin: email address ? | 17:35 |
| mgedmin | marius@pov.lt | 17:35 |
| th1a | HL1: Still here? | 17:36 |
| HL1 | hi | 17:37 |
| th1a | HL1: Hi again. | 17:37 |
| HL1 | howdy | 17:38 |
| th1a | Do you have any more sense of what information they actually want from this request? | 17:38 |
| HL1 | nope | 17:39 |
| HL1 | not really7 | 17:39 |
| th1a | It is a strange document. | 17:39 |
| HL1 | I think we should go with original plan | 17:39 |
| th1a | Do we need to discuss the accept/don't accept questions? | 17:39 |
| HL1 | we do - if we want them to read the rest of it | 17:39 |
| HL1 | pain - I know - but am happy to do it | 17:40 |
| th1a | I mean, do we need to discuss what our answers will be? | 17:40 |
| HL1 | I went through them - I was not opposed to accepting any of them - they are all very 'in principle' - i.e. if you were to get the contract etc.... | 17:40 |
| th1a | OK. | 17:40 |
| HL1 | did you look at the bottom part of: http://wiki.tsf.org.za/SchoolTool | 17:41 |
| th1a | Yes. | 17:41 |
| HL1 | the gov OS strat has not been touched since June last year.... | 17:41 |
| th1a | I can write something up. | 17:41 |
| HL1 | but they are there in principle... | 17:42 |
| th1a | The thing is, realistically, the most that is likely to happen is to import/export according to the data dictionary they're already working on. | 17:42 |
| th1a | Which one would hope they were planning anyhow. | 17:43 |
| HL1 | implications for interoperability? | 17:43 |
| th1a | I mean, that's how you'd handle interoperability, short of building a full web service system, | 17:43 |
| th1a | which would be considerably more complex and risky. | 17:43 |
| HL1 | ahhh - ok | 17:43 |
| HL1 | so that is all good? | 17:44 |
| th1a | What it comes down to is that we can make a pretty simple technical request. | 17:44 |
| th1a | Which hopefully they were planning on doing anyhow. | 17:44 |
| th1a | I should read over the document to see what it says about that. | 17:44 |
| HL1 | never assume ANYTHING! | 17:44 |
| th1a | Yes. | 17:44 |
| HL1 | it does not say much about that sort of thing - just gives a huge list of odd 'specs' | 17:45 |
| HL1 | they don;t appear to be real specs | 17:45 |
| HL1 | just a list of user requirements - saying what but not how | 17:45 |
| th1a | Is it OK if I write a draft later today? | 17:46 |
| HL1 | sure thing | 17:46 |
| th1a | OK. I'll do that. Should be short and simple, I presume. | 17:47 |
| HL1 | I will set up the doc with all of the accept/do not accept etc.... | 17:47 |
| th1a | OK. | 17:47 |
| HL1 | short and simple - the name of the game! | 17:47 |
| HL1 | thanks Tom | 17:47 |
| th1a | Excellent. | 17:47 |
| th1a | Thank you Helen. Shoudl I post it on the wiki or email it? | 17:47 |
| th1a | Or both? | 17:47 |
| HL1 | both | 17:47 |
| th1a | OK. | 17:47 |
| HL1 | later potater | 17:48 |
| th1a | bye! | 17:48 |
| PupenoK | mgedmin: mail sent. | 17:51 |
| mgedmin | PupenoK: mail received | 17:53 |
| mgedmin | PupenoK: account created, please test -- access instructions are on http://source.schooltool.org/ | 17:55 |
| mgedmin | note in particular that the filesystem path part differs for http:// and svn+ssh:// access | 17:56 |
| jinty | faassen: still there? | 17:56 |
| PupenoK | mgedmin: thanks. | 17:57 |
| PupenoK | working :) | 17:59 |
| PupenoK | brb. | 18:00 |
| faassen | jinty: on phone | 18:01 |
| jinty | k | 18:01 |
| *** alga has quit IRC | 18:09 | |
| faassen | jinty: back | 18:11 |
| jinty | faassen: ok, re the zc.* eggs | 18:11 |
| jinty | since you seem to be taking care of them | 18:12 |
| jinty | or not, I don't know | 18:12 |
| jinty | any objections if I re-release them with updated copyright | 18:12 |
| jinty | and include tar.gz with the eggs? | 18:12 |
| jinty | well, not re-release, more just a new release | 18:15 |
| *** PupenoK has quit IRC | 18:15 | |
| faassen | jinty: sure, do you want to update the version numbers? | 18:17 |
| faassen | jinty: or not? | 18:17 |
| faassen | jinty: no objections to you releasing newer versions. | 18:17 |
| faassen | jinty: I'm taking care of them, in the sense that I just did the minimal stuff to have them work. :) | 18:17 |
| jinty | faassen: yep, like 0.5 -> 0.51 | 18:18 |
| * jinty will add his own minimal stuff | 18:18 | |
| jinty | any ideas how I can guide people to always release a .tar.gz when they release an egg? | 18:19 |
| povbot | /svn/commits: * gintas committed revision 6131: | 18:19 |
| povbot | /svn/commits: Updated security policy docs. | 18:19 |
| jinty | faassen: my current best idea is a makefile rule | 18:19 |
| povbot | /svn/commits: * gintas committed revision 6132: | 18:24 |
| povbot | /svn/commits: Removed the old ACL page. | 18:24 |
| povbot | /svn/commits: * gintas committed revision 6133: | 18:26 |
| povbot | /svn/commits: Noted that local grants are gone. | 18:26 |
| *** whaddon has joined #schooltool | 18:27 | |
| faassen | jinty: where does one release a .tar.gz? | 18:28 |
| faassen | jinty: I mean, I only release the eggs, but where would one put the tgz? | 18:28 |
| jinty | the same place as the eggs I presume? | 18:29 |
| povbot | /svn/commits: * gintas committed revision 6134: | 18:29 |
| povbot | /svn/commits: Mentioned the custom security policy in app/security.txt. | 18:29 |
| jinty | downloads.zope.org/distribution has quit a few tar.gz there | 18:29 |
| *** whaddon has quit IRC | 18:30 | |
| *** whaddon has joined #schooltool | 18:32 | |
| faassen | jinty: okay, I'll place them there. | 18:33 |
| faassen | jinty: a makefile rule would be easiest for me, sure. | 18:33 |
| povbot | /svn/commits: * gintas committed revision 6135: | 18:33 |
| povbot | /svn/commits: Cosmetic fix. | 18:33 |
| jinty | faassen: thanks, I'll go and get them copyright clean enough to pass the debian gatekeepers. | 18:36 |
| faassen | jinty: great! | 18:41 |
| *** whaddon has quit IRC | 18:52 | |
| *** whaddon has joined #schooltool | 18:53 | |
| povbot | /svn/commits: * faassen committed revision 6136: | 18:55 |
| povbot | /svn/commits: Remove password editing logic from the person edit form; we now have a separate form for this. | 18:55 |
| *** whaddon has quit IRC | 18:57 | |
| *** HL1 has left #schooltool | 19:26 | |
| ignas | th1a: ping :) | 19:31 |
| *** srichter has quit IRC | 20:02 | |
| th1a | ignas: pong. | 20:31 |
| ignas | some questions ... | 20:31 |
| ignas | changePassword is a preference or deserves a row of it's own? | 20:32 |
| ignas | calendar overlay list should go where, as at the moment we are leaning to special casing it (only allow owners look or edit the overlay list) | 20:33 |
| th1a | I think it does deserve a row of its own. | 20:33 |
| th1a | But if it is going to break a bunch of stuff... | 20:33 |
| th1a | it might not be worth it. | 20:34 |
| th1a | Calendar overlays: that sounds right. Owners only. | 20:34 |
| ignas | th1a: not really break, and if we will get LDAP some time, we will want to disallow users changing their passwords while still letting them to edit their preferences ... | 20:34 |
| th1a | They are different things, really. | 20:35 |
| ignas | gintas just explained me a way to do a really simple security policy that would cover all schooltool usecases elegantly | 20:36 |
| ignas | but there is no way to do that in Zope3 :/ | 20:36 |
| ignas | ok, byew | 20:38 |
| ignas | s/byew/bye | 20:38 |
| th1a | Good night! | 20:39 |
| *** ignas has quit IRC | 20:56 | |
| *** faassen has quit IRC | 21:08 | |
| *** alga has joined #SchoolTool | 21:17 | |
| *** pcardune has joined #schooltool | 21:48 | |
| *** thisfred has quit IRC | 22:15 | |
| *** srichter has joined #schooltool | 22:20 | |
| *** mgedmin has quit IRC | 22:51 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!
