11:56:37 #startmeeting 11:56:37 Meeting started Wed Sep 4 11:56:37 2013 UTC. The chair is buxy. Information about MeetBot at http://wiki.debian.org/MeetBot. 11:56:37 Useful Commands: #action #agreed #help #info #idea #link #topic. 11:56:46 #topic review of last week 11:57:30 how went the last week? 12:01:53 mlalic: ^ 12:05:42 buxy: Sorry for this! Got disconnected for some reason! Here is a copy paste of what I'd said before I realized that... 12:05:49 As you've noticed, the account stories were completed this time around. In the end, I didn't tackle the source dependencies since from your mail, there are many changes which need to be made prior to actually implementing the model (which was the part I had trouble last week) 12:05:55 For example, extending the update repositories task to have hooks 12:06:00 To work with everything in memory and commit it in the end... 12:06:03 Parent repositories for Repository model 12:06:06 The story is no longer simply about dependencies at this point and seems like all this should be separate stories to work on. 12:07:06 Well, I think it's a better end-situation and that we should do it at some point. I don't think it's required right now. We could just squeeze this task in the current task. 12:07:25 Do you agree with this? 12:08:42 So you're saying squeeze it in even though it's not required right now? 12:08:43 I don't mind doing the refactoring right now but I bet you will evaluate it as a rather big task and I'm not sure I want to prioritize that. On the contrary, I want to finish the accounts + teams stories. 12:09:20 Hum. I'm not sure I understand. 12:09:50 "We could just squeeze this task in the current task." -> Work on the refactoring? 12:10:03 I mean that generating the source-to-source dependencies could be made within pts_update_repositories instead of something separate with with hooks and everything. 12:10:16 Ah right 12:10:41 I'd like to have the feature but not tie it to a proper immediate refactoring. 12:10:58 Yeah, that is what I think is better for now as well. The refactoring, while definitely useful, is quite a large undertaking here 12:11:12 But then the problem becomes that there are no parent repositories for instance 12:12:12 Leading again to a situation where we have a repository which lacks all binary packages to detect the dependencies 12:13:04 I suggest we only take into account the "default repository" in the first pass. 12:13:46 and we assume this one to be complete 12:14:50 Right! That sounds good. In this case, the code that I've already pushed only needs a minor modification to use only the default repository (it is using all repos right now) and to create the model based on the discovered dependencies 12:14:56 Given all this, what would be the new estimation to finish "WNPP derived information" 12:14:59 ? 12:16:02 Updated the card. 12:19:07 Thanks. 12:20:16 mlalic: did you do all the points listed as action items last week? 12:20:22 fwiw, /me looking at tastypie for RDF + REST 12:21:14 buxy: The only thing I didn't do is update the exim setting to match Debian's 12:21:30 Kind of slipped my mind. 12:23:06 OK, let's do it then. I want to know if it would be safe to use it as is on debian.org. 12:23:15 But there, it's done now! 12:23:16 :) 12:23:37 mlalic: can you give me the link of your mail on exim-users ? 12:25:52 Ehm... I can't find it in the archive :-o 12:26:25 Was it dropped because you didn't subscribe maybe? 12:26:45 No, I subscribed first 12:27:20 I think it probably takes some time for the message to appear in the online interface though 12:27:30 I wrote it last night and sent earlier this morning. 12:27:42 I can forward you the email itself? 12:28:04 yes, please 12:28:56 #action mlalic to ensure his mail to exim-users goes trough and to make a summary of the answers 12:29:35 mlalic: has there been no deployment this week? 12:30:29 Oh wow! I seriously can't believe I forgot about that... 12:31:08 I'm so sorry... I think I even wrote in the weekly report that it was deployed 12:31:31 BTW, I don't know if I told you but someone from Tanglu asked me about the opportunity to deploy the rewritten PTS for them 12:32:02 No big deal, last week didn't have much new stuff. 12:32:10 No, you didn't. It's excellent news :) 12:32:34 Yeah, true, but still kind of embarrassed about it. 12:32:54 I suggested them to wait for a while still because I believe that we have to do some model refactoring and that we should start using south. 12:33:17 ok, let's close the review, first 12:33:39 mlalic: anything else worth saying about the last week? 12:34:31 I've started working on extracting the generic accounts app yesterday. It's looking good so it should be done quite soon as well 12:34:58 Other than that, it was a nice week: I really like that fact that we have a completely new feature to show case this week 12:35:02 mlalic: can you add estimations to the last 3 stories (Import old PTS data)? 12:35:03 Which is already useful 12:36:34 I'd like to see how we will manage the last 2 weeks. 12:37:38 I'm on it... 12:39:43 Is it dump-tags.pl that gives a list of keywords associated to user subscriptions? 12:39:54 mlalic: yes 12:40:45 basically it's foo@example.com#package => bts,bts-control,… 12:41:02 holy crap: rdflib too old in Debian.... (again)... virtualenv is my friend 12:41:38 and foo@example.com (without any hashtag) for user's default keywords 12:41:47 Also, don't we already have a the management command to export package subscribers? 12:41:54 pts_dump_subscribers 12:42:07 yes we have 12:42:16 So the only difference is the output format, it seems? 12:42:23 not even... 12:42:36 the output is the same than the old no? 12:42:45 (except if we use --json) 12:43:00 package => [email1 email2] 12:43:26 (Which is what dump.pl was doing IIRC) 12:43:42 buxy, mlalic: ping me when you're available to discuss tastypie 12:43:48 if/when 12:44:02 mlalic: ah, yes the format is slightly different 12:44:07 obergix[work]: sure... 12:44:35 Anyway, the necessary work is minimal there 12:44:40 I don't even wanna call it [1] 12:45:40 A --udd-format switch for the existing command is enough 12:45:47 yes 12:46:16 #topic next week planning 12:47:36 so basically my plan is to work for 2 weeks to finish the important features and then use teh remaining 2-3 days for some refactoring/janitorial tasks 12:48:27 Sounds good 12:48:39 mlalic: have you seen what I have put in "Input from mentor"? it's basically what I believe needs to be done before we can safely deploy and offer some upgrade paths in the future 12:48:50 Yes 12:49:22 In order: Indexes; AFAIK, indexes are automatically created for any unique=True field 12:49:47 so the example of package names you gave already has them 12:50:00 None the less, I'll check what else may use one. 12:50:34 Email model: Would it be okay if all the PTS models referenced the custom User model's Email model. It seems unnecessary to duplicate this 12:51:05 mlalic: I don't think this is the case 12:51:14 at least ./manage.py sqlindexes core doesn't list them 12:52:01 mlalic: exactly, that would be my suggestion as well, rely on the Email model from pts.accounts 12:52:45 you might need another model with a OneToOne relationship for storing default keywords and the like though 12:53:26 buxy: I just checked directly in postgres, and the indexes are definitely there 12:53:29 e.g. core_actionitemtype_type_name_key 12:53:45 core_binarypackagename_pkey, etc. 12:54:02 Okay, that last one is because it's a primary key 12:54:50 but this: core_packagename_name_key -- index for the name field... 12:55:09 I think the management command only searches for fields which have been explicitly marked with db_index=True 12:56:26 OK, still you might want to index pair of fields in some cases 12:57:18 Next up PackageName: The reason BinaryPackageName is separated from the other ones is that a binary package can share a name with a source package. I wanted to keep the unique constraint on the name field (instead of (name, package_type) for instance). 12:57:38 Now that I think of it, I don't know what that gained really :) 12:58:51 Neither do I. I believe that we should get rid of it and just use booleans to know whether the package exists as a binary, a source or a pseudo-package 12:59:55 well, maybe the package type field is better than a boolean for each type 13:00:04 (there are also subscription-only packages) 13:01:08 subscription-only is just a package name where all the booleans are False 13:01:44 Hehe, right. :-) 13:02:01 South: there hasn't been a feature yet that required more than syncdb to deploy. With the upcoming changes to use a single email model though, it'll be necessary 13:03:40 I'm not familiar enough with South to know what kind of operations can be done to automate such difficult upgrades but we don't have any big deployment yet, so don't bother writing custom upgrade code to handle this. 13:04:11 Right 13:04:38 I'd rather spend that time to review the models and ensure they are sane for the future. Feel free to come up with suggestions of your own as well. 13:07:03 Something that has been on my mind for a while is the MailingList model. It was supposed to represent a "known mailing list" so that their links can be added to the package page. Perhaps this would work better as one of the plugin mechanisms, instead of a model though... 13:07:48 mlalic: why are you saying this? 13:09:44 I feel as if it maybe isn't flexible enough. Right now, it assumes that there is a placeholder for the local part of the email somewhere in a field called archive_url_template 13:09:59 Maybe there would need to be additional processing of the email before rendering the URL for some lists. 13:10:14 And also since it really looks similar to the VCS model we kicked out 13:10:22 How often do known mailing lists really change? 13:10:43 Not often. 13:11:35 It should still be easy for derivatives to add support for their own mailing list domains without writing code. As long as we offer something via the settings, I'm OK getting rid of that. 13:13:06 Yeah, a setting which works exactly as the model does now (a template of the URL with a place holder for the local-part) should be good. Optionally, a callable could be provided in which case it would get the user directly and a URL should be produced 13:13:51 Anyway, this does not affect other models in any way, so it's probably less important, but it's kind of been bugging me 13:14:42 So I have put 30 points of stories in this week. This includes the whole team feature and I have left the remaining accounts stories for the last week. 13:15:22 I have put a fake card to show in the backlog delimiting the remaining stories that I want to see done. 13:15:34 s/to show// 13:16:34 I think it looks reasonable 13:17:01 That's only 20 points of stories for the last week but that leaves plenty of time for the cleanup/janitorial tasks. 13:18:07 mlalic: I would like you to implement the "Import old news" first and deploy just after having done this story 13:18:45 somehow we need to handle duplicates 13:18:54 Should I drop the news generated so far by the deployment? 13:19:09 Right, that's a no then :) 13:19:26 I think we should 13:19:47 Okay, why would there be duplicates then? 13:20:49 well, it needs to not crash in case of duplicates 13:21:29 we won't be able to perfectly synchronize the "rsync" of the files and the drop in the database 13:22:15 I see no reason that it would. The title of the news model does not have a unique constraint on it 13:24:01 mlalic: anyway, when you plan to deploy, get in touch with me, I'll do a last rsync of the files, you'll drop the news in the database, and then you'll run your script 13:24:20 Sure 13:28:08 #agreed mlalic deploys after having done "Import old news" story and coordinates with buxy to update the news files rsynced from packages.qa.debian.org 13:28:35 #topic misc questions 13:28:50 mlalic: do you have remaining questions? 13:29:28 I've got one about the GUI for the upcoming teams story. Do you have an idea where the "Create team" button should be placed? 13:29:48 Simply another option/tab in the user profile is the best I could come up with 13:35:30 mlalic: on the page listing all the teams? 13:36:15 #action mlalic to switch from virtualenv to using system-wide files with real Debian packages 13:36:34 That is a related questions, where is the link for this page to be found. The best I could come up for that one is a link in the front page, below the current "Jump to package" form 13:37:33 mlalic: ^ that's a point I forgot to tell, I want to ensure things work well with using official wheezy debian packages (+ python-django-jsonfield from jessie/wheezy-backports) 13:37:44 mlalic: yeah, front page should be fine 13:39:23 And Django from backports as well? 13:39:41 I'd like to redesign the header and use some bar (like the one you get when you're logged in in wordpress) 13:39:50 mlalic: yes 13:40:20 but that's something for later I guess (too many ideas of improvements) 13:41:51 Yeah, of course, I think it's best to always have something to improve upon. I don't think there can be a "perfect" application :) 13:42:20 Hopefully the rewrite will allow such changes to be implemented though! 13:44:08 obergix[work]: if you high level questions (i.e. not deeply technical), you can ask them now, otherwise I'll close the meeting and you'll be free to chat with marko and me 13:44:19 +have 13:50:16 #endmeeting