Re: [Telepathy] The telepathy-reviewers mailing list.
On Fri, 25 Mar 2011 at 16:34:29 +, Will Thompson wrote: Are we okay with having a Grand Unified List of Reviewers for all Telepathy components hosted on freedesktop.org, just as commit access is all-or-nothing? I think this is fine; as Sjoerd said elsewhere in the thread, one of the criteria for being a designated reviewer is recognising changes that you're not qualified to review. S ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] The telepathy-reviewers mailing list.
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Sjoerd Simons Sent: Saturday, March 26, 2011 2:32 PM To: Olivier Crête Cc: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] The telepathy-reviewers mailing list. I don't think it's a good idea to have random people review stuff for random modules. Since our modules are relatively small, I think there should be a owner/maintainer for each module so we have a minimum of accountability. Also, the maintainer should always have an overview of the changes to his module, so that he can maintain a good level of consistency Also, some modules (like tp-farsight/farstream) require specialized knowledge so in practice only one or two people could review them anyway. I'm not sure how you get from Will saying that people should use their own judgement to what patches they can review to ``have random people review stuff for random modules''. Note that this is also encoded in the criteria themselves. The Criteria for Reviewers section has the following: They are also expected to show good judgement in whether or not they review a patch at all, or defer to another reviewer. Futhermore it has: They should also be in touch with other reviewers and aware of who are the experts in various areas. The first bit is crucial for a reviewer imho, it basically says ``Know your own limits''. Do note that using this procedure doesn't any way change how things are currently done wrt. reviewing. It's just there to have a more clear definition of when someone gets/can expect a certain status. To come back to the original question, I'm totally fine with having a grand unified list of reviewers and comitters and would very much be against anything else. At some point in time we had a wiki page with a matrix of projects and reviewers, which is just a massive pain to maintain and will never reflect reality. The reality is always that some patches can be reviewed by essentially any comitter and others can be best reviewed by one particular person. That one person can be different for different areas of a project! I support Sjoerd's points. In our team in Nokia, I encourage everybody to use the common mailing list for reviews, with a stated premise that anybody can voice their concerns with any patch. The preferred reviewers are indicated with Cc in the message or personal assignment in ReviewBoard. In practice, people cluster around projects they know well anyway, so the good judgment approach works (except, it's usually me who raises the occasional hell about things people thought were OK :)). Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Massively complicating Folks for greater future
On Mon, 2011-03-28 at 13:58 +0100, Will Thompson wrote: Hi, On 18/11/10 21:03, mikhail.zabal...@nokia.com wrote: I have created a branch on Folks to propose a more scalable API: http://git.collabora.co.uk/?p=user/zabaluev/folks.git;a=shortlog;h=refs/heads/views So, Travis, Philip and myself had a chat on #telepathy on Thursday (from 1810 to 1930 UTC if you have logs; http://people.collabora.co.uk/~wjt/tmp/folks-search-and-filtering is the poorly-formatted log I got from irssi) about this. The ongoing work on exposing information from libsocialweb in Folks has added another case where it's expensive to fetch excess information, and also where it's impossible to keep it up-to-date without polling. We broadly think that Folks needs the following additions and changes: • An API for specifying queries. Mikhail's API proposal (above) look like the right kind of level of simplicity for this: exposing specific implementations of a Query interface for attributes which make sense to query on, like contact ID, phone number, birthdays in the next week, etc.; rather than some kind of maximally-general query language for predicates on contact attributes or something. • Read-only, live-updated views of the results of those queries, as the IndividualList sketch provides; plus… • A way to explicitly tell one of these views to refresh its poll-only data. The latter allows for the case where, for instance, the user knows by some out-of-band means that a contact has changed their phone number, and they want to force a refresh even though the local cache doesn't seem stale. • Specifying interfaces that the application making the query is interested in. Again, Misha's sketch provides this. • Extending the PersonaStore interface to relay all this information to the backends for different sources. (Some backends can disregard most of this information: for views on local stores with change notification, refresh is meaningless, for instance.) • Finally, obviously the backends for libsocialweb and possibly other sources need to be updated to make use of this information. We think that the same human retrieved via two different IndividualLists should be represented by the same object. This means that IndividualLists can return Individuals with more information than was requested up-front, because some other query asked for different information. I don't see this as a problem: if the information's available, there's no extra cost to showing it. Selectively retrieving expensive information should have no impact on auto-linking: I think it's a safe bet that only very static information (like names, email addresses, and so on) is useful for auto-linking. As Travis and I agreed (after you'd left, I think), a reasonable way to do this is to require that backends *always* retrieve the values of properties in their personas which have been defined as linkable (i.e. properties which are listed in Persona.linkable_properties). This guarantees that all the necessary data is always available for linking, so the correct links are always made. Handily enough, the only properties which are listed as linkable at the moment are particularly static ones. Philip Thoughts? signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Video call with GTalk
Do I need to rely on telepathy-stream-engine? Thanks, Cassie 2011/3/28 flower bean beanflowe...@gmail.com Thanks very much for your response. I was create Voice call successfully via call below API: QListTp::MediaStreamType request_types; request_types.append(Tp::MediaStreamTypeAudio); mRetValue = (*mWaiter)( mChannel-requestStreams( aTarget, request_types) ); *but fail to create Video call as below(especially no audio):* request_types.append(Tp::MediaStreamTypeVideo); request_types.append(Tp::MediaStreamTypeAudio); mRetValue = (*mWaiter)( mChannel-requestStreams( aTarget, request_types) ); Channel fully ready, Audio/Video stream created successfully, but there is no audio and video output, what do I need to do else? Thanks in advance! Cassie 2011/3/28 Olivier Crête olivier.cr...@collabora.co.uk On Mon, 2011-03-28 at 10:41 +0800, flower bean wrote: Hello, I use telepathy-qt4 to implement video call with GTalk protocal. I'm not sure if I need to launch camera by myself, if yes, does it use the API org.maemo.Telepathy.StreamEngine.StartCamera()? I have called org.maemo.Telepathy.StreamEngine.AttachToChannel, do I also need to call StartCamera/VideoPreviewSize etc. separatly ? I assume you're on Maemo5 (stream-engine is only for Maemo). You don't have to call StartCamera(), its only there if you want to start the camera before the call actually starts (like the Maemo5 default UI does). VideoOutputSize and VideoPreviewSize are signals that tell the UI what resolution the output/preview is so the UI can put its output window at the right ratio. That said, be careful, I'm not sure how will it will interact with the official UI if you use stream-engine. -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Video call with GTalk
On Tue, 2011-03-29 at 08:53 +0800, flower bean wrote: Do I need to rely on telepathy-stream-engine? No, but them you must re-implement the Gst bits that it has into your own app. -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Video call with GTalk
Is there no API in Telepathy-qt4 for this? I have called : request_types.append(Tp::MediaStreamTypeVideo); request_types.append(Tp::MediaStreamTypeAudio); mRetValue = (*mWaiter)( mChannel-requestStreams( aTarget, request_types) ); Channel fully ready, Audio/Video stream created successfully, but there is no audio and video output. Do I also need to re-implement the Gst bits? Thanks, Cassie 2011/3/29 Olivier Crête olivier.cr...@collabora.co.uk On Tue, 2011-03-29 at 08:53 +0800, flower bean wrote: Do I need to rely on telepathy-stream-engine? No, but them you must re-implement the Gst bits that it has into your own app. -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
