| *** karstix has joined #schooltool | 00:08 | |
| *** karstix has left #schooltool | 00:09 | |
| *** karstix has joined #schooltool | 00:24 | |
| *** karstix has left #schooltool | 00:31 | |
| *** karstix has joined #schooltool | 00:32 | |
| *** Ninno has quit IRC | 00:45 | |
| *** karstix has left #schooltool | 01:04 | |
| *** jfroche has quit IRC | 01:12 | |
| *** didymo has joined #schooltool | 01:52 | |
| *** didymo has quit IRC | 02:01 | |
| *** didymo has joined #schooltool | 02:01 | |
| *** jinty has quit IRC | 02:24 | |
| *** Aim2 has quit IRC | 02:49 | |
| *** Aim2 has joined #schooltool | 03:09 | |
| *** alga has quit IRC | 03:29 | |
| *** DeathOmen has joined #schooltool | 03:59 | |
| *** Bhaskar has joined #schooltool | 05:53 | |
| Bhaskar | thla:hello u know schooltool? | 07:12 |
|---|---|---|
| th1a | Hi Bhaskar. | 07:21 |
| Bhaskar | thla:hi | 07:21 |
| th1a | Unfortunately, I don't understand internationalization. | 07:22 |
| th1a | So I don't know how to help you with your translation problems. | 07:22 |
| th1a | I can see if one of the other developers can. | 07:22 |
| Bhaskar | thla: i have problem on schooltool: running schooltool and schoolbell simultaneously?? | 07:23 |
| th1a | Oh... that might cause a problem. | 07:24 |
| th1a | Are they trying to use the same port? | 07:24 |
| th1a | Basically, we aren't actively developing SchoolBell anymore anyhow. | 07:24 |
| th1a | You should concentrate on SchoolTool. | 07:24 |
| Bhaskar | thla , u r involving schooltool development ? | 07:51 |
| *** didymo has quit IRC | 07:57 | |
| Bhaskar | thla: how can i customize schooltool? | 08:01 |
| th1a | Bhaskar: I am the project manager for SchoolTool. | 08:18 |
| th1a | Do you have any experience with Python programming? | 08:18 |
| Bhaskar | thla:well | 08:18 |
| Bhaskar | thla:little not in depth | 08:18 |
| Bhaskar | thla: in Nepal, i m involving localization, customization of schooltool | 08:19 |
| th1a | Yes. | 08:19 |
| Bhaskar | thla: in nepali language | 08:20 |
| th1a | Do you think you might be able to meet with some of our programmers in person (you emailed me about this)? | 08:20 |
| Bhaskar | thla: i have already done some work on localization of schooltool | 08:20 |
| Bhaskar | thla:if u cooperate i can consult with them pls specify their mailing list | 08:21 |
| Bhaskar | thla:my email:b_bprimal@yahoo.com | 08:21 |
| th1a | The schooltool-dev list is best. | 08:21 |
| Bhaskar | thla: can your project trained to us? | 08:22 |
| Bhaskar | thla: i mean any training regarding to the schooltool | 08:22 |
| th1a | I can't train you myself, I'm not a good enough programmer. | 08:22 |
| th1a | There are several developers in Lithuania who would be capable of giving you some training, and perhaps I could fund their work. | 08:23 |
| Bhaskar | thla:well how can i consult with them | 08:24 |
| th1a | We should talk to ignas. One problem is that Nepal time is still pretty far ahead of Lithuania. | 08:26 |
| th1a | So usually you guys are on here while they're asleep (and right before I go to bed). | 08:26 |
| th1a | We'll have a developer meeting today at 1430 UTC, here. | 08:27 |
| Bhaskar | thla: so you talk about Nepal | 08:27 |
| th1a | Do you know Ashik? | 08:28 |
| Bhaskar | thla: if we meet in a single forum it is better | 08:28 |
| Bhaskar | thla: he had gone from here and i join for this project | 08:28 |
| Bhaskar | thla: i am handling schooltool project here in Nepal | 08:30 |
| Bhaskar | thla:we are planning to implement schooltool in around 2500 schools in Nepal | 08:30 |
| th1a | Yes. Well, we'll have to get you to Lithuania for a visit, I think. | 08:31 |
| Bhaskar | thla: but how can i | 08:32 |
| Bhaskar | thla: we have no fund ? | 08:32 |
| th1a | OK... I thought you said you did. | 08:33 |
| Bhaskar | thla:well | 08:33 |
| th1a | I'll talk to the developers and see if we can get some ideas. | 08:33 |
| Bhaskar | thla:ok | 08:34 |
| Bhaskar | thla: any success case study of this project in Lithuania? | 08:34 |
| Bhaskar | thla:they may be useful for us in Nepal | 08:35 |
| Bhaskar | thla: how many school are using this tool in Lithuania? | 08:35 |
| th1a | Well, we're working with one school in Lithuania to deploy SchoolTool next year. | 08:36 |
| th1a | I'm afraid we might not be ready for 2500 schools in Nepal yet. | 08:36 |
| Bhaskar | thla: in first phase we are planning for 5 school | 08:37 |
| th1a | Good. | 08:37 |
| Bhaskar | thla: upto Next year we hole we are ready for deploying for 5 school, some private school and some of them are governmental school or some may be community based school | 08:39 |
| Bhaskar | thla: we hope | 08:39 |
| th1a | When does school start? | 08:39 |
| Bhaskar | thla: schoolstart from from March session here in Nepal | 08:40 |
| Bhaskar | thla: pls share your planning to deploy one school in Lithuania | 08:41 |
| *** Aiste has joined #schooltool | 08:42 | |
| th1a | Well, we have one developer (ignas) working with a secondary school in Vilnius. | 08:42 |
| th1a | We also have a developer (jfroche) working with a school in Brussels, Belgium. | 08:42 |
| Bhaskar | thla: why not we come in a single forum to share experiences to each other | 08:44 |
| th1a | What forum do you suggest? | 08:47 |
| th1a | Things just haven't been very chatty lately because of the holidays. | 08:48 |
| Bhaskar | thla: i think set a Conference for schooltool which brings all the developers, founder and all relating people in common plateform | 08:49 |
| th1a | Well, could you get to such a conference? | 08:50 |
| Bhaskar | thla: so that there will more interaction and discussion about schooltool | 08:50 |
| Bhaskar | thla: if schooltool organizer invite us we will attend..... | 08:51 |
| th1a | Well, we'll all be at PyCon, and most of us will be at EuroPython. | 08:51 |
| Bhaskar | thala: well | 08:53 |
| Bhaskar | thla:if Shuttleworth Foundation arrange for schooltool conference, this is better for all | 08:55 |
| th1a | Easier for you to get funding? | 08:56 |
| Bhaskar | thla : t think Shuttleworth Foundation arrange fund because we are from poor country | 08:58 |
| th1a | OK. I understand. | 08:58 |
| th1a | I'll look into it. | 08:59 |
| Bhaskar | thla: we want to add new innovative ideas to speed up schooltool project all over the developing as well as under developing country | 09:00 |
| th1a | Yes. We'd like to make that happen, too. | 09:01 |
| Bhaskar | thla:basically Asian school have no systematic management , so this tool may be a grate | 09:01 |
| Bhaskar | thla: we should broaden the areas, and the concept of opensource worldwide | 09:02 |
| Bhaskar | thla: in Nepal we are starting a revolution in opensource | 09:03 |
| th1a | Bhaskar: Yes, I agree in principle, but in practice we've found that we needed to narrow the scope in the short term in order to actually finish and ship some software. | 09:03 |
| th1a | We just get overwhelmed with the worldwide scope and only a few developers. | 09:03 |
| th1a | So we need to focus on some specific schools for a year. | 09:04 |
| th1a | We're not quite ready, in general, for a global SchoolTool conference, but hopefully next year. | 09:04 |
| th1a | But I'll think about how to get you in better communication with the rest of the team. | 09:05 |
| th1a | In the meantime, I need to go to bed. | 09:05 |
| th1a | It is 2:00 AM here. | 09:05 |
| Bhaskar | thla: we should bring more developers, trained them and deploy | 09:06 |
| Bhaskar | thla: i think we people keep in touch | 09:06 |
| th1a | It would be helpful if I had a better idea of your overall project. I could never quite get Ashik to give me the big picture. | 09:07 |
| Bhaskar | thla:well | 09:08 |
| th1a | Bhaskar: Perhaps you could send me an email. | 09:10 |
| th1a | I'm off to bed. | 09:10 |
| th1a | Good night. Nice chatting with you. | 09:10 |
| Bhaskar | thla ok have good night | 09:10 |
| Bhaskar | joerg:hello | 09:17 |
| Bhaskar | joerge: do u know school tool | 09:22 |
| joerg | no | 09:33 |
| Bhaskar | Aim2: hello | 09:39 |
| Bhaskar | do u know school too | 09:40 |
| *** Bhaskar has quit IRC | 10:11 | |
| *** thisfred has joined #schooltool | 11:40 | |
| *** povbot` has joined #schooltool | 11:51 | |
| *** jfroche has joined #schooltool | 11:54 | |
| *** ignas has joined #schooltool | 12:06 | |
| *** jinty has joined #schooltool | 12:19 | |
| *** povbot has quit IRC | 12:19 | |
| *** didymo has joined #schooltool | 13:00 | |
| *** vidasp has joined #schooltool | 13:06 | |
| *** alga has joined #SchoolTool | 14:12 | |
| *** joerg_ has joined #schooltool | 14:32 | |
| *** joerg has quit IRC | 14:45 | |
| *** ddaa has joined #schooltool | 14:49 | |
| ddaa | ignas: ping | 14:50 |
| ignas | xpong | 14:50 |
| ddaa | First... | 14:51 |
| ddaa | Happy new year | 14:51 |
| ignas | Yippieeeee :) | 14:51 |
| ddaa | Okay, now done with the formalities | 14:51 |
| ignas | Gratz :) | 14:51 |
| ddaa | did you have time to test the last import I gave you? | 14:51 |
| ignas | yes | 14:52 |
| ignas | brilliant, wonderful, yay :) | 14:53 |
| ignas | more than I have expacted | 14:53 |
| ignas | thanks :) | 14:53 |
| ddaa | Does this mean you are satisfied? | 14:53 |
| ignas | it is already usable, but there are some minor details | 14:54 |
| ddaa | Ah! | 14:54 |
| ddaa | Listening. | 14:54 |
| ignas | check ins are not ordered by date in bzr log | 14:54 |
| ddaa | can you show me a paste that exhibits the unwanted behaviour? | 14:55 |
| ignas | ok | 14:55 |
| ddaa | I sort of guess what's the problem... | 14:55 |
| ddaa | bzr log shows merges, so the logs are sorted topologically, so revisions that are merged in a mainline revisions appear before other mainline revisions. | 14:56 |
| lisppaste5 | ignas pasted "Example of mixed checkin order" at http://paste.lisp.org/display/33944 | 14:56 |
| ddaa | mh | 14:56 |
| ignas | ddaa: not sure i understood the explanation, sorry | 14:57 |
| ignas | it seems that independent revisions get shuffled a bit | 14:57 |
| ddaa | I see. | 14:57 |
| ignas | and sometimes (i'll try to find where) merges re in the oposite direction ... i mean as if feature appears in a commit with message "Merge from trunk" and then is merged to trunk with message "Implemented feature A" | 14:58 |
| ddaa | I vaguely remember seeing some commit messages for merges to trunk reading "implemented feature", which makes some sense | 15:00 |
| ddaa | for the "merge from trunk", I have an idea of what's the problem, but I would need to check first. Otherwise it might be confusing. | 15:01 |
| ignas | by the way maybe it would not take too much time to implement a branch rename or something like that for branches that are being deleted? like instead of deleting a branch just rename it to branches/deleted/schoolbell-date-of-deletion | 15:02 |
| ddaa | ignas: did you look at the "attic" directory? | 15:03 |
| ignas | hmm | 15:03 |
| ignas | no, not really :) | 15:03 |
| ignas | cool :) | 15:03 |
| ignas | it's all there :) | 15:03 |
| ddaa | About the log ordering, can you paste the log starting with a mainline revision (last revision with no identation in the log before the mixed revisions). | 15:03 |
| ddaa | Also, if you can give me a log about the mixed merge/implement logs, that would help a lot to track the problem. | 15:05 |
| ignas | ok, looking for it, bzr visualize takes a bit of time to show up | 15:06 |
| lisppaste5 | ignas annotated #33944 with "more revisions" at http://paste.lisp.org/display/33944#1 | 15:06 |
| ddaa | ignas: what's the problem in the new paste? | 15:07 |
| ignas | that should have been "(last revision with no identation in the log before the mixed revisions)" | 15:08 |
| ignas | but now i have understood that i have misread it | 15:08 |
| ignas | going to look at the logs once more | 15:08 |
| ignas | kind of strange ... | 15:15 |
| ignas | the date on a revision that merges | 15:16 |
| ignas | is smaller than the one on the revision being merged from | 15:16 |
| ddaa | sounds weird | 15:16 |
| ignas | like - the patch is merged from the future ... | 15:16 |
| ignas | http://ignas.pov.lt/Screenshot-2.png | 15:17 |
| ddaa | I see | 15:18 |
| * ddaa checks the svn log | 15:18 | |
| ignas | these are from an up to date repository though ... | 15:19 |
| ignas | i mean it's lyceum branch | 15:19 |
| ddaa | url to the repo? | 15:19 |
| ddaa | you mean the more recent dump? | 15:19 |
| ignas | yes | 15:20 |
| ignas | ftp://ftp.schooltool.org/pub/schooltool/st-repo.tar.gz | 15:21 |
| ignas | it was there, hope it still is there | 15:21 |
| ddaa | thanks | 15:21 |
| ddaa | downloading | 15:21 |
| ddaa | found it in the logs :) | 15:21 |
| ddaa | I fully expect to find the dates are mixed up in the svn repo, but I want to check :) | 15:22 |
| ignas | what seems strange is that when showing 2 branches in parallel bzr is not ordering checkins by date | 15:24 |
| ddaa | I'm not sure what you mean. I do not know a way to show two branches in parallel with bzr. | 15:25 |
| ignas | bzr visualise | 15:25 |
| ddaa | I guess you are referring to the recursive log listing. | 15:25 |
| ddaa | bzr vis orders revision by ancestry | 15:25 |
| ddaa | for parallel lines of ancestry, it tries to group related revisions toghether | 15:26 |
| ignas | oh | 15:26 |
| ddaa | initially it did not do this, and that made it much harder to read | 15:26 |
| ddaa | so I fixed it :) | 15:26 |
| ignas | :) | 15:26 |
| ignas | i guess it makes more sense for normal bzr branches | 15:27 |
| ddaa | yup. I understand that it feels weird when looking at it with svn goggles. | 15:27 |
| ignas | dates are nearly always shuffled in merges, i mean feature added is after the feature merged date | 15:27 |
| *** vidasp has quit IRC | 15:27 | |
| ddaa | I really need an example to find the revision... even a screenshot with a reasonably unique commit message is okay | 15:28 |
| ddaa | okay... the dates are confuddled | 15:31 |
| ddaa | "Merge Jinty's and event id stuff to lyceum branch." is "2006-11-16 19:59:47 +0100" in the svn log. | 15:31 |
| ddaa | And 2006-11-20 something in the bzr vis screenshot | 15:32 |
| ignas | srichter-20061229150716-sjb48uo8xk1yrmi3 is the merge from srichter-20061229150658-6ovnj3wj1i6hqtsf | 15:34 |
| ignas | dates seem to be confused too | 15:34 |
| ddaa | no doubt, something is wrong with how dates are read from svn | 15:34 |
| ddaa | sorting my branches now to look at it | 15:34 |
| ddaa | got some uncommitted optimizations I need to get out of the way first | 15:35 |
| ddaa | mhmh... | 15:44 |
| ddaa | okay, I found the problem | 15:49 |
| ddaa | stupid untested code :( | 15:49 |
| ddaa | <insert rant here about how date-time handling in python is an incredible confusing mess> | 16:27 |
| th1a | I'm on the phone with Dave Welsh... | 16:29 |
| * ddaa -> lunch | 16:29 | |
| * th1a shuffles some papers around. | 16:30 | |
| th1a | Hi ignas, jfroche. | 16:31 |
| th1a | Happy New Year everyone. | 16:31 |
| jfroche | hello th1a best wishes for 2007 | 16:31 |
| ignas | happy new year | 16:31 |
| ignas | ddaa: hmm, can you guide me to the place you are having problems with, i am kind of specialising in datetime timezone stuff | 16:32 |
| th1a | So ddaa is helping with bzr migration? | 16:32 |
| th1a | Or.. I'm confused. | 16:32 |
| ignas | yes he is | 16:33 |
| ignas | he is more or less doing the migration actually | 16:33 |
| ignas | i am the one who is helping | 16:33 |
| th1a | Excellent. | 16:34 |
| th1a | OK... updates and plans for the next week or so? | 16:35 |
| jfroche | i am meeting Nicolas tomorrow | 16:35 |
| th1a | ignas: What's up in Vilnius? | 16:35 |
| jfroche | we will speak/write down the goals | 16:35 |
| jfroche | will be able to tell you more tomorrow | 16:35 |
| jfroche | i will start in the school monday next week | 16:36 |
| th1a | Tomorrow would be good. Invoice me as well for December. | 16:36 |
| th1a | Excellent. | 16:36 |
| ignas | th1a: i have merged all the changes branche<->trunk wise | 16:36 |
| jfroche | ah yes about this, i am creating my company... is it ok if i invoice you as soon as it's created (should be in 2week) ? | 16:37 |
| th1a | Hm... I don't want there to be any confusion with Mark & the bank about what's coming from which year's budget, so I'd prefer if we could do it now. | 16:38 |
| ignas | refactored schoolbell for the fun of it:) | 16:38 |
| th1a | ignas: Yes, what's the status of that? | 16:38 |
| th1a | What does it do? | 16:38 |
| jfroche | th1a: ok no problem | 16:38 |
| ignas | it works, if someone will report a bug - i will probably fix it :) | 16:38 |
| th1a | Works in what sense? | 16:38 |
| th1a | Works well enough to update the SchoolBell page on the website? | 16:39 |
| ignas | th1a: works in "i am not responsible for the quality and tests are not passing" sense | 16:39 |
| ignas | i did it for fun, and for people who are feeling adventurous :) | 16:39 |
| th1a | OK. I guess I can at least point to the branch for the adventurous. | 16:40 |
| ignas | i have written an email to the dev list i think | 16:40 |
| th1a | Yes. | 16:41 |
| ignas | now I am working on the resource booking, to make it fully deployabe | 16:42 |
| jfroche | th1a: does Nicolas has the same role as before or has he more commitment than before ? | 16:43 |
| th1a | What do you mean by "fully deployable?" | 16:43 |
| ignas | with all the features they wanted before the first deployment i think | 16:43 |
| th1a | jfroche: He has more commitment than before, I'd say, because I have a little money to pay him. | 16:43 |
| ignas | hmm, now i just remembered one feature that is missing | 16:43 |
| th1a | What your school wanted? | 16:44 |
| ignas | editable Timetable events, fck editor integration | 16:44 |
| ignas | cookie based language switcher | 16:45 |
| th1a | OK. I haven't read your 2007 proposal yet... I suppose it is in there. Had a kind of hectic holiday. | 16:46 |
| th1a | Lots of painting. | 16:47 |
| ignas | happens | 16:47 |
| ignas | i did quite a lot of programming, merging, proposing during these days :) | 16:47 |
| ignas | more productive than usually :) | 16:47 |
| th1a | I saw the big checkins. | 16:47 |
| th1a | Yes, holidays can be productive times, when you're single or at least childless ;-) | 16:48 |
| *** vidasp has joined #schooltool | 16:48 | |
| ignas | :D | 16:48 |
| th1a | That's changing for me, rapidly. | 16:48 |
| th1a | OK, what else... | 16:49 |
| th1a | I was chatting with our friend in Nepal. | 16:50 |
| th1a | Last night. | 16:50 |
| ignas | have you seen my chat with him before that ? | 16:50 |
| ignas | Thursday i think | 16:50 |
| th1a | They're government wants to test SchoolTool in 5 schools. | 16:50 |
| th1a | Oh... I don't think I read it. | 16:50 |
| ignas | well apparently he doesn't know python nor Zope, his english skills are not good enough to a lot of documentation and he wants to customize schooltool (or us do it for him) | 16:51 |
| ignas | s/to a lot/to read a lot/ | 16:52 |
| th1a | RIght. | 16:52 |
| th1a | Kind of a difficult situation. | 16:52 |
| th1a | I don't expect you to spend a lot of time with him. | 16:52 |
| ignas | and i am no sure if it's a cultural thing, or he likes asking random people about schooltool without finding out who they are | 16:52 |
| th1a | Well, yeah. Nepal is a long way away. | 16:53 |
| th1a | In several ways. | 16:53 |
| ignas | it seems that his main occupation is adapting schooltool for Nepal, and he just does not know what to do now, that the translation is more or less finished ... | 16:54 |
| ignas | and i have failed at explaining him the difference between the developer sandbox and dapper schooltool :/ | 16:54 |
| th1a | Yes, I would like to help him get the translation running, although I'm personally useless at that task. | 16:55 |
| ignas | language barrier i think :/ | 16:55 |
| th1a | Hm... ok. That's helpful in knowing where he's starting from. | 16:55 |
| ignas | if he would ask questions and do his homework i could help him a lot ... | 16:55 |
| ignas | but it seems that he just wants us to solve his problems :/ | 16:55 |
| th1a | What I'm going to do is talk to jelkner about perhaps getting him integrated into some of the training he's starting with his interns. | 16:56 |
| ignas | hmm, maybe that would work | 16:56 |
| th1a | In fact, perhaps a few of them could work directly with the Nepal folks. Would look good on a college application. | 16:56 |
| th1a | Also, SchoolTool is funding some of those interns, so that gives me a little pull... | 16:57 |
| ignas | but how to make him stop pinging everyone by mail, or IRC ? he even tried talking to povbot ... | 16:57 |
| ignas | i have told him that i can help him with his issues, but he didn't tell me what they were :/ | 16:57 |
| th1a | Um... well, I'll try to get it under control. | 16:57 |
| ignas | and today he asked you same things i have told him about ... | 16:58 |
| th1a | I know... | 16:58 |
| th1a | I won't put this on your shoulders. | 16:58 |
| ignas | I think his most recent problem is translating 2006 pot not the release | 16:59 |
| ignas | can't be sure though ... | 16:59 |
| th1a | Oh... that seems likely. OK. | 16:59 |
| th1a | I think we can wrap this up early then. | 17:00 |
| ignas | i don't know what schooltool he is running at the moment, and i don't know where he got the 2006 url | 17:00 |
| th1a | Probably from me ;-) | 17:00 |
| th1a | I'll talk to him tonight. | 17:00 |
| ignas | th1a: ping me if you'll have questions/comments about the proposal | 17:00 |
| th1a | I'll look at it this afternoon. | 17:01 |
| ignas | thanks | 17:01 |
| th1a | Anything else? | 17:01 |
| ignas | hmm, any news about CanDo ? | 17:02 |
| ignas | their next meeting, etc. | 17:02 |
| th1a | It is in a few weeks, I think. | 17:02 |
| * jinty just notes that he is busy installing pqm and a test bzr repo on schooltool.org | 17:02 | |
| th1a | Happy New Year, jinty! | 17:02 |
| jinty | Happy new year all;) | 17:03 |
| ignas | 2006 2.0 :) | 17:03 |
| jinty | ignas: have any thoughts on pqm? | 17:03 |
| th1a | jinty: You're in the budget for 2007 to continue sys admining all year, btw. | 17:03 |
| jinty | cool;) | 17:04 |
| * jinty will also try do some release infrastructure work at some stage as well... | 17:05 | |
| th1a | Eggification, when the time comes? | 17:06 |
| ignas | no not really, i haven't seen how it works really ... | 17:06 |
| ignas | jinty: ^ | 17:06 |
| th1a | jinty: Are you planning to go to EuroPython? | 17:06 |
| jinty | th1a: yes, but I'm still patiently waiting for what is happening with zope3 | 17:06 |
| jinty | th1a: yes, if I can | 17:07 |
| th1a | OK. I can probably give you some funding for that. | 17:07 |
| jinty | ignas: good reason to try it out then, seems to be the only sane way of running post commit hooks. | 17:07 |
| ignas | hmm, any urls of the repository ? | 17:08 |
| jinty | th1a: great! I'll speak to you when the time comes! you coming as well? | 17:08 |
| th1a | ignas: Can we do a little sprint before or after EuroPython? | 17:08 |
| th1a | I'll be there and Paul Carduner from CanDo. | 17:08 |
| jinty | ignas: for now there's an empty repository at http://staging.schooltool.org/bzr/schooltool/trunk/ | 17:08 |
| ignas | th1a: with pleasure, if it will be a sprint on the data archiving or gradebook - wit heven more plasure :) | 17:08 |
| th1a | ignas: OK. | 17:09 |
| th1a | Do you need anything else from me re:PyCon? | 17:09 |
| ignas | hmm | 17:09 |
| ignas | let me see if i have the letter in my mail | 17:09 |
| th1a | Oh... also, you and jfroche should plan another meeting. | 17:09 |
| * ddaa uploads st.bzr-7.tgz, ETA 10 mins | 17:09 | |
| ddaa | fixed svn2bzr.schooltool uploaded already | 17:10 |
| th1a | You've got 2000 euro for the year for those trips, iirc. | 17:10 |
| ignas | ddaa: is there a way to see the diff when bzr pulling changes ? | 17:10 |
| jfroche | th1a: ok | 17:11 |
| ddaa | ignas: you can "bzr merge ; bzr diff; bzr revert ; bzr pull" | 17:11 |
| jfroche | th1a: do we go all to pycon ? | 17:11 |
| ddaa | since the the merge already fetched all the data, the pull will be fast | 17:11 |
| th1a | jfroche: Do you need anything from me? Do you need a visa, too? | 17:12 |
| jfroche | i think so yes | 17:12 |
| th1a | I don't know if there is a difference in how we receive guests from Belgium and Lithuania. | 17:12 |
| ddaa | mh... the branch nick computation will need another small tweak | 17:12 |
| ddaa | but the dates should now be parsed correctly | 17:12 |
| * ddaa -> lunch, really | 17:12 | |
| th1a | jfroche: I'll send you a letter. | 17:13 |
| ddaa | in theory, should be able to "bzr diff url_to_remote", but last I checked, bzr diff did not work if the other branch did not have a working tree. | 17:13 |
| ddaa | (known bug, might have been fixed) | 17:14 |
| ignas | ddaa: thanks | 17:14 |
| jfroche | th1a: i have to ask if i can fit with the Visa Waiver Program | 17:14 |
| jfroche | but could you send me the same paper you sent to ignas ? | 17:14 |
| th1a | Yes. | 17:14 |
| th1a | I'll even try to change all the instances of his name. | 17:15 |
| jfroche | th1a: you decided the dates ? | 17:15 |
| th1a | Yes. We'll sprint for four days after the conference. | 17:16 |
| jfroche | should i book conference ? planes ? | 17:16 |
| th1a | Well, let's get a sense of the visa info. | 17:17 |
| th1a | I'll book the conference; you can handle the plane (we'll reimburse). | 17:17 |
| jfroche | 22 feb => 29 feb ? | 17:19 |
| jfroche | uhm | 17:19 |
| jfroche | no 29 | 17:19 |
| jfroche | 1 mar | 17:19 |
| th1a | Sounds right. | 17:19 |
| th1a | OK... anything else? | 17:22 |
| * th1a drops the bag of gravel. | 17:23 | |
| ignas | jinty: hmm, how about committing to the repository ? bzr doesn't want to push to an http source ... | 17:25 |
| ignas | jinty: or i should publish my changes, and you will merge/pull them? | 17:26 |
| jinty | ignas: that's where pqm comes in | 17:26 |
| jinty | you send a gpg signed mail to pqm@schooltool.org | 17:26 |
| ignas | ok | 17:27 |
| ignas | what should be the content of the email ? | 17:27 |
| jinty | and it'll pull the changes | 17:27 |
| jinty | but it's not set up yet | 17:27 |
| ignas | oh :) | 17:27 |
| * jinty loves non-released software with a dpendency chain from hell | 17:27 | |
| ignas | jinty: now, what about being able to commit things to the repository without pqm, as i am not sure i have more reliable web space than schooltool.org for publishing of my branches | 17:37 |
| ignas | having trunk managed by pqm is fine | 17:37 |
| ignas | but i would like to have commit access to the lyceum branch, new-navigation branch as i just don't know how using pqm for a branch that might disappear will work out ... | 17:39 |
| jinty | ignas: I'm not sure what would be easier, making a repository you can commit to, or just giving you a space on the net to publish things | 17:39 |
| jinty | I think the lyceum branch would be easier to manage as your personal branch | 17:41 |
| jinty | I just want one branch where I can specify that things like buildbot and commit mails are run | 17:42 |
| ignas | hmm | 17:43 |
| jinty | once I have pqm up, I'll see what I can do about giving developers space to put their repositories | 17:43 |
| ignas | as else i would have to put it up on pov servers, and well, i just can | 17:43 |
| ignas | 't | 17:44 |
| ignas | be sure they will be up ... | 17:44 |
| jinty | I think they only need to be up when you try and merge | 17:44 |
| jinty | not sure if they need to be up for the rest of eternity... | 17:45 |
| ignas | yes, but if jfroche wants to get my lyceum tweaks ... | 17:45 |
| ignas | now everyhing commited to a branch is available to wveryone on the project | 17:45 |
| jinty | yeah, but I thought we wanted to get away from centralization;) | 17:46 |
| ignas | well i will be able to commit without any repos | 17:47 |
| ignas | available online | 17:47 |
| ignas | but i want to have a safe place to push my changes | 17:48 |
| ignas | or to pull from | 17:48 |
| ignas | and what i wanted was an easier way to manage 2+ branches | 17:48 |
| jinty | I do see what you mean, but we also need a central place linked to buildbot and such | 17:49 |
| * ignas just merged ~7 commits from trunk to branch and ~5 commits from branch to trunk | 17:49 | |
| ignas | yes so the trunk will be the only part buildbot will care about | 17:49 |
| jinty | perhaps we could have another place where developers could put their own work | 17:49 |
| ignas | suits me | 17:49 |
| ignas | as long as there is a place | 17:50 |
| jinty | but I'm not sure what is the best way for it to work... | 17:50 |
| ignas | hmm, can bzr push through https? | 17:50 |
| jinty | looks like the stuff to do that was pretty experimental | 17:52 |
| jinty | I really don't want to spend ages bug hunting... | 17:52 |
| ignas | hmm | 17:53 |
| jinty | I know that pqm is in production | 17:53 |
| ignas | ssh? | 17:53 |
| jinty | sftp is normally used | 17:53 |
| jinty | but then how do you centrally manage a commit hook | 17:54 |
| ignas | hmm | 17:54 |
| jinty | or we could make cron jobs to send the commit mails | 17:54 |
| ignas | do we need review for all branches | 17:54 |
| jinty | I think it's only _really_ necessary for trunk | 17:55 |
| ignas | so pqm manages the trunk | 17:55 |
| ignas | we could register branches like in launchpad | 17:55 |
| ignas | if we want checkin emails | 17:55 |
| *** mattva01 has joined #schooltool | 17:55 | |
| ignas | but i think if someone will want a WIP review | 17:55 |
| ignas | he will just tell the addreess of his branch | 17:55 |
| ignas | and that's all | 17:56 |
| *** karstix has joined #schooltool | 17:56 | |
| ignas | and when it works good enough - tell pqm to merge stuff | 17:56 |
| ignas | or a corn script that loops through registered branches and sends emails | 17:56 |
| jinty | if we have the cron script, I think pqm is unnecessary | 17:57 |
| jinty | but I have no idea how to write those cron scripts | 17:57 |
| jinty | my bzr-fu is really bad | 17:58 |
| * ddaa comes back from lunch | 17:58 | |
| * jinty grabs ddaa and asks im how to write a cron script that sends commit mails for all new revisions committed to a branch | 18:00 | |
| *** mattva01 has quit IRC | 18:01 | |
| ddaa | jinty: do you need the diffs as well, or jus the commit messages? | 18:04 |
| jinty | diffs as well, for review on a mailing list | 18:04 |
| ddaa | mh... post-commit review... | 18:04 |
| jinty | yes, less sand in the gears;) | 18:05 |
| ddaa | jinty: so, you would like something that monitors a trunk branch, after somebody commits a revision to trunk, an email is sent to a mailing list for people to review. | 18:06 |
| ddaa | if somebody instead pushes to trunk, what should happen? | 18:06 |
| jinty | yes, probably run once an hour via cron | 18:06 |
| ddaa | if there were multiple commits since the last run, you want one message with a combined diff, or multiple messages? | 18:07 |
| jinty | well, if it's for review, anything that changes trunk should have a full diff on the mailing list | 18:07 |
| jinty | multiple messages, would be nice with the name/email of the comitter | 18:07 |
| ddaa | jinty: are you familiar with how push-on-branch differs from merge-commit-on-checkout? | 18:08 |
| ddaa | (that might seem unrelated, but there's a point I want to make, please bear with me) | 18:09 |
| jinty | I am not familiar with very much of baz at all, just trying to figure out ho to administer this | 18:09 |
| jinty | but go ahead | 18:09 |
| ddaa | jinty: baz is the GNU Arch thing, also known as Bazaar 1.x. What we're talking about is bzr, aka Bazaar 2.x (although it's still pre-1.0...) | 18:10 |
| jinty | I presume one is pushing the changes from a branch to another branch, the other is svn like... | 18:10 |
| jinty | ;) yeah, sorry typo | 18:11 |
| ddaa | there's an important difference between push and commit-merge | 18:11 |
| jinty | ? | 18:11 |
| ddaa | If you only merge-commit on a branch, every commit translates to a new revision in the main history (the line of first parents). So in this case it is possible to send one email with diff for each commit. | 18:12 |
| ddaa | But if you push, you can have a situation that looks like this: | 18:12 |
| ddaa | Initially, trunk looks like: A->B->C | 18:13 |
| jfroche | ignas: query an unamed adapter is done by queryAdapterInContext ? | 18:14 |
| ddaa | The feature branch is: A->D->E[C] (E[C] means E merges C, the list of parents of E is ['D', 'C'] | 18:14 |
| ignas | emm, unnamed ? | 18:14 |
| ignas | as in without an interface ? | 18:14 |
| ddaa | Then if feature is pushed to trunk, trunk becomes: A->D->E | 18:14 |
| jfroche | ignas: adapter without a name | 18:15 |
| ignas | paste the definition of the adapter | 18:15 |
| ignas | i mean how is it declared in zcml | 18:15 |
| jfroche | lisppaste5: url | 18:15 |
| lisppaste5 | To use the lisppaste bot, visit http://paste.lisp.org/new/schooltool and enter your paste. | 18:15 |
| ddaa | In this case, history (line of first parents) looks like B and C were removed, and D and E were added. And there is no way to know that this was actually a single operation. | 18:15 |
| lisppaste5 | jfroche pasted "adapter definition" at http://paste.lisp.org/display/33955 | 18:16 |
| ddaa | What happens ancestry-wise (all parents considered) is that D and E were added and nothing was removed. | 18:16 |
| ignas | jfroche: ITimelineAdapter(adaptee) | 18:17 |
| jfroche | right but i would like to avoid doing: | 18:17 |
| ddaa | jinty: my point being: if you allow people to write to a common branch directly, you cannot prevent them from doing push (the UI is a bit confusing in that respect IMO). So you need somehow to be able to deal with this case. | 18:18 |
| jfroche | try: ITimelineAdapter(adaptee) | 18:18 |
| jfroche | except ... | 18:18 |
| jfroche | else... | 18:18 |
| ddaa | in practice, if feature was a long lived, branch, it can look like dozens of revisions were removed and added from the history. You probably do not want to send dozens of email messages in this case, because that really obscures the actual change. | 18:18 |
| jinty | ddaa: So you can't represent D and E as one patch because C comes in between? | 18:19 |
| ignas | jfroche: queryAdapter(parent, ITimelineAdapter, default=None) | 18:19 |
| ddaa | jinty: yes you can | 18:19 |
| jfroche | oh so queryAdapter doesnt require a name ! | 18:19 |
| jfroche | good to know | 18:19 |
| ddaa | jinty: that's the difference with merge-commit-on-a-checkout | 18:19 |
| ddaa | if you do merge-commit, you end up with trunk: A->B->C->F[E] | 18:20 |
| ddaa | and that's nice and easy | 18:20 |
| ignas | jinty: do we want it pqm style or bundle buggy style or svn style? | 18:20 |
| jinty | ignas: I'm not sure what we want exactly, but we do need some method to see what's going into the trunk. | 18:21 |
| jinty | post commit review I believe | 18:22 |
| ddaa | So, what you _can_ do, is make a a _policy_ that says "do _not_ push a branch to trunk. Only push to trunk when you have done commit --local. All new revisions to trunk must be merges" | 18:22 |
| ddaa | Which effectively gives you the same topology as using pqm would. | 18:22 |
| jinty | my experience is that policy doesn't work like that | 18:23 |
| ignas | jinty: i think we could do pre commit reviews for trunk | 18:23 |
| jinty | if people can do something normally they would... | 18:23 |
| ignas | with bzr we can do that and not mess up the pace of development | 18:23 |
| ignas | i was thinking of bundle buggy, but we can use pqm for that as well | 18:23 |
| ignas | the only thing for sane checkin emails we need is a more or less readonly trunk | 18:24 |
| ignas | i mean only have the pqm or BB to merge/push/pull to trunk | 18:24 |
| ddaa | yup... sorry about that. When the smart server is really smart it will be possible to enforce things like "do not push to trunk", but it's not possible yet. | 18:25 |
| ddaa | unless you use a robot to commit to trunk | 18:25 |
| jinty | bb actually does the merge? | 18:25 |
| ignas | hmm | 18:26 |
| ignas | i can't find it's website | 18:26 |
| jinty | I had a look at it, but I didn't see that functionality, I thought it was just a tracker. | 18:26 |
| ddaa | IMO, you could go ahead with just enforced-by-policy, and only start adding tools to the system if that turns out to be a problem. | 18:26 |
| ignas | jinty: you mean someone was manually merging bundles ? | 18:27 |
| ddaa | The thing with bzr is that, paradoxically, you can have a smaller group of trusted comitters than with svn. | 18:27 |
| ignas | yep | 18:28 |
| ignas | :) | 18:28 |
| ddaa | ignas: I believe for bzr development, there's actually a small group of people who can send merge requests to pqm | 18:28 |
| ignas | hmm | 18:28 |
| ignas | but what about bundles ? | 18:28 |
| ddaa | something like: poolie, lifeless, j-a-meinel, abentley. | 18:28 |
| ignas | i mean you can merge bundle with pqm somehow? | 18:29 |
| jinty | ddaa: I think that's the way things seem to be going, start small, get experience | 18:29 |
| ignas | jinty: only me having access to schooltool trunk would work anyway ;) | 18:29 |
| * jinty actually thinks that might be a good idea;) | 18:29 | |
| ddaa | ignas: I do not think pqm handles bundles itself. Comitters upload a branch with the bundle merged and ask pqm to merge it. | 18:30 |
| ddaa | though bundle support for pqm is definitely a desired feature :) | 18:30 |
| jinty | ok, so for now, I'll make a repository, give ignas access to it and publish it | 18:30 |
| ddaa | okay, and we trust ignas not to mess with the history... | 18:31 |
| ddaa | so we have narrowed down the problem: send one email message for each added or removed revision on a branch... | 18:32 |
| jinty | more than I do myself... | 18:32 |
| jinty | yep | 18:32 |
| jinty | surely this is a common problem... | 18:32 |
| * ddaa looks | 18:32 | |
| ignas | jinty: do you have access to pqm source code? | 18:33 |
| ignas | and is pqm using bzr as a command line tool or as a library | 18:33 |
| jinty | yes, it's public | 18:33 |
| ddaa | not that common, I think. Bzr and launchpad have pre-merge reviews. And I think most other bzr projects are small enough that they have a single maintainer so it's not an issue. | 18:33 |
| ddaa | There's a feature in development for launchpad to send email messages, but I got the impression that you do not want to depend on launchpad for your infrastructure. | 18:34 |
| ignas | ddaa: we have a pre merge reviews now :) | 18:34 |
| ignas | i always review my code | 18:34 |
| ignas | and i would whack anyone who would commit anything significant to trunk without me reviewing it first | 18:34 |
| ddaa | ignas: I mean pre-merge review as a process, with specific supporting tools, etc. | 18:34 |
| jinty | ddaa: I like outsourcing infrastructure... | 18:34 |
| * ddaa looks for relevant plugins | 18:35 | |
| ignas | jinty: can you describe the workflow you want to see when you will complete everything ? | 18:38 |
| ignas | jinty: i think our views on the problem are a bit different and want to realign them ;) | 18:39 |
| jinty | ignas: I thihnk the problem is that we just don't have enough experience with this | 18:39 |
| ignas | hmm, well, how do you imagine it working? | 18:39 |
| jinty | but there are 2 things I want: A mailing list of commit messages to trunk, buildbot to run on the trunk | 18:40 |
| ddaa | actually, it looks like pqm accepts bundles directly | 18:40 |
| jinty | (actually pqm with commits failing on test failure would be cool) | 18:41 |
| jinty | but start small... | 18:41 |
| ignas | ddaa: i don't know how pqm works, so maybe you could enlighten me on - how it "accepts" bundles ? | 18:42 |
| jinty | ok, ignas, you have full shell access now, I've created a group stbaz of which you are the only member | 18:42 |
| jinty | there is writable space at /var/local/baz/schooltool where you can put a repository | 18:43 |
| ddaa | how it accepts bundles, apparently using this plugin: https://launchpad.net/products/bzr-submit | 18:43 |
| ignas | ddaa: any mailing lists i can see pqm in action? | 18:44 |
| ddaa | pqm is a robot that is driven by email messages, those messages are normally generated by bzr plugins, not composed manually | 18:44 |
| ignas | jinty: and the central bzr repository will live in? | 18:44 |
| ignas | /var/somewhere ? | 18:45 |
| jinty | I presume /var/local/baz/schooltool/trunk | 18:45 |
| ddaa | ignas: not that I know, the pqm messages are generally sent privately to the robot. | 18:45 |
| jinty | the whole thing is published here: http://staging.schooltool.org/bzr2/ | 18:45 |
| jinty | bugger.... ignas, wait, I shoudl change baz-> bzr | 18:46 |
| jinty | done | 18:47 |
| jinty | ddaa: do you know where I can get a config-manager that works with the latest pqm? | 18:48 |
| ddaa | ouch | 18:49 |
| * jinty __loves__ non-released, non-packaged software.... | 18:50 | |
| ddaa | The two working instances of pqm I know are setup and operated by lifeless... | 18:50 |
| ignas | hmm, bundle buggy is nice for the trunk control, but doesn't support merges from a branch, and these might get too big to be handled as bundles ... | 18:50 |
| ignas | pqm seems good, but would require personal review requests or something like that for code review to work ... | 18:51 |
| ddaa | it looks like the config-manager package in edgy should work... | 18:52 |
| ddaa | I do not know much more about it... but pqm is not really the friendliest piece of software around. | 18:52 |
| ignas | and i'd *wish* there was a way to register branches for crontab buildbot | 18:52 |
| * ddaa is still looking at email thing on spare cycles | 18:53 | |
| jinty | ddaa: I have already tried that... but don't worry about it, I think pqm is crossing itself off the list of possible solutions | 18:54 |
| ignas | hmm :/ what could we do with shared repositories ... i mean we want all the history available, but without anyone having commit access (system being decentralized) they will get out of date soon | 18:54 |
| ddaa | ignas: what do you mean? | 18:55 |
| jinty | ignas: have you found some bundlebuggy instructions somewhere? | 18:55 |
| ignas | jinty: no, not really, there is no link to the source of it anywhere | 18:55 |
| ignas | ddaa: well, i own the trunk, lyceum branch, new-navigation branch | 18:56 |
| ignas | jfroche has his branch | 18:56 |
| ignas | for the school | 18:56 |
| ignas | CanDo have a branch of their own | 18:56 |
| ignas | what to do with the rest of branches and attic | 18:56 |
| jinty | I think a repository of their own | 18:56 |
| jinty | ah, i see... | 18:56 |
| ignas | and tags | 18:57 |
| ignas | i could adopt them :) | 18:57 |
| ddaa | jinty: is that what you are looking for? http://code.aaronbentley.com/BundleBuggy/ | 18:57 |
| ddaa | (hint, that's a bzr branch) | 18:57 |
| ignas | and put somewhere on schooltool.org (if i have an http accessible place) | 18:57 |
| ddaa | You can just have everybody use a separate repository (possibly on the same host, different logins). | 18:58 |
| ignas | and we'd only have trunk in /var/local | 18:58 |
| ignas | jfroche and other would just download their branches | 18:58 |
| ignas | and reupload them somewhere | 18:58 |
| ddaa | With bzr, a repository is just an optimization. | 18:58 |
| ignas | i know | 18:58 |
| ignas | then i'd move their branches to the attic so they would not confuse people | 18:59 |
| ignas | ddaa: i want to have all the svn history in one place for the historic record at least until the system becomes really distributed | 19:00 |
| ignas | bzr get'able place | 19:00 |
| ignas | so everyone will be developing on their own branch, publishing changes the way they prefer, and I will be keeping an eye on their repositories for changes i would like to see on trunk | 19:02 |
| ignas | and i'll be working with stable and lyceum branch, sometimes merging changes to the trunk | 19:02 |
| jinty | ignas: so every developer should have write access to every branch (except trunk)? | 19:03 |
| ignas | jinty: no | 19:03 |
| ddaa | ignas: I see. What are you missing to get there? | 19:03 |
| ignas | the problem I see is only having trunk commits on the mailing list ... as at the moment i can just review jfroche's code every time he commits | 19:04 |
| ignas | and now i will have to go and checkout his branch | 19:04 |
| ddaa | right | 19:04 |
| ignas | what i want is bzr-web plugin for every repository hosted on personal accounts in schooltool.org | 19:04 |
| ignas | and people who don't have their web space having a way to publish their branches using schooltool's server | 19:05 |
| ddaa | ignas: you mean a server to browse branches, like viewvc? | 19:05 |
| ignas | yes | 19:05 |
| ignas | that would be better than me having to checkout every branch i want to check out for stuff | 19:06 |
| ignas | but still, without mailing list, it would take a lot more effort to write a comment about some particular changeset :/ | 19:06 |
| ignas | now i just reply to a checkin email (branches/schooltool-jfroche) | 19:06 |
| ignas | and now i will have to compose one + paste everything and then comment on it ... | 19:07 |
| ddaa | ignas: I guess if you have email notifications you do not need the browser that much? Or is it something separate, like you find it more convenient to check past changes? | 19:07 |
| ignas | well, mailing list is enough | 19:07 |
| ddaa | ignas: I'm looking at the email thing right now. | 19:07 |
| ignas | but we are planning to have emails on trunk only, what about personal branches ? | 19:08 |
| ddaa | if you have emails that do not depend on post-commit hooks, it's not more difficult to support it for other branches than just for trunk. | 19:08 |
| ignas | you mean? | 19:09 |
| ddaa | I mean, if you have a cronjob that sees what are the new changes on a branch, and sends emails for each of them, it's trivial to make it support many branches. | 19:10 |
| ddaa | You could even put the list of branches in a bzr branches that all trusted developers can write to. | 19:10 |
| ignas | hmm, or just pick up all branches in /home/someone/www/ :) | 19:11 |
| ddaa | unfortunately it seems there's nothing that looks robust for this | 19:11 |
| ddaa | ignas: there's "bzr branches" for this | 19:11 |
| ddaa | it's in bzrtools | 19:11 |
| ignas | or maybe we could register them in launchpad ... | 19:12 |
| ignas | does launchpad give some api for retrieving of all URLs ? | 19:12 |
| ddaa | I think that might end up being simpler, yes :) | 19:12 |
| ddaa | phone | 19:12 |
| ddaa | mh | 19:15 |
| ignas | or launchpad can send emails on commit itself ? | 19:16 |
| ddaa | the email commit message feature is in development | 19:16 |
| ddaa | I'll have a look on the status of the code right now | 19:16 |
| ddaa | so... while bzr vis downloads stuff, let's make the point... | 19:21 |
| ddaa | 1. there is nothing out there to send commit emails from a cron job, there's just the bzr-email plugin that runs as a post-commit hook | 19:24 |
| ddaa | 2. there is the "foreach" plugin that would be a good starting point, but it assumes that the branch history is append-only, which is not robust. | 19:24 |
| ddaa | 3. launchpad does not send emails for commits yet, but thumper (Tim Penhey) is actively working on it | 19:24 |
| ignas | hmm | 19:27 |
| ignas | as for our side ... | 19:27 |
| ignas | we need a way for people to publish their changes, both bzr get'able, and email readable | 19:27 |
| ignas | as code review in schooltool is not just for quality control, it's for tutoring as well | 19:28 |
| ddaa | Launchpad sftp would be nice for this, but since it does not support repositories, uploading new branches is relatively expensive. | 19:29 |
| ddaa | okay, about launchpad | 19:30 |
| ddaa | there's a branch pending review to send emails for changes on branch descriptions and stuff like this | 19:30 |
| ddaa | there's a branch existing for the work to send emails on new commit, but there's no new work on it yet | 19:31 |
| ddaa | I'll check with thumper tomorrow how it's going. Today is a holiday in .nz | 19:31 |
| ignas | i see | 19:31 |
| ddaa | It's already relatively high priority since Ubuntu needs this feature. But the diff in the message is not critical to Ubuntu. | 19:32 |
| ignas | it get's so convoluted when one thinks more about it :/ | 19:32 |
| ignas | the workflow seemed so simple at first :) | 19:32 |
| ddaa | ignas: thank you for noticing :) | 19:32 |
| ddaa | it's definitely simple when you have a small project | 19:33 |
| ddaa | transitioning a large project with a lot of infrastructure to a DVCS is always complicated | 19:33 |
| ddaa | I would be happy to send a few days writing up something to do the email notification stuff you need, but that would have to be after the 14th (on vacation next week). | 19:34 |
| ddaa | Also, I'd need to ask SteveA about it. And I think he'll just suggest to use the Launchpad email notifications that should be up there in one or two months (at most). | 19:35 |
| ignas | well, we must straighten out the push/pull/merge-commit part at first anyway | 19:36 |
| ddaa | (counting the time for tim to write it, review time, and a launchpad release cycle or two before it gets deployed) | 19:36 |
| ignas | hmm | 19:36 |
| ddaa | ignas: I do not want to assume anything to avoid confusion, so what do you mean you must straighten out at first? | 19:40 |
| ignas | well, at the moment i am not sure how will changes get to the trunk | 19:41 |
| ignas | for normal development i will do everything on a local checkout and push it to somewhere on the web time to time | 19:41 |
| ignas | and then i will have to cherry pick revisions and get them to the main trunk | 19:42 |
| ignas | the cherry pick and get to trunk part is hazy ... | 19:42 |
| ddaa | you probably do not want to do cherrypicking for ongoing development | 19:42 |
| ignas | i guess i'll have my own trunk checkout called stable | 19:43 |
| ignas | i'll merge required changes from lyceum branch to the stable branche | 19:43 |
| ignas | and then probably merge or pull everything from the stable to the trunk | 19:43 |
| ignas | ddaa: why's that? | 19:43 |
| ignas | ddaa: or should i just have a branch for every feature and pull/merge everything from it to lyceum and stable ? | 19:44 |
| * ignas is used to darcs | 19:44 | |
| ddaa | darcs tend to give people habits that only work well with darcs | 19:45 |
| ddaa | with bzr (or git, or hg, or monotone...) | 19:45 |
| ddaa | it's much easier to have one branch per outstanding feature/bugfix | 19:45 |
| ignas | makes for a less chaotic development too i guess | 19:46 |
| ddaa | it does requires a bit of discipline, but in the ends it makes it easier to manage | 19:46 |
| ddaa | ignas: one way to think about it | 19:47 |
| ddaa | is to think of a branch as a "versioned patch" | 19:47 |
| ddaa | the actual patch is the change you get when this branch is merged. | 19:48 |
| ignas | side question: bzr merge keeps the track of single commits or only pull does that ? | 19:48 |
| ddaa | <voice race="vorlon" effect="gurglebubble">Yes.</voice> | 19:49 |
| ignas | "D | 19:49 |
| ddaa | in the bzr vis thing | 19:49 |
| ignas | yes | 19:50 |
| ddaa | normally, all circles that appears at the extreme left are mainline revisions | 19:50 |
| ignas | and in log | 19:50 |
| *** Aiste has quit IRC | 19:50 | |
| ddaa | so when you pull, you replace your mainline history by the history of the branch you are pulling from | 19:50 |
| ddaa | When you merge-commit, you append a single revision to the mainline history. | 19:51 |
| ddaa | But all the individual commits that you merged are still recorded. | 19:51 |
| ddaa | And they translate into indented revisions in the log and in bzr vis. | 19:51 |
| ignas | oh | 19:52 |
| *** thisfred has quit IRC | 19:53 | |
| * ddaa watches ignas going lightbulb | 19:53 | |
| *** jfroche has quit IRC | 19:58 | |
| ignas | now how do you take changes from trunk? | 19:58 |
| ignas | i mean - if i do a bugfix on my some-bugfix-branch | 19:59 |
| ignas | then merge-commit it to trunk | 19:59 |
| ignas | and merge-commit it to lyceum-branch | 19:59 |
| ignas | and delete it | 19:59 |
| ignas | how would someone get that bugfix into their personal branch ? | 19:59 |
| ddaa | Most of the time, just by merging trunk. | 20:00 |
| ddaa | Which is something you often to do anyway. | 20:00 |
| ddaa | But you can also reinstate the bugfix branch by "bzr branch -r <something> trunk" | 20:00 |
| ddaa | where <something> can be revid:<revision id> or a dotted revision number | 20:01 |
| ignas | hmm | 20:01 |
| ddaa | you can also _not_ delete the branch in the first place | 20:01 |
| ddaa | it makes it more convenient | 20:02 |
| ddaa | note, you can also do "bzr merge -r <something> trunk" directly | 20:02 |
| ignas | and it will merge only that revision (revision having the patchset of the bugfix) ? | 20:02 |
| ddaa | it will merge the branch whose tip is that revision | 20:03 |
| ddaa | in bzr, merge picks all the ancestry of the merged revision | 20:03 |
| ddaa | you _can_ request "only apply the changed between revision 24 and revision 25", but if revision 24 is not already past of the ancestry, that will not be recorded as a merge | 20:04 |
| ddaa | in other words, bzr does not tracks cherrypicks | 20:04 |
| ignas | i see | 20:04 |
| ddaa | it will eventually | 20:04 |
| ddaa | but it's a serious can of worms to provide useful merging in presence of cherrypicking | 20:05 |
| ddaa | actually, the only thing that does it in a vaguely useful way is darcs merge | 20:05 |
| ignas | exponential can of worms in darcs case ;) | 20:05 |
| ddaa | so bzr focused on being nice and doing the right thing without tracking cherrypicks | 20:06 |
| ignas | i see | 20:06 |
| ddaa | though bzr and launchpad do use cherrypicking | 20:06 |
| ddaa | but only cherrypick into release branches | 20:06 |
| *** ddaa has left #schooltool | 20:07 | |
| ignas | you mean branches no one will merge/pull from | 20:07 |
| *** ddaa has joined #schooltool | 20:07 | |
| ddaa | typically, when a release is made, a new release branch is created | 20:07 |
| ddaa | and it only get changes through cherrypicking | 20:07 |
| ddaa | and it's never merged into anything else | 20:07 |
| ddaa | so the merge-not-being-reliable-anymore problem is not an issue in this case | 20:08 |
| ddaa | ("not reliable" as in "giving tons of conflict", not as as in "corrupting your repository and killing your kittens") | 20:09 |
| ignas | hmm, bundles can contain a patchset not just a patch, yes ? | 20:10 |
| ddaa | actually a bundle is a way to transmit a revision | 20:10 |
| ddaa | It contains the delta from a base revision, and the metadata for one or several new revisions. | 20:11 |
| ddaa | It is applied with "bzr merge" | 20:11 |
| ignas | so if i generate a bandle my-bugfix-branch vs trunk and someone merges it it will be identical to the bzr merge from the branch? | 20:12 |
| ddaa | for some value of identical | 20:12 |
| ddaa | two people merging a bundle will not produce the same revision (because they both commit independently), but bzr will record that they both merged the same thing. | 20:13 |
| ddaa | so knit-merging will work right, etc. | 20:13 |
| ignas | i mean - no information will be lost (the bundle will not become a one huge checkin without traceable history) | 20:13 |
| ddaa | yes, that's the whole points of bzr bundles | 20:14 |
| ddaa | merging a bundle is equivalent to merging the branch it was generated from | 20:14 |
| ddaa | sorry, misread your question | 20:14 |
| ddaa | Sorry for the complicated answer, but I wanted to make it clear that, "yes a bundles contains a patchset" but that it does not help for cherrypicking :) | 20:16 |
| ignas | all bzr development is done through bundles or are you merging from branches too? | 20:16 |
| ddaa | Well... I'm doing any bzr development myself. | 20:17 |
| ddaa | I just complain and j-a-meinel fixes it :) | 20:17 |
| ignas | :) | 20:17 |
| ddaa | I guess they are mostly working through bundles because are a key part of they pre-merge review process. | 20:18 |
| ignas | i see | 20:19 |
| ddaa | The key piece on the launchpad review process | 20:19 |
| ddaa | is a cronscript | 20:19 |
| ddaa | that reads a wiki page | 20:19 |
| ddaa | does merges in sandboxes, and puts the produced diffs online | 20:19 |
| ddaa | so when a branch is pending review, there is a regularly updated diff online of what merging that branch on its target will produce. | 20:20 |
| ddaa | (it is something we want to do directly in launchpad) | 20:20 |
| ddaa | jamesh is the one who runs this stuff. Maybe he could release it if asked. | 20:21 |
| ddaa | There should not be any secret sauce in it. | 20:21 |
| ignas | that works for trunk being pushed to ... | 20:21 |
| ddaa | hu | 20:22 |
| ignas | what we need at the moment is "pulling" | 20:22 |
| ignas | i mean - i am the person who decides what goes to trunk what doesn't | 20:22 |
| * ddaa kicks crazy cuddly kitten outside | 20:23 | |
| ignas | so there is pretty much no incentive for anyone to post their branch for a merge ... except for the review value ... | 20:23 |
| ignas | i am looking at jfroches branch, and if he will add something i think everyone needs i will pull it into trunk | 20:24 |
| ignas | other than that he's on his own | 20:24 |
| ignas | we are developing different products with the same core or something like that ... | 20:24 |
| ddaa | hu | 20:24 |
| ignas | so everyone benefits from the improvement of the core schooltool (trunk) | 20:25 |
| ignas | while a lot of code will only live in branches | 20:25 |
| ignas | so jfroche is developing his branch, and i am developing "core" and lyceum branch | 20:25 |
| ddaa | You are saying there is little incentive for people to partition their work in multiple branches, that can be merged to trunk without dragging project-specific code in. | 20:25 |
| ddaa | Right? | 20:26 |
| ignas | on one hand - there is, on the other hand - there is nothing to stop other developers from accidentally adding things i don't want in trunk | 20:26 |
| ignas | and if they would actively ask me for advice or wait for me to review - it might stall them :/ | 20:27 |
| ddaa | Maybe you can use your leverage to ask people "please put this stuff in a branch based on core". | 20:27 |
| ddaa | it's quite possible to do this post-hoc. | 20:28 |
| ddaa | Actually, if they do it themselves, it will be easier for them to merge trunk after you merged this change. | 20:28 |
| ddaa | Here's how it can go. | 20:28 |
| ddaa | trunk: A->B | 20:29 |
| ddaa | jfroche: A->C->D | 20:29 |
| ddaa | you say "jfroche, please put D in a branch based on trunk" | 20:29 |
| ddaa | phone | 20:31 |
| ignas | hmm, the part i don't like about it is that it requires effort and time on his side | 20:39 |
| ignas | i must rely on him making a nice compact patch for the feature i want in trunk | 20:39 |
| ddaa | so he does | 20:39 |
| ddaa | feature: A->E(cherrpicks D) | 20:39 |
| ddaa | jfroche: A->C->D->F(E) (F introduces no change) | 20:39 |
| ddaa | since he did the pick, and merged it himself, he will not get spurious conflicts when merging trunk that merged E | 20:40 |
| ddaa | Well... | 20:41 |
| ignas | how is "jfroche: A->C->D->F(E) (F introduces no change)" performed ? | 20:41 |
| ignas | i mean everything up to this step could be performed by me (in case i have more time on my hands etc.) | 20:41 |
| ddaa | something like "bzr merge ../E ; bzr revert . ; bzr commit -m 'merged cherripick branch'" (the dot in revert . is important) | 20:41 |
| ddaa | The point of this step is to save him spurious conflicts. | 20:42 |
| ddaa | You could also just cherrypick D into trunk. | 20:42 |
| ddaa | Then when he'll merge trunk, he may or may not have spurious conflicts, but nothing worse than with svn. | 20:42 |
| ignas | well, i could cherry pick into feature branch: | 20:43 |
| ddaa | bzr is not really designed to handle parallel branches with long-lived divergence | 20:43 |
| ignas | so he could get clean conflicts | 20:43 |
| ignas | without potential conflicts from trunk | 20:43 |
| ddaa | right, you could make a feature branch that looks like: 1230: "cherrypick r1234 for jfroche", 1231 "fixups" | 20:44 |
| ddaa | but practically that might not work as well since the cherrypick itself may need additional changes to apply cleanly | 20:45 |
| ddaa | though that would give as much fine grained information as bzr can record | 20:45 |
| ignas | i see | 20:45 |
| ddaa | I'm wondering how you managed the situation with svn... | 20:46 |
| ddaa | it's already quite messy with bzr... | 20:46 |
| ddaa | Is it because the stuff that's site-specific is well segregated is separate files? | 20:46 |
| ignas | yes it is | 20:47 |
| ignas | i just svn merge --r 1234:1236 http://trunk in src/schooltool-lyceum | 20:47 |
| ddaa | oh | 20:47 |
| ignas | and svn merge --revision 1239:1245 http://lyceum in src/schooltool | 20:47 |
| ignas | but it's error prone, loses information, and it is inconvenient for jfroche who might want features from both branches | 20:48 |
| ignas | and would have to very accurately pick only those checkins that he needs | 20:48 |
| ignas | checkins not being grouped in any way | 20:48 |
| ddaa | I see. | 20:49 |
| ignas | with bzr i'll just have a branch for every feature and well merge the required ones into trunk and into lyceum | 20:50 |
| ignas | and jfroche can pick features he needs either directly from branches | 20:50 |
| ignas | or from trunk/lyceum branch with -r | 20:50 |
| ddaa | From my experience, you probably do not want to go all the way to "everything is in branches" | 20:51 |
| ignas | what's the alternative? | 20:52 |
| ddaa | I mean, you should keep a branch that's clearly trunk. | 20:52 |
| ddaa | mesh-merging works well when there's a few branche per person | 20:52 |
| ddaa | so the mesh topology can look like fully-connected network where each node is a person | 20:53 |
| ignas | i see | 20:53 |
| ddaa | but if you have many long-lived feature branches and no clear trunk, it can quickly become hell | 20:54 |
| ddaa | because you'll inevitable get functional and/or textual dependencies between branches | 20:54 |
| ddaa | so... I think there are a couple of good ways to tackle your problem with bzr. | 20:54 |
| ddaa | If I were in your position, I'll try to segregate the project-specific code even further, so each project have a common trunk branch | 20:55 |
| ddaa | so you would effectively push the persistent divergence outside of the problem space | 20:56 |
| ddaa | if that's not possible, but the project-specific code is still well separated, you can have custom merge scripts that always revert the changes made to project specific files. | 20:57 |
| ddaa | The problem with the later is that you get a ping-pong situation, where everytime somebody merges and reverts the uneeded changes, he effectively records a change that says "turns these files into my files". | 20:58 |
| ddaa | so as long as everybody uses the custom merge+revert scripts, it's okay | 20:59 |
| ignas | hmm, some things might be a lot easier to implement in a dirty way (put some small school specific stuff in the core so you would not have to refactor the whole module) | 20:59 |
| ignas | but in the perfect case all lyceum specific things will be in src/lyceum (with schooltool nearby) | 20:59 |
| ignas | same for belgian school | 20:59 |
| ddaa | I'd love to be able to say that bzr can gracefully handle the situation you describe. But unfortunately it cannot... yet. | 21:00 |
| ignas | but with unit tests - changes in lyceum part might have to happen at the same time as changes in the core do | 21:00 |
| ignas | so changes to to core would have to go into a feature branch, and lyceum stuff get fixed on merge from the feature branch ... | 21:01 |
| ddaa | ignas: I think your approach is actually the most practical | 21:01 |
| ddaa | When you move stuff from a project branch into a feature branch, you do lose the information from where it comes. | 21:02 |
| ddaa | but from this point, the changes should flow nicely outwards with not much more conflicts than necessary | 21:03 |
| ddaa | I think I would just have each feature branch be merged on trunk, and recommend people merge trunk. That's also nice for other reasons, like when changes on a branch breaks the functionality on another branch. | 21:04 |
| ddaa | Maintaining an integration branch is a good way to catch, and fix, those problems. | 21:04 |
| ddaa | anything more complicate (like a custom merge+revert script) leads to madness | 21:05 |
| ddaa | ignas: btw, it looks like jelmer has been working on making bzr-svn works well for schooltool | 21:08 |
| ignas | hmm | 21:08 |
| ddaa | maybe it would be a good way to gain experience with bzr before the big switch | 21:09 |
| ignas | but i am afraid bzr-svn will not make the merging part easier :/ | 21:11 |
| ignas | but for getting used to developing features on branches | 21:11 |
| ignas | it should work | 21:11 |
| ddaa | I do not know how well bzr-svn works. | 21:11 |
| ddaa | But I'm afraid that given your problem, anything will suck :( | 21:12 |
| ignas | :D | 21:12 |
| ddaa | though probably in different ways | 21:12 |
| ddaa | darcs will do the correct thing, in cosmological time. | 21:12 |
| ignas | :) | 21:13 |
| ddaa | svn will allow you to pick bits freely, but force you to do all the book-keeping by hand | 21:13 |
| ignas | hmm, does bzr have something like svn externals ? | 21:13 |
| ddaa | not... yet... | 21:13 |
| ddaa | strongly desired feature | 21:13 |
| ddaa | will be in for 1.0 | 21:14 |
| ddaa | needed a lot of deep refactorings | 21:14 |
| ddaa | there has been a lot of activity to deliver this | 21:14 |
| ddaa | folks in #bzr (abently and j-a-meinel in particular) will know the details better | 21:14 |
| ignas | i see | 21:14 |
| ddaa | should be coming soon now (few months) | 21:15 |
| ignas | because one way to solve it would be to move src/lyceum into an external | 21:15 |
| ddaa | well yes | 21:15 |
| ddaa | that's what I meant when I said move project-specific stuff into separate branches | 21:15 |
| ddaa | bzr works well with nested branches, but it does not record them | 21:16 |
| ignas | oh, i misunderstood the segregation bit sorry | 21:16 |
| ddaa | sorry, I was unclear | 21:16 |
| ddaa | the problem is that bzr gives no facility to operate on collections of nested branches like that | 21:17 |
| ddaa | and provides no convenience to track "these two revisions went toghether in the code I used last week" | 21:17 |
| ddaa | in launchpad, we have a tree like this | 21:18 |
| ddaa | with a big launchpad branch | 21:18 |
| ddaa | and many other branches are checked out in launchpad/sourcecode | 21:18 |
| ddaa | since most of the ./sourcecode stuff is third party code | 21:20 |
| ddaa | code there tends to see a lot less activity than launchpad itself | 21:20 |
| ddaa | so the inability to "get all the branches as they were last week" is not a practical problem for us | 21:21 |
| ignas | hmm, i see | 21:22 |
| ddaa | might still work for you... | 21:22 |
| ignas | i think i'll have to try out some scenarios | 21:24 |
| ignas | thanks for all the information | 21:26 |
| ignas | i have to go now | 21:27 |
| ignas | getting late in here :/ | 21:27 |
| jinty | ignas: me too | 21:27 |
| ignas | bye | 21:27 |
| *** ignas has quit IRC | 21:27 | |
| *** jinty has quit IRC | 21:27 | |
| *** alga has quit IRC | 21:31 | |
| *** jfroche has joined #schooltool | 22:03 | |
| *** mortons has joined #schooltool | 22:21 | |
| *** Ninno has joined #schooltool | 22:22 | |
| *** vidasp has quit IRC | 22:27 | |
| *** Ninno has quit IRC | 22:35 | |
| mortons | :) | 22:41 |
| *** karstix has left #schooltool | 23:11 | |
| *** th1a has quit IRC | 23:23 | |
| *** ignas has joined #schooltool | 23:37 | |
| *** ignas has quit IRC | 23:44 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!
