12:00:15 #startmeeting 12:00:15 Meeting started Wed Sep 11 12:00:15 2013 UTC. The chair is buxy. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:00:15 Useful Commands: #action #agreed #help #info #idea #link #topic. 12:00:22 #topic review of last week 12:01:29 mlalic: how did the last week go? looks like you didn't manage to do everything 12:02:24 Yes, quite right. I had to go to Munich for a day to handle some administrative business for an apartment there 12:02:49 So I lost a day there and, to be honest, it made be quite tired 12:04:20 With that in mind, I don't think the week was bad. Two small stories and a larger one are left... 12:04:39 OK. 12:04:56 Everything regarding creating and managing the teams through the Web is complete. 12:05:33 mlalic: what's up with the mail to exim-users? 12:06:02 So the best feedback, which wasn't to switch to postfix, was to set all mail to be automatically queued 12:06:11 Disregarding the system's average load 12:06:36 and then setting a fix number of queue cleaner tasks which are to be ran in a regular time interval 12:06:52 However, the problem here is that this will affect all incoming mail. 12:08:11 They also suggested the approach we mentioned where the application itself would have a number of mail consumer processes which retrieve mails from a spool 12:08:41 This way the dispatch/process of PTS-specific mails would be entirely controlled by PTS settings... 12:08:58 And the mail delivery would use the same settings as the rest of the mail that exim handles. 12:10:46 OK, so no magical solution for now. :) 12:11:12 Nope, unfortunately not. 12:13:01 mlalic: did you update pts.debian.net to use packages instead of virtualenv? 12:14:09 Well, python-django-jsonfield is only in testing for the moment, not backports, so I didn't think I should... 12:14:35 mlalic: it install fines in wheezy 12:15:08 I can make the backport but it will mostly lead to the same package with a different version 12:15:29 Ehm, right... Well it's just that you said last time that I should install it from bpo, so I went thought it meant that I should wait 'till it was in the repository. 12:16:03 Yeah, I'll do it for this deployment in that case. No need for extra work if everything is fine when using it from testing. 12:16:10 I said "+ python-django-jsonfield from jessie/wheezy-backports" 12:16:38 I'll upload it to wheezy-backports anyway because we will need it for deployment on .debian.org 12:16:53 but I didn't expect you to wait for it 12:17:38 Sorry then, I misunderstood. 12:17:51 #action mlalic to switch from virtualenv to using system-wide files with real Debian packages 12:18:10 during this deployment then 12:18:17 Yes, of course. 12:19:13 the news import finished but it has been very, very long 12:19:57 #action mlalic to fix news import with fallback to latin1 when email doesn't validate as UTF-8 12:20:04 ^this needs to be fixed 12:21:06 Okay. 12:21:45 and it would be nice to allow to disable the GPG scanning 12:23:25 Yeah, I could do that. Retroactively adding them has the chance to process a few already processed news though. But that shouldn't be too big of an issue 12:23:59 yes 12:24:22 BTW your keyring was not complete enough anyway 12:26:02 So debian-nonupload and emeritus-keyring need to be used too? 12:26:17 'cause I think I rsync'd the directory before running the update 12:26:32 you should have put all the keyrings (including removed, emeritus, etc.) except -nonupload, role keys 12:27:29 extra-key is also not needed 12:28:10 Okay. I added emeritus and removed keys immediately 12:29:17 Btw, I'm wondering if the benefit to having this two-phase import process is that great, since the background task will keep running to validate the signatures. 12:29:21 both are only relevant to integrate the history, new uploads can't happen via those keys 12:29:30 Plus it's a one off task... 12:29:49 It's a small amount of work either way. 12:29:55 Hum? 12:30:22 Well, the benefit to doing it in two phases is that all news are imported quicker and thus appear in the package pages without the signature data. 12:30:30 This signature parsing task should not be automated. 12:30:36 The process keeps running for approximately the same amount of time. 12:30:49 But it will be useful for others who have expanded/fixed their keyrings... 12:31:29 Right, so the idea is to have a completely separate task which updates the signatures, then. 12:31:30 Right, it's ok if that signature parsing takes a long time. 12:32:01 updates = fills the missing signatures at least 12:32:15 no need to redo what was already done 12:32:38 Okay, understood. 12:34:06 #action mlalic to split import news in two tasks = raw import + gpg signature parsing 12:36:15 mlalic: have you seen the feedback of themill about the testing excuses being out of date on pts.debian.net ? 12:36:54 Ehm no. 12:37:06 mlalic: I sent it to you via gtalk 12:37:19 Oh, damn, let me check. 12:37:33 buxy: is pts.d.n not updating migration info correctly? It says «Too young, only 7 of 10 days old» when the package migrated two days ago. http://pts.debian.net/pkg/rosegarden 12:37:48 I guess we're not running all the tasks that should be run... i.e. we need run_all_tasks since not all tasks depend on event from pts_update_repositories 12:38:17 Aaa! Heh, while I was configuring the new deployment I'd disabled the crontab entries and never renabled them again. 12:39:03 Still though, having run_all could be useful 12:41:27 yeah, just saw the insane crontab entry you have :) 12:42:47 BTW, why is pts_update_repositories not a task like others and why does it need to be executed separately? 12:43:18 Well, there's cons to just doing run_all, to be honest. Maybe a group of tasks would have a specific time when the users know they would have something useful to do, so they'd want to run them separately. 12:43:41 It's simply a remnant of the fact that back when that task was implemented, there were no others and no pts_run_task management command. 12:43:56 Now it can be ran the same way, sure. 12:45:41 ok 12:46:25 BTW, you can say 0-23/3 and 2-23/3 instead of the list you used in the crontabs :) 12:47:35 Thanks :) I tried something to that effect, but must've made some other (syntax) error because it didn't work. 12:48:20 or */3 if you don't care of the precise start hour, 12:48:35 (is likely the same as 0-23/3) 12:48:39 anyway 12:49:11 #action mlalic to implement a "pts_run_all_tasks" management command 12:49:31 hopefully it's a short one not work a dedicated card 12:49:38 s/work/worth/ 12:49:53 #topic next week planning 12:49:55 Yeah, it'd have to be <1 :) 12:50:15 no surprise here, I'll just add the remaining stories from the backlog 12:51:35 it still makes 33 points of stories, so a full week when we hoped it to be a lightweight one 12:52:11 Indeed. Btw, there was a notification in the students' GSoC list that any contributions to the project after the 16th which are allowed to be submitted in the end must be related only to the documentation. 12:52:41 I'm not sure why they are treating docs as an afterthought, but anyway, I don't think it makes any difference for us. We can simply submit only the code which was done on the 16th? 12:52:54 and it's the last one so we can't really shift anything 12:53:27 mlalic: I haven't seen this on my side... although it has been suggested to use the last week for that kind of work. 12:53:46 I also thought it was merely a suggestion, but a student asked this question directly and this was the answer. 12:53:55 I can forward you the email if you'd like to read it. 12:54:44 yes, please 12:55:31 Done. 12:56:17 does this work amount looks too much to you? do you think you'll manage it? 12:56:46 and then be able to use the 2.5 remaining days for the stuff listed in "Input from mentor" ? 12:58:15 I moved 3 of them in the "backlog" 12:58:44 Well, looking at it, it seems like it should be fine. 12:59:47 I mean, our system's worked fairly well throughout the summer, so I think this week hopefully shouldn't be an exception. :) 13:00:09 OK, then we will stick with it. 13:01:21 #topic name of the PTS 13:01:39 panopticon! :) 13:01:44 I hate having to choose a name :-) 13:01:45 (mostly kidding) 13:02:24 'bikeshed' is already taken 13:02:35 hehe 13:02:40 I believe it's likely we will stick with D(ebian|istribution) Tracker 13:03:09 'something' can't be 'package'? 13:03:11 what does [arch|fedora|rhel|gentoo] call this thing? 13:03:27 and go for tracker.debian.org, it's what people are expecting 13:03:38 Yeah, I was following the comments in your blog post. something like distro-tracker for the package name seems okay... 13:04:18 jcristau: I'd rather not because it's going to track more than that, even though most of it centers around packages and packaging 13:04:23 what's wrong with "pts" if it's a PTS? 13:05:06 but we will have teams next week and probably more extensions in the future (like integration of the Patch Tracker) 13:05:35 http://raphaelhertzog.com/2013/09/03/finding-a-new-name-for-the-package-tracking-system/ 13:05:54 if you want to review some of the suggestions/discussions on this question 13:07:44 distro-tracker looks fine for the package name indeede and for the software name, but the "instances" of it should probably be referred to as something else 13:08:38 one easy way is to replace "distro" by the vendor name but then you get "debian tracker" and it sounds weird 13:09:19 there's little wrong with using a well-known name even if that system grows more functionality 13:09:50 "tracker.d.o" is too generic and sounds like it's serving web tracking pixels 13:11:01 Myon: I don't associate the word tracker with tracking pixels, tbh. 13:11:08 neither do I 13:11:44 and that doubt is quickly solved once you have a look at the website 13:12:45 Myon: most names are too generic, it's difficult to have something short/handy/easy to remember and at the same time very specifiy 13:13:05 specific 13:14:59 I'd rather lean towards too-generic than too-specific in this case (as long as we don't introduce confusion in most people's head) 13:15:36 I don't think anyone really cares much what it is called as long as it's not too long to type and existing URLs keep working 13:16:56 right 13:17:19 #topic misc questions 13:17:29 mlalic: do you have any remaining questions? 13:18:18 buxy: I don't think so, no. Everything in the iteration's plan has already been discussed so I'm good. 13:19:36 good then 13:19:39 buxy: tracker.d.o sounds like a bittorrent tracker to me 13:20:30 mlalic: thank you for you work, and keep the momentum for the last week and a half 13:21:22 buxy: Yes, I definitely will. Thank you for the constant feedback, as well! :) 13:21:43 pabs: or a bug/issues tracker, but I don't have better name suggestions unfortunately 13:22:14 pkgtracker would duplicate since URL will be tracker.debian.org/pkg/foo 13:22:20 pabs: Okay, that I can see more than the tracking pixel... Even though to me, it does seem kind of weird for that to be the primary interpretation in the debian.org domain. 13:24:51 * pabs figures qa.d.o/source/foo qa.d.o/team/foo@bar.com 13:26:18 pabs: it would be a pain to mix a Django website in the qa website 13:26:41 and I'd rather not tie both services on the same machine 13:27:13 #endmeeting