12:00:15 <buxy> #startmeeting
12:00:15 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00:22 <buxy> #topic review of last week
12:01:29 <buxy> mlalic: how did the last week go? looks like you didn't manage to do everything
12:02:24 <mlalic> Yes, quite right. I had to go to Munich for a day to handle some administrative business for an apartment there
12:02:49 <mlalic> So I lost a day there and, to be honest, it made be quite tired
12:04:20 <mlalic> With that in mind, I don't think the week was bad. Two small stories and a larger one are left...
12:04:39 <buxy> OK.
12:04:56 <mlalic> Everything regarding creating and managing the teams through the Web is complete.
12:05:33 <buxy> mlalic: what's up with the mail to exim-users?
12:06:02 <mlalic> So the best feedback, which wasn't to switch to postfix, was to set all mail to be automatically queued
12:06:11 <mlalic> Disregarding the system's average load
12:06:36 <mlalic> and then setting a fix number of queue cleaner tasks which are to be ran in a regular time interval
12:06:52 <mlalic> However, the problem here is that this will affect all incoming mail.
12:08:11 <mlalic> 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 <mlalic> This way the dispatch/process of PTS-specific mails would be entirely controlled by PTS settings...
12:08:58 <mlalic> And the mail delivery would use the same settings as the rest of the mail that exim handles.
12:10:46 <buxy> OK, so no magical solution for now. :)
12:11:12 <mlalic> Nope, unfortunately not.
12:13:01 <buxy> mlalic: did you update pts.debian.net to use packages instead of virtualenv?
12:14:09 <mlalic> Well, python-django-jsonfield is only in testing for the moment, not backports, so I didn't think I should...
12:14:35 <buxy> mlalic: it install fines in wheezy
12:15:08 <buxy> I can make the backport but it will mostly lead to the same package with a different version
12:15:29 <mlalic> 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 <mlalic> 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 <buxy> I said "+ python-django-jsonfield from jessie/wheezy-backports"
12:16:38 <buxy> I'll upload it to wheezy-backports anyway because we will need it for deployment on .debian.org
12:16:53 <buxy> but I didn't expect you to wait for it
12:17:38 <mlalic> Sorry then, I misunderstood.
12:17:51 <buxy> #action mlalic to switch from virtualenv to using system-wide files with real Debian packages
12:18:10 <buxy> during this deployment then
12:18:17 <mlalic> Yes, of course.
12:19:13 <buxy> the news import finished but it has been very, very long
12:19:57 <buxy> #action mlalic to fix news import with fallback to latin1 when email doesn't validate as UTF-8
12:20:04 <buxy> ^this needs to be fixed
12:21:06 <mlalic> Okay.
12:21:45 <buxy> and it would be nice to allow to disable the GPG scanning
12:23:25 <mlalic> 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 <buxy> yes
12:24:22 <buxy> BTW your keyring was not complete enough anyway
12:26:02 <mlalic> So debian-nonupload and emeritus-keyring need to be used too?
12:26:17 <mlalic> 'cause I think I rsync'd the directory before running the update
12:26:32 <buxy> you should have put all the keyrings (including removed, emeritus, etc.) except -nonupload, role keys
12:27:29 <buxy> extra-key is also not needed
12:28:10 <mlalic> Okay. I added emeritus and removed keys immediately
12:29:17 <mlalic> 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 <buxy> both are only relevant to integrate the history, new uploads can't happen via those keys
12:29:30 <mlalic> Plus it's a one off task...
12:29:49 <mlalic> It's a small amount of work either way.
12:29:55 <buxy> Hum?
12:30:22 <mlalic> 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 <buxy> This signature parsing task should not be automated.
12:30:36 <mlalic> The process keeps running for approximately the same amount of time.
12:30:49 <buxy> But it will be useful for others who have expanded/fixed their keyrings...
12:31:29 <mlalic> Right, so the idea is to have a completely separate task which updates the signatures, then.
12:31:30 <buxy> Right, it's ok if that signature parsing takes a long time.
12:32:01 <buxy> updates = fills the missing signatures at least
12:32:15 <buxy> no need to redo what was already done
12:32:38 <mlalic> Okay, understood.
12:34:06 <buxy> #action mlalic to split import news in two tasks = raw import + gpg signature parsing
12:36:15 <buxy> mlalic: have you seen the feedback of themill about the testing excuses being out of date on pts.debian.net ?
12:36:54 <mlalic> Ehm no.
12:37:06 <buxy> mlalic: I sent it to you via gtalk
12:37:19 <mlalic> Oh, damn, let me check.
12:37:33 <buxy> <themill> 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 <buxy> 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 <mlalic> Aaa! Heh, while I was configuring the new deployment I'd disabled the crontab entries and never renabled them again.
12:39:03 <mlalic> Still though, having run_all could be useful
12:41:27 <buxy> yeah, just saw the insane crontab entry you have :)
12:42:47 <buxy> BTW, why is pts_update_repositories not a task like others and why does it need to be executed separately?
12:43:18 <mlalic> 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 <mlalic> 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 <mlalic> Now it can be ran the same way, sure.
12:45:41 <buxy> ok
12:46:25 <buxy> BTW, you can say 0-23/3 and 2-23/3 instead of the list you used in the crontabs :)
12:47:35 <mlalic> Thanks :) I tried something to that effect, but must've made some other (syntax) error because it didn't work.
12:48:20 <buxy> or */3 if you don't care of the precise start hour,
12:48:35 <buxy> (is likely the same as 0-23/3)
12:48:39 <buxy> anyway
12:49:11 <buxy> #action mlalic to implement a "pts_run_all_tasks" management command
12:49:31 <buxy> hopefully it's a short one not work a dedicated card
12:49:38 <buxy> s/work/worth/
12:49:53 <buxy> #topic next week planning
12:49:55 <mlalic> Yeah, it'd have to be <1 :)
12:50:15 <buxy> no surprise here, I'll just add the remaining stories from the backlog
12:51:35 <buxy> it still makes 33 points of stories, so a full week when we hoped it to be a lightweight one
12:52:11 <mlalic> 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 <mlalic> 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 <buxy> and it's the last one so we can't really shift anything
12:53:27 <buxy> 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 <mlalic> I also thought it was merely a suggestion, but a student asked this question directly and this was the answer.
12:53:55 <mlalic> I can forward you the email if you'd like to read it.
12:54:44 <buxy> yes, please
12:55:31 <mlalic> Done.
12:56:17 <buxy> does this work amount looks too much to you? do you think you'll manage it?
12:56:46 <buxy> and then be able to use the 2.5 remaining days for the stuff listed in "Input from mentor" ?
12:58:15 <buxy> I moved 3 of them in the "backlog"
12:58:44 <mlalic> Well, looking at it, it seems like it should be fine.
12:59:47 <mlalic> 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 <buxy> OK, then we will stick with it.
13:01:21 <buxy> #topic name of the PTS
13:01:39 <paultag> panopticon! :)
13:01:44 <buxy> I hate having to choose a name :-)
13:01:45 <paultag> (mostly kidding)
13:02:24 <jcristau> 'bikeshed' is already taken
13:02:35 <mlalic> hehe
13:02:40 <buxy> I believe it's likely we will stick with D(ebian|istribution) <something> Tracker
13:03:09 <jcristau> 'something' can't be 'package'?
13:03:11 <paultag> what does [arch|fedora|rhel|gentoo] call this thing?
13:03:27 <buxy> and go for tracker.debian.org, it's what people are expecting
13:03:38 <mlalic> Yeah, I was following the comments in your blog post. something like distro-tracker for the package name seems okay...
13:04:18 <buxy> 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 <Myon> what's wrong with "pts" if it's a PTS?
13:05:06 <buxy> but we will have teams next week and probably more extensions in the future (like integration of the Patch Tracker)
13:05:35 <buxy> http://raphaelhertzog.com/2013/09/03/finding-a-new-name-for-the-package-tracking-system/
13:05:54 <buxy> if you want to review some of the suggestions/discussions on this question
13:07:44 <buxy> 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 <buxy> one easy way is to replace "distro" by the vendor name but then you get "debian tracker" and it sounds weird
13:09:19 <Myon> there's little wrong with using a well-known name even if that system grows more functionality
13:09:50 <Myon> "tracker.d.o" is too generic and sounds like it's serving web tracking pixels
13:11:01 <mlalic> Myon: I don't associate the word tracker with tracking pixels, tbh.
13:11:08 <buxy> neither do I
13:11:44 <buxy> and that doubt is quickly solved once you have a look at the website
13:12:45 <buxy> 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 <buxy> specific
13:14:59 <buxy> 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 <themill> 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 <buxy> right
13:17:19 <buxy> #topic misc questions
13:17:29 <buxy> mlalic: do you have any remaining questions?
13:18:18 <mlalic> buxy: I don't think so, no. Everything in the iteration's plan has already been discussed so I'm good.
13:19:36 <buxy> good then
13:19:39 <pabs> buxy: tracker.d.o sounds like a bittorrent tracker to me
13:20:30 <buxy> mlalic: thank you for you work, and keep the momentum for the last week and a half
13:21:22 <mlalic> buxy: Yes, I definitely will. Thank you for the constant feedback, as well! :)
13:21:43 <buxy> pabs: or a bug/issues tracker, but I don't have better name suggestions unfortunately
13:22:14 <buxy> pkgtracker would duplicate since URL will be tracker.debian.org/pkg/foo
13:22:20 <mlalic> 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 <buxy> pabs: it would be a pain to mix a Django website in the qa website
13:26:41 <buxy> and I'd rather not tie both services on the same machine
13:27:13 <buxy> #endmeeting