KDE Core/Platform 11/KDEQtRelationship: Difference between revisions

From KDE Community Wiki
(Created page with '= Qt KDE relations = == Us and Them == Respect should go both ways? Tone of messages should be friendly. Offering KDE as playground - less strict, gets feedback, gets real app ...')
 
No edit summary
 
(7 intermediate revisions by one other user not shown)
Line 1: Line 1:
= Qt KDE relations =
{{warning|This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made.  Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.}}
 
What is the relationship between the Qt and KDE communities, in particular on a non-technical level? What can we do to improve it. What are the topics to address, and how do we do that?


== Us and Them ==
== Us and Them ==
Respect should go both ways? Tone of messages should be friendly.


Offering KDE as playground - less strict, gets feedback, gets real app exposure
There still is a us and them mentality. Communities could be closer together. There are a lot of common ideas. Lots of personal ties, but always changing. We need mutual respect. Core people should act as role models for community and users.
  -> more that a Qt labs project


== Qt and KDE ==
== Technical collaboration ==
Qt is cross platform, KDE is not there


KDE as space for innovation - less strict, gets feedback, gets real app exposure, more than a Qt labs project


== KDE plan for QCS ==
Qt is cross platform, KDE is not there yet. Qt standards like unit tests, API review, continuous integration are or would also be good KDE standards.


Make KDE attractive
KDE is part of ecosystem of independent Qt libraries that are not part of Qt.
Present KDE vision to Qt people


System how to get libraries, similar to ruby gems, cpan?


Sessions: KDE and Qt communities and working together, what can we learn from each other
How do we handle improved KDE stuff that goes into Qt but has a different api?
Code of conduct


Technical: The things that should be merged: KUrl and friends
== What is attractive for Qt in KDE ==
KLocale QLocale
Printing
Config systems
Archive handling


* App developers
* KDE is still a great public showcase and large resource of openly available Qt application code.
* KDE is an early adopter, commercial customers are way behind.
* KDE is a good pool for people.
* KDE wants to contribute to Qt.
* KDE cares about Qt. High quality feedback and contributions.
* Example for successful library: QJson
* Rekonq is interesting because it is a real world demo using qt webkit.
* Git is a bonus


3rd party libraries
== Open Governance ==
independent Qt libraries
Libraries for Qt developers that are not part of Qt
- system how to get libraries ?!? ruby gems, cpan


Can we convince people to help with modularization and clean up for KDE?


The contributor agreement?
Get a foot into the door: go for qt creator


Can we put cmake projects into qt creator? Make it possible to create KDE applications by default.


How do we handle improved KDE stuff that goes into Qt but has a different api?
What about QML designer?


== KDE plan for QCS ==


Open Governance
''This needs input from the outcome of other groups and topics discussed at the platform sprint. Do another breakout session towards the end of the sprint with the people who will be at the contributors' summit.''
 
App developers:
 
KDE is still a great public showcase and large resource of Qt example code.
KDE is an early adopter, commercial customers are way behind.
KDE is a good pool for people.
KDE wants to contribute to Qt.
KDE cares about Qt. High quality feedback and contributions.
 
Example for successful library: QJson
 
- modularization is great


Rekonq is interesting because it is a real world demo using qt webkit.
=== Goals ===


Git is a bonus
* Show KDE's attractiveness
* Present KDE vision to Qt people


Can we convince people to do modularization and clean up for KDE?
=== General sessions ===
Can kdelibs benefit from Qt test infrastructure.


KDE attitude: complain about blog post
* KDE and Qt communities and working together, what can we learn from each other (community processes, e.g. code of conduct) (Frederik, Cornelius)


=== Technical sessions ===


* The things that should be merged: KUrl and friends
* KLocale QLocale
* Printing
* Config systems
* Archive handling
* ...


Buildsystem???
=== Topics to discuss ===


What do we want to discuss? Who are the people to discuss with? What do we want to achieve? What do other people expect? How do we address pushback?


Can we put cmake projects into qt creator.
* The contributor agreement?
 
* ...
Get a foot into the door: go for qt creator
What about QML designer

Latest revision as of 16:31, 6 June 2011

Warning

This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made. Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.


What is the relationship between the Qt and KDE communities, in particular on a non-technical level? What can we do to improve it. What are the topics to address, and how do we do that?

Us and Them

There still is a us and them mentality. Communities could be closer together. There are a lot of common ideas. Lots of personal ties, but always changing. We need mutual respect. Core people should act as role models for community and users.

Technical collaboration

KDE as space for innovation - less strict, gets feedback, gets real app exposure, more than a Qt labs project

Qt is cross platform, KDE is not there yet. Qt standards like unit tests, API review, continuous integration are or would also be good KDE standards.

KDE is part of ecosystem of independent Qt libraries that are not part of Qt.

System how to get libraries, similar to ruby gems, cpan?

How do we handle improved KDE stuff that goes into Qt but has a different api?

What is attractive for Qt in KDE

  • App developers
  • KDE is still a great public showcase and large resource of openly available Qt application code.
  • KDE is an early adopter, commercial customers are way behind.
  • KDE is a good pool for people.
  • KDE wants to contribute to Qt.
  • KDE cares about Qt. High quality feedback and contributions.
  • Example for successful library: QJson
  • Rekonq is interesting because it is a real world demo using qt webkit.
  • Git is a bonus

Open Governance

Can we convince people to help with modularization and clean up for KDE?

Get a foot into the door: go for qt creator

Can we put cmake projects into qt creator? Make it possible to create KDE applications by default.

What about QML designer?

KDE plan for QCS

This needs input from the outcome of other groups and topics discussed at the platform sprint. Do another breakout session towards the end of the sprint with the people who will be at the contributors' summit.

Goals

  • Show KDE's attractiveness
  • Present KDE vision to Qt people

General sessions

  • KDE and Qt communities and working together, what can we learn from each other (community processes, e.g. code of conduct) (Frederik, Cornelius)

Technical sessions

  • The things that should be merged: KUrl and friends
  • KLocale QLocale
  • Printing
  • Config systems
  • Archive handling
  • ...

Topics to discuss

What do we want to discuss? Who are the people to discuss with? What do we want to achieve? What do other people expect? How do we address pushback?

  • The contributor agreement?
  • ...