11:56:37 <buxy> #startmeeting
11:56:37 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:56:46 <buxy> #topic review of last week
11:57:30 <buxy> how went the last week?
12:01:53 <buxy> mlalic: ^
12:05:42 <mlalic> 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 <mlalic> 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 <mlalic> For example, extending the update repositories task to have hooks
12:06:00 <mlalic> To work with everything in memory and commit it in the end...
12:06:03 <mlalic> Parent repositories for Repository model
12:06:06 <mlalic> 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 <buxy> 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 <buxy> Do you agree with this?
12:08:42 <mlalic> So you're saying squeeze it in even though it's not required right now?
12:08:43 <buxy> 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 <buxy> Hum. I'm not sure I understand.
12:09:50 <mlalic> "We could just squeeze this task in the current task." -> Work on the refactoring?
12:10:03 <buxy> 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 <mlalic> Ah right
12:10:41 <buxy> I'd like to have the feature but not tie it to a proper immediate refactoring.
12:10:58 <mlalic> 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 <mlalic> But then the problem becomes that there are no parent repositories for instance
12:12:12 <mlalic> Leading again to a situation where we have a repository which lacks all binary packages to detect the dependencies
12:13:04 <buxy> I suggest we only take into account the "default repository" in the first pass.
12:13:46 <buxy> and we assume this one to be complete
12:14:50 <mlalic> 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 <buxy> Given all this, what would be the new estimation to finish "WNPP derived information"
12:14:59 <buxy> ?
12:16:02 <mlalic> Updated the card.
12:19:07 <buxy> Thanks.
12:20:16 <buxy> mlalic: did you do all the points listed as action items last week?
12:20:22 <obergix[work]> fwiw, /me looking at tastypie for RDF + REST
12:21:14 <mlalic> buxy: The only thing I didn't do is update the exim setting to match Debian's
12:21:30 <mlalic> Kind of slipped my mind.
12:23:06 <buxy> 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 <mlalic> But there, it's done now!
12:23:16 <mlalic> :)
12:23:37 <buxy> mlalic: can you give me the link of your mail on exim-users ?
12:25:52 <mlalic> Ehm... I can't find it in the archive :-o
12:26:25 <buxy> Was it dropped because you didn't subscribe maybe?
12:26:45 <mlalic> No, I subscribed first
12:27:20 <mlalic> I think it probably takes some time for the message to appear in the online interface though
12:27:30 <mlalic> I wrote it last night and sent earlier this morning.
12:27:42 <mlalic> I can forward you the email itself?
12:28:04 <buxy> yes, please
12:28:56 <buxy> #action mlalic to ensure his mail to exim-users goes trough and to make a summary of the answers
12:29:35 <buxy> mlalic: has there been no deployment this week?
12:30:29 <mlalic> Oh wow! I seriously can't believe I forgot about that...
12:31:08 <mlalic> I'm so sorry... I think I even wrote in the weekly report that it was deployed
12:31:31 <buxy> 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 <buxy> No big deal, last week didn't have much new stuff.
12:32:10 <mlalic> No, you didn't. It's excellent news :)
12:32:34 <mlalic> Yeah, true, but still kind of embarrassed about it.
12:32:54 <buxy> 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 <buxy> ok, let's close the review, first
12:33:39 <buxy> mlalic: anything else worth saying about the last week?
12:34:31 <mlalic> 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 <mlalic> 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 <buxy> mlalic: can you add estimations to the last 3 stories (Import old PTS data)?
12:35:03 <mlalic> Which is already useful
12:36:34 <buxy> I'd like to see how we will manage the last 2 weeks.
12:37:38 <mlalic> I'm on it...
12:39:43 <mlalic> Is it dump-tags.pl that gives a list of keywords associated to user subscriptions?
12:39:54 <buxy> mlalic: yes
12:40:45 <buxy> basically it's foo@example.com#package => bts,bts-control,…
12:41:02 <obergix[work]> holy crap: rdflib too old in Debian.... (again)... virtualenv is my friend
12:41:38 <buxy> and foo@example.com (without any hashtag) for user's default keywords
12:41:47 <mlalic> Also, don't we already have a the management command to export package subscribers?
12:41:54 <mlalic> pts_dump_subscribers
12:42:07 <buxy> yes we have
12:42:16 <mlalic> So the only difference is the output format, it seems?
12:42:23 <buxy> not even...
12:42:36 <buxy> the output is the same than the old no?
12:42:45 <buxy> (except if we use --json)
12:43:00 <mlalic> package => [email1 email2]
12:43:26 <mlalic> (Which is what dump.pl was doing IIRC)
12:43:42 <obergix[work]> buxy, mlalic: ping me when you're available to discuss tastypie
12:43:48 <obergix[work]> if/when
12:44:02 <buxy> mlalic: ah, yes the format is slightly different
12:44:07 <mlalic> obergix[work]: sure...
12:44:35 <mlalic> Anyway, the necessary work is minimal there
12:44:40 <mlalic> I don't even wanna call it [1]
12:45:40 <mlalic> A --udd-format switch for the existing command is enough
12:45:47 <buxy> yes
12:46:16 <buxy> #topic next week planning
12:47:36 <buxy> 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 <mlalic> Sounds good
12:48:39 <buxy> 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 <mlalic> Yes
12:49:22 <mlalic> In order: Indexes; AFAIK, indexes are automatically created for any unique=True field
12:49:47 <mlalic> so the example of package names you gave already has them
12:50:00 <mlalic> None the less, I'll check what else may use one.
12:50:34 <mlalic> 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 <buxy> mlalic: I don't think this is the case
12:51:14 <buxy> at least ./manage.py sqlindexes core doesn't list them
12:52:01 <buxy> mlalic: exactly, that would be my suggestion as well, rely on the Email model from pts.accounts
12:52:45 <buxy> you might need another model with a OneToOne relationship for storing default keywords and the like though
12:53:26 <mlalic> buxy: I just checked directly in postgres, and the indexes are definitely there
12:53:29 <mlalic> e.g. core_actionitemtype_type_name_key
12:53:45 <mlalic> core_binarypackagename_pkey, etc.
12:54:02 <mlalic> Okay, that last one is because it's a primary key
12:54:50 <mlalic> but this: core_packagename_name_key -- index for the name field...
12:55:09 <mlalic> I think the management command only searches for fields which have been explicitly marked with db_index=True
12:56:26 <buxy> OK, still you might want to index pair of fields in some cases
12:57:18 <mlalic> 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 <mlalic> Now that I think of it, I don't know what that gained really :)
12:58:51 <buxy> 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 <mlalic> well, maybe the package type field is better than a boolean for each type
13:00:04 <mlalic> (there are also subscription-only packages)
13:01:08 <buxy> subscription-only is just a package name where all the booleans are False
13:01:44 <mlalic> Hehe, right. :-)
13:02:01 <mlalic> 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 <buxy> 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 <mlalic> Right
13:04:38 <buxy> 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 <mlalic> 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 <buxy> mlalic: why are you saying this?
13:09:44 <mlalic> 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 <mlalic> Maybe there would need to be additional processing of the email before rendering the URL for some lists.
13:10:14 <mlalic> And also since it really looks similar to the VCS model we kicked out
13:10:22 <mlalic> How often do known mailing lists really change?
13:10:43 <buxy> Not often.
13:11:35 <buxy> 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 <mlalic> 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 <mlalic> 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 <buxy> 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 <buxy> I have put a fake card to show in the backlog delimiting the remaining stories that I want to see done.
13:15:34 <buxy> s/to show//
13:16:34 <mlalic> I think it looks reasonable
13:17:01 <buxy> 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 <buxy> mlalic: I would like you to implement the "Import old news" first and deploy just after having done this story
13:18:45 <buxy> somehow we need to handle duplicates
13:18:54 <mlalic> Should I drop the news generated so far by the deployment?
13:19:09 <mlalic> Right, that's a no then :)
13:19:26 <buxy> I think we should
13:19:47 <mlalic> Okay, why would there be duplicates then?
13:20:49 <buxy> well, it needs to not crash in case of duplicates
13:21:29 <buxy> we won't be able to perfectly synchronize the "rsync" of the files and the drop in the database
13:22:15 <mlalic> I see no reason that it would. The title of the news model does not have a unique constraint on it
13:24:01 <buxy> 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 <mlalic> Sure
13:28:08 <buxy> #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 <buxy> #topic misc questions
13:28:50 <buxy> mlalic: do you have remaining questions?
13:29:28 <mlalic> 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 <mlalic> Simply another option/tab in the user profile is the best I could come up with
13:35:30 <buxy> mlalic: on the page listing all the teams?
13:36:15 <buxy> #action mlalic to switch from virtualenv to using system-wide files with real Debian packages
13:36:34 <mlalic> 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 <buxy> 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 <buxy> mlalic: yeah, front page should be fine
13:39:23 <mlalic> And Django from backports as well?
13:39:41 <buxy> 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 <buxy> mlalic: yes
13:40:20 <buxy> but that's something for later I guess (too many ideas of improvements)
13:41:51 <mlalic> 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 <mlalic> Hopefully the rewrite will allow such changes to be implemented though!
13:44:08 <buxy> 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 <buxy> +have
13:50:16 <buxy> #endmeeting