[SailfishDevel] Sailfish OS Open Source Community Collaboration Meeting 2nd of June 2016
Alexey Andreyev
yetanotherandreyev at gmail.com
Fri Jun 3 09:22:12 UTC 2016
Peter Kovacs, feel free to ping me in case of anything. It's just a hobby
for me right now, but I'm interested in this too.
2016-06-03 11:53 GMT+03:00 Peter Kovacs <leginee at gmail.com>:
> Cool thanks. Will take a look on the weekend. Thanks for the discussion.
>
> Alexey Andreyev <yetanotherandreyev at gmail.com> schrieb am Fr., 3. Juni
> 2016, 10:12:
>
>> Tone Kastlunger, +1 :)
>>
>> Peter Kovacs, please, take a look at tracker implementation:
>> https://github.com/GNOME/tracker
>> It uses semantic nosql techniques to handle the user data (RDF
>> ontologies).
>> it's focusing on low memory footprint ("Tracker is designed and built to
>> run well on mobile and desktop systems with lower memory (256MB or less)"),
>> and it is "built around a combination indexer and SQLite database",
>> but you can execute sparql queries here.
>> So, if you want a graph connections: they are already there. We just have
>> to create an apropriate clients.
>>
>> If you are interested in some other triplestore implementations, also
>> take a look at redland rdf libraries^ http://librdf.org/
>>
>> 2016-06-02 15:42 GMT+03:00 Tone Kastlunger <users.giulietta at gmail.com>:
>>
>>> In a distributed fashion it may make sense;
>>> speaking of which, doesn't tracker implement a graph db?
>>>
>>> On Thu, Jun 2, 2016 at 3:40 PM, Andrew Branson <
>>> sfdevlist at andrewbranson.net> wrote:
>>>
>>>> I'm missing how your contacts can be linked as a graph on your phone. I
>>>> assumed it was about which of your friends know each other, but that isn't
>>>> relevant information on the client side. I don't think it's even easily
>>>> available in the main social networks.
>>>>
>>>> Andy
>>>>
>>>> On 02/06/2016 2:34pm, Tone Kastlunger wrote:
>>>>
>>>>> On the RDBMS vs Graph DB's discussion, the point Peter is making is a
>>>>> very solid one;
>>>>> the purpouse of the contacts app is to mange contacts; hence how they
>>>>> are connected;
>>>>> if relying on a Graph DB provides a simpler implementation (in terms of
>>>>> raw lines of code I mean) in upper implementation levels,
>>>>> whilst helping in keeping data consistency in a flawless and
>>>>> hassle-free
>>>>> way (which SQL can help with only up to a certain extent),
>>>>> well it definitely sounds too good to be true (at least from what I
>>>>> understood):
>>>>> I'd agree with Neo4J on a phone being somewhat of an overkill (same as
>>>>> having Postgres for instance); I'd wonder if there are embedded
>>>>> versions
>>>>> of it?
>>>>> I'd say especially within Jolla's Social/Address book/mail/calendar
>>>>> contacts management peculiarities, plus the dual SFOS/Android world, it
>>>>> requires a
>>>>> rock-solid contact management system, I'd assume.
>>>>>
>>>>> tk
>>>>>
>>>>>
>>>>> On Thu, Jun 2, 2016 at 3:22 PM, Andrew Branson
>>>>> <sfdevlist at andrewbranson.net <mailto:sfdevlist at andrewbranson.net>>
>>>>> wrote:
>>>>>
>>>>> Hi!
>>>>>
>>>>> RDBMSes are not very good at graphs, or trees, or any other data
>>>>> structure that requires variable traversal steps in queries. I
>>>>> don't
>>>>> think we have that here though. Those social networks only have
>>>>> graphs when they're integrating your data with other people's, but
>>>>> personally you just have your own address book and your own
>>>>> calendars. Both of those consist of many instances of the same data
>>>>> structures which need to be indexed, which is a good use of
>>>>> relational databases.
>>>>>
>>>>> Your point about SQL being used out of habit is always pertinent
>>>>> though. It's important to keep on top of the NoSQL options, as SQL
>>>>> is definitely overused. I always find it very irritating when SQL
>>>>> is
>>>>> used only for config storage, using tables with single rows and
>>>>> many
>>>>> columns. Berkeley DB would be a good alternative for that. I don't
>>>>> know if the graph DBs are ready yet though - Neo4J is very
>>>>> interesting, but I would never run a Java server in a phone.
>>>>>
>>>>> While we're on the subject, I think the Nemo thumbnail DB is a
>>>>> really good candidate for a NoSQL database. It's currently a huge
>>>>> collection of tiny files that seems to take up way too much BTRFS
>>>>> allocation, and I don't think as a collection of binary files it
>>>>> would be a good match for SQLite.
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>> On 02/06/2016 1:42pm, Peter Kovacs wrote:
>>>>>
>>>>> Well SQL is in my opinion good for grouping or conduct
>>>>> calculations on
>>>>> transactional data.
>>>>> Updating, or adding / sorting is not is best discipline. It is
>>>>> medicore
>>>>> in my opinion.
>>>>> On small sets of data as used in phones medicore performance is
>>>>> still
>>>>> quick. Phones are quite powerfull today.
>>>>>
>>>>> However the feature the DB should excel should be, in my eyes
>>>>> social,
>>>>> stuff. It is a phone after all, intended to maintain my social
>>>>> life, or?
>>>>>
>>>>> And Facebook, amazon, google+ does not use relational
>>>>> databases.
>>>>> They
>>>>> use graph databases. So I wonder why this is not used on
>>>>> phones.
>>>>> Neo4j
>>>>> claims to outperform relational databases by a factor of 1000
>>>>> when it
>>>>> comes to relationships.
>>>>>
>>>>> I admit these softwares are very latest technology. And maybe
>>>>> not as
>>>>> robust as sqllite.
>>>>> However I would love to have a contact app which knows that
>>>>> Mary
>>>>> and Joe
>>>>> are married live in the same place. And when I search for one
>>>>> of
>>>>> the 2 I
>>>>> get the shared information. And when I update one end the app
>>>>> knows to
>>>>> update the other one too.
>>>>> Or it can store company hierarchies would help me in my
>>>>> business
>>>>> life. I
>>>>> am not good at memo these.
>>>>>
>>>>> Yes you can do that with sql. But I think it is easier more
>>>>> naturally
>>>>> done in a graph db.
>>>>> No problem if any one does not agree. I plan to build this
>>>>> anyhow.
>>>>>
>>>>> I am quite unhappy with Google in that because they are not
>>>>> doing this
>>>>> for me ;)
>>>>>
>>>>> Btw Object DB is good at storing objects as the name suggests.
>>>>> It is
>>>>> even more far away from the requirements on a phone then
>>>>> relational db
>>>>> in my eyes.
>>>>>
>>>>> All the Best
>>>>> Peter
>>>>>
>>>>>
>>>>> Tone Kastlunger <users.giulietta at gmail.com
>>>>> <mailto:users.giulietta at gmail.com>
>>>>> <mailto:users.giulietta at gmail.com
>>>>> <mailto:users.giulietta at gmail.com>>> schrieb am Do., 2. Juni
>>>>> 2016, 11:13:
>>>>>
>>>>> Peter;
>>>>> I'm curious, what brings you to the conclusion SQL (as in
>>>>> relational
>>>>> dbs) is not ideal for transactional functionality?
>>>>>
>>>>> On Thu, Jun 2, 2016 at 10:41 AM, Peter Kovacs
>>>>> <leginee at gmail.com <mailto:leginee at gmail.com>
>>>>> <mailto:leginee at gmail.com <mailto:leginee at gmail.com>>>
>>>>> wrote:
>>>>>
>>>>> I would actually like to know why SQL stuff.
>>>>> Datastructure types I am think of on the Phone are
>>>>> relationships
>>>>> (Facebook style) or transactional.
>>>>> And both are not ideal to solve with relational dbs.
>>>>>
>>>>> I guess the Answer is because every one does it. But
>>>>> that is not
>>>>> really satisfactory. Would there be an interest to
>>>>> use
>>>>> something else?
>>>>>
>>>>>
>>>>> Tone Kastlunger <users.giulietta at gmail.com
>>>>> <mailto:users.giulietta at gmail.com>
>>>>> <mailto:users.giulietta at gmail.com
>>>>>
>>>>> <mailto:users.giulietta at gmail.com>>> schrieb am Do., 2. Juni
>>>>> 2016, 09:33:
>>>>>
>>>>> Hi Chris;
>>>>>
>>>>>
>>>>> >2) API to access Calendar data. Correct,
>>>>> currently we
>>>>> don't provide access to calendar API in Harbour.
>>>>> The reason
>>>>> is that we want to use QtOrganizer as the public
>>>>> API, but to
>>>>> do that we need to write a QtOrganizer engine
>>>>> backend >for
>>>>> mkcal (note that one already existed in QtMobility
>>>>> days,
>>>>> which is open source, so we can potentially adapt
>>>>> that one
>>>>> with relatively little effort. Help with that
>>>>> effort would
>>>>> be greatly appreciated). Eventually, I'd like to
>>>>> develop a
>>>>> >QtOrganizer backend directly in sqlite, for
>>>>> performance
>>>>> and maintainability reasons (mkcal has several
>>>>> design and
>>>>> implementation problems, in my opinion), at which
>>>>> point
>>>>> QtOrganizer can become the platform API (not just
>>>>> the 3rd
>>>>> >party API).
>>>>>
>>>>>
>>>>> I guess the worload to push it all the way to
>>>>> QtOrganizer
>>>>> requires scratching the existing backend /
>>>>> rewriting a big
>>>>> part of the cal app?
>>>>>
>>>>> On Thu, Jun 2, 2016 at 5:06 AM, Chris Adams
>>>>> <chris.adams at jolla.com
>>>>> <mailto:chris.adams at jolla.com> <mailto:chris.adams at jolla.com
>>>>>
>>>>> <mailto:chris.adams at jolla.com>>> wrote:
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I will try to be at the meeting tonight, but I
>>>>> cannot
>>>>> promise (it's held at 11:30 pm in my
>>>>> timezone).
>>>>>
>>>>> A couple of the questions relate to areas I am
>>>>> involved
>>>>> with, so I'll try to provide some information
>>>>> in case I
>>>>> don't make it to the meeting. If you have any
>>>>> follow up
>>>>> questions or discussion, feel free to contact
>>>>> me
>>>>> directly via email or on Freenode IRC
>>>>> (chriadam
>>>>> is my nick).
>>>>>
>>>>> 1) Contact Note details. This is tracked
>>>>> internally by
>>>>> JB#14734. As you mentioned, it's supported
>>>>> in the
>>>>> backend, but not in the People app UI. It was
>>>>> on going
>>>>> to be part of the apps overhaul which was
>>>>> planned prior
>>>>> to the financial difficulties last year, and
>>>>> since then
>>>>> this has fallen off the radar. It requires
>>>>> design
>>>>> input, because you can have multiple Note
>>>>> details in a
>>>>> single contact. I've just pinged our lead
>>>>> designer in
>>>>> the bug report again, in case he can fit it in
>>>>> sometime
>>>>> soon.
>>>>>
>>>>> 2) API to access Calendar data. Correct,
>>>>> currently we
>>>>> don't provide access to calendar API in
>>>>> Harbour. The
>>>>> reason is that we want to use QtOrganizer as
>>>>> the public
>>>>> API, but to do that we need to write a
>>>>> QtOrganizer
>>>>> engine backend for mkcal (note that one
>>>>> already
>>>>> existed
>>>>> in QtMobility days, which is open source, so
>>>>> we can
>>>>> potentially adapt that one with relatively
>>>>> little
>>>>> effort. Help with that effort would be
>>>>> greatly
>>>>> appreciated). Eventually, I'd like to
>>>>> develop a
>>>>> QtOrganizer backend directly in sqlite, for
>>>>> performance
>>>>> and maintainability reasons (mkcal has several
>>>>> design
>>>>> and implementation problems, in my opinion),
>>>>> at
>>>>> which
>>>>> point QtOrganizer can become the platform API
>>>>> (not just
>>>>> the 3rd party API).
>>>>>
>>>>> 3) Email app development. Yes, you're
>>>>> absolutely right
>>>>> that the Email application hasn't received
>>>>> much
>>>>> development effort since Valerio unfortunately
>>>>> left.
>>>>> Yes, I would personally like to see it (along
>>>>> with other
>>>>> apps like Clock, Notes, and Calendar)
>>>>> opensourced. No, I
>>>>> don't know what the status of the opensourcing
>>>>> discussions with the Board Of Directors is, so
>>>>> I cannot
>>>>> give a roadmap for that possibility.
>>>>> However, the
>>>>> "engine" of the email application is already
>>>>> open source
>>>>> (except for the Exchange/ActiveSync plugin) -
>>>>> we use QMF
>>>>> (Qt Messaging Framework) for email handling.
>>>>> See
>>>>> https://git.merproject.org/mer-core/qmf and
>>>>> https://git.merproject.org/mer-core/messagingframework
>>>>> etc for that stuff. Speak to Matt Vogt
>>>>> (mvogt on
>>>>> Freenode IRC) for code reviews etc.
>>>>>
>>>>> In general, the Sailfish OS wiki has been
>>>>> updated with a
>>>>> lot of information about the various software
>>>>> components
>>>>> which make up the Sailfish OS stack (including
>>>>> links to
>>>>> the open-source repositories), so you should
>>>>> be
>>>>> able to
>>>>> find most of the information you need to help
>>>>> develop
>>>>> these components, from reading
>>>>> https://sailfishos.org/wiki/Core_Areas_and_APIs and the
>>>>> drill-down links from that page.
>>>>>
>>>>> Finally, I don't know much about Bluetooth,
>>>>> but
>>>>> I know
>>>>> that we're looking at updating to Bluez 5
>>>>> right now
>>>>> (development is currently ongoing to port the
>>>>> Qt stack
>>>>> across, possibly by using the KDE bluez-qt
>>>>> wrappers), so
>>>>> it's possible that the tethering issue will be
>>>>> addressed
>>>>> as part of that, with the new stack - but
>>>>> again, that's
>>>>> not my area so I might be incorrect.
>>>>>
>>>>> Cheers,
>>>>> Chris.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *From:* devel-bounces at lists.sailfishos.org
>>>>> <mailto:devel-bounces at lists.sailfishos.org>
>>>>> <mailto:devel-bounces at lists.sailfishos.org
>>>>> <mailto:devel-bounces at lists.sailfishos.org>>
>>>>> [devel-bounces at lists.sailfishos.org
>>>>> <mailto:devel-bounces at lists.sailfishos.org>
>>>>> <mailto:devel-bounces at lists.sailfishos.org
>>>>> <mailto:devel-bounces at lists.sailfishos.org>>] on behalf
>>>>> of James Noori [james.noori at jolla.com
>>>>> <mailto:james.noori at jolla.com>
>>>>> <mailto:james.noori at jolla.com
>>>>> <mailto:james.noori at jolla.com>>]
>>>>> *Sent:* Wednesday, June 01, 2016 11:15 PM
>>>>> *To:* devel at lists.sailfishos.org
>>>>> <mailto:devel at lists.sailfishos.org>
>>>>> <mailto:devel at lists.sailfishos.org
>>>>> <mailto:devel at lists.sailfishos.org>>
>>>>> *Subject:* [SailfishDevel] Sailfish OS Open
>>>>> Source
>>>>> Community Collaboration Meeting 2nd of June
>>>>> 2016
>>>>>
>>>>> Hi everyone!
>>>>>
>>>>> Following up last week’s postponed Community
>>>>> collaboration meeting on IRC, this week’s
>>>>> meeting is
>>>>> going to be held at the agreed time and date,
>>>>> 2/6/2016
>>>>> at 13:30 UTC.
>>>>>
>>>>> Please see this link for your local time
>>>>> (Redirects to
>>>>> timeanddate.com <http://timeanddate.com> <
>>>>> http://timeanddate.com>)
>>>>>
>>>>> :http://bit.ly/247PwwT
>>>>>
>>>>> <
>>>>> http://redir.aspx?REF=g5j-y9bnU2VIldZnOnr8CS7-bSPOGw-1AMJwEvMljvQjLMD_gYrTCAFodHRwOi8vYml0Lmx5LzI0N1B3d1Q
>>>>> .>
>>>>>
>>>>> Location: #mer-meeting on Freenode IRC
>>>>>
>>>>> Chairperson: Jaymzz
>>>>>
>>>>> Duration: Approximately 100 minutes.
>>>>>
>>>>> Thanks to everyone who has responded and added
>>>>> topics on
>>>>>
>>>>> TJC:
>>>>> https://together.jolla.com/question/54157/sailfishos-open-source-collaboration-meeting-planning/
>>>>>
>>>>> <
>>>>> http://redir.aspx?REF=OlRBTW_rwoaCk_9FOorV7mZrXabeWUP7jnZySM69E7wjLMD_gYrTCAFodHRwczovL3RvZ2V0aGVyLmpvbGxhLmNvbS9xdWVzdGlvbi81NDE1Ny9zYWlsZmlzaG9zLW9wZW4tc291cmNlLWNvbGxhYm9yYXRpb24tbWVldGluZy1wbGFubmluZy8
>>>>> .>
>>>>>
>>>>> Proposed topics:
>>>>>
>>>>> -Intro (5min)
>>>>>
>>>>> -Bluetooth tethering - status of the fix
>>>>> (20min)
>>>>>
>>>>> -2016 roadmap (15min)
>>>>>
>>>>> -Show notes of contact (opensource contact
>>>>> app?) (15 min)
>>>>>
>>>>> -API to access calendar (15 min)
>>>>>
>>>>> -Email app development (15 min)
>>>>>
>>>>> - Requesting things to be added to mer-tools
>>>>> repo (5 min)
>>>>>
>>>>> - General Discussion (5-10 min)
>>>>>
>>>>> Please familiarize yourself with the topics
>>>>> before the
>>>>> meeting, as well
>>>>>
>>>>> as the common Meetbot commands
>>>>> https://wiki.debian.org/MeetBot
>>>>>
>>>>> <
>>>>> http://redir.aspx?REF=9bflfCySOf4l8VxPhhLe4rl_8CX0V51Eghusn5jTRNIjLMD_gYrTCAFodHRwczovL3dpa2kuZGViaWFuLm9yZy9NZWV0Qm90
>>>>> >
>>>>> (it's
>>>>>
>>>>>
>>>>> used for meeting management and logging)
>>>>>
>>>>> Best regards,
>>>>> James Noori, Community Manager at Jolla
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SailfishOS.org Devel mailing list
>>>>> To unsubscribe, please send a mail to
>>>>> devel-unsubscribe at lists.sailfishos.org
>>>>> <mailto:devel-unsubscribe at lists.sailfishos.org>
>>>>> <mailto:
>>>>> devel-unsubscribe at lists.sailfishos.org
>>>>> <mailto:devel-unsubscribe at lists.sailfishos.org>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SailfishOS.org Devel mailing list
>>>>> To unsubscribe, please send a mail to
>>>>> devel-unsubscribe at lists.sailfishos.org
>>>>> <mailto:devel-unsubscribe at lists.sailfishos.org>
>>>>> <mailto:devel-unsubscribe at lists.sailfishos.org
>>>>>
>>>>> <mailto:devel-unsubscribe at lists.sailfishos.org>>
>>>>>
>>>>> --
>>>>>
>>>>> Disclaimer: Diese Nachricht stammt aus einem Google
>>>>> Account.
>>>>> Ihre Antwort wird in der Google Cloud Gespeichert und
>>>>> durch
>>>>> Google Algorythmen zwecks werbeanaöysen gescannt. Es
>>>>> ist derzeit
>>>>> nicht auszuschließen das ihre Nachricht auch durch
>>>>> einen NSA
>>>>> Mitarbeiter geprüft wird. Durch kommunikation mit
>>>>> diesen Account
>>>>> stimmen Sie zu das ihre Mail, ihre Kontaktdaten und
>>>>> die
>>>>> Termine
>>>>> die Sie mit mir vereinbaren online zu Google
>>>>> konditionen in der
>>>>> Googlecloud gespeichert wird. Sollten sie dies nicht
>>>>> wünschen
>>>>> kontaktieren sie mich bitte Umgehend um z.B.
>>>>> alternativen zu
>>>>> verhandeln.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SailfishOS.org Devel mailing list
>>>>> To unsubscribe, please send a mail to
>>>>> devel-unsubscribe at lists.sailfishos.org
>>>>> <mailto:devel-unsubscribe at lists.sailfishos.org>
>>>>> <mailto:devel-unsubscribe at lists.sailfishos.org
>>>>> <mailto:devel-unsubscribe at lists.sailfishos.org>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SailfishOS.org Devel mailing list
>>>>> To unsubscribe, please send a mail to
>>>>> devel-unsubscribe at lists.sailfishos.org
>>>>> <mailto:devel-unsubscribe at lists.sailfishos.org>
>>>>> <mailto:devel-unsubscribe at lists.sailfishos.org
>>>>> <mailto:devel-unsubscribe at lists.sailfishos.org>>
>>>>>
>>>>> --
>>>>>
>>>>> Disclaimer: Diese Nachricht stammt aus einem Google Account.
>>>>> Ihre
>>>>> Antwort wird in der Google Cloud Gespeichert und durch Google
>>>>> Algorythmen zwecks werbeanaöysen gescannt. Es ist derzeit nicht
>>>>> auszuschließen das ihre Nachricht auch durch einen NSA
>>>>> Mitarbeiter
>>>>> geprüft wird. Durch kommunikation mit diesen Account stimmen
>>>>> Sie
>>>>> zu das
>>>>> ihre Mail, ihre Kontaktdaten und die Termine die Sie mit mir
>>>>> vereinbaren
>>>>> online zu Google konditionen in der Googlecloud gespeichert
>>>>> wird.
>>>>> Sollten sie dies nicht wünschen kontaktieren sie mich bitte
>>>>> Umgehend um
>>>>> z.B. alternativen zu verhandeln.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SailfishOS.org Devel mailing list
>>>>> To unsubscribe, please send a mail to
>>>>> devel-unsubscribe at lists.sailfishos.org
>>>>> <mailto:devel-unsubscribe at lists.sailfishos.org>
>>>>>
>>>>> _______________________________________________
>>>>> SailfishOS.org Devel mailing list
>>>>> To unsubscribe, please send a mail to
>>>>> devel-unsubscribe at lists.sailfishos.org
>>>>> <mailto:devel-unsubscribe at lists.sailfishos.org>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SailfishOS.org Devel mailing list
>>>>> To unsubscribe, please send a mail to
>>>>> devel-unsubscribe at lists.sailfishos.org
>>>>>
>>>>> _______________________________________________
>>>> SailfishOS.org Devel mailing list
>>>> To unsubscribe, please send a mail to
>>>> devel-unsubscribe at lists.sailfishos.org
>>>>
>>>
>>>
>>> _______________________________________________
>>> SailfishOS.org Devel mailing list
>>> To unsubscribe, please send a mail to
>>> devel-unsubscribe at lists.sailfishos.org
>>>
>>
>> _______________________________________________
>> SailfishOS.org Devel mailing list
>> To unsubscribe, please send a mail to
>> devel-unsubscribe at lists.sailfishos.org
>
> --
>
> Disclaimer: Diese Nachricht stammt aus einem Google Account. Ihre Antwort
> wird in der Google Cloud Gespeichert und durch Google Algorythmen zwecks
> werbeanaöysen gescannt. Es ist derzeit nicht auszuschließen das ihre
> Nachricht auch durch einen NSA Mitarbeiter geprüft wird. Durch
> kommunikation mit diesen Account stimmen Sie zu das ihre Mail, ihre
> Kontaktdaten und die Termine die Sie mit mir vereinbaren online zu Google
> konditionen in der Googlecloud gespeichert wird. Sollten sie dies nicht
> wünschen kontaktieren sie mich bitte Umgehend um z.B. alternativen zu
> verhandeln.
>
> _______________________________________________
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to
> devel-unsubscribe at lists.sailfishos.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20160603/948420ab/attachment-0001.html>
More information about the Devel
mailing list