[kde-community] Proposal One: KDE (Core) Apps and Suites
Proposal: Reduce the amount of KDE Core Apps according to a definition and release the other apps in independent groups or suites like e.g. KDE Edu, KDE Games, KDE PIM, Amarok or the Calligra Suite. Details: We could decide on a group of KDE Core Apps (for the Desktop) based on a definition like this: - Allows you to manage your files and documents (e.g. => Dolphin, Ark, K3b?) - Allows you to view documents and pictures (e.g. => Okular and Gwenview) - Allows you to watch movies and listen to music (e.g. => Dragon and Juk) - Allows you to administrate and manage your system (e.g. => print-manager, ksane, systemsettings) - Allows you to do this in an accessible way*: (e.g. => Simon, Jovie and Co) - Allows you to write some notes and find them again (e.g. => Kate/Kwrite) * A really nice promo argument. And as we as a community are inclusive this is the only thing the makes sense. Make our (core) apps accessible by default. About the current modules [1] we have and released it's a very unbalanced thing. Just compare KDEAdmin or KDEToys with KDEEdu or KDEPIM. So I think a reduction and rearrangement is the best thing. About the release of these Core Apps, Edu Suite, PIM Collection and Co see one of the next proposals. These suites or groups could then decide on their own if they want include new apps like e.g. KBibTeX or Rkward in KDEEdu or Trojita in KDEPIM. But I think these core apps (or call it differently) should be very well maintained, probably team maintained, have good unit and regression tests and good bug triage and bug handling. Reduced to the core and let it shine. Next steps: - Work on the definition for the KDE Core Apps (for Desktop). - Decide on the applications that fulfill this definition. - Define the minimum requirements these core apps need to fulfill to be released. - See what other suites or groups are logical and possible. - Discuss and agree an development and review work for these core apps. - Decide on a name for the "core apps". Now please tell me your opinion in a short, constructive and polite way. Details can be discussed in Randa and/or at Akademy. So let's concentrate on the bigger ideas. Thanks and best regards Mario [1] https://projects.kde.org/projects/kde ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Tuesday 22 of April 2014 11:31:02 Mario Fux wrote: > About the current modules [1] we have and released it's a very unbalanced > thing. Just compare KDEAdmin or KDEToys with KDEEdu or KDEPIM. So I think a > reduction and rearrangement is the best thing. Just a very tiny note for the record: when KDEToys was moved to git, the idea floating around (I asked on IRC, I should check my logs) was to remove it and move the three programs to other modules. IIRC kdegames for amor, kdepim for kteatime and kdeartwork (or workspace?) for ktux. It was not done at that time I think to avoid too many changes at the same time (module splits introduce further work for packagers). Ciao -- Luigi ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Tue, Apr 22, 2014 at 11:31 AM, Mario Fux wrote: > Proposal: > Reduce the amount of KDE Core Apps according to a definition and release > the > other apps in independent groups or suites like e.g. KDE Edu, KDE Games, > KDE > PIM, Amarok or the Calligra Suite. > > Details: > We could decide on a group of KDE Core Apps (for the Desktop) based on a > definition like this: > - Allows you to manage your files and documents (e.g. => Dolphin, Ark, > K3b?) > - Allows you to view documents and pictures (e.g. => Okular and Gwenview) > - Allows you to watch movies and listen to music (e.g. => Dragon and Juk) > - Allows you to administrate and manage your system (e.g. => print-manager, > ksane, systemsettings) > - Allows you to do this in an accessible way*: (e.g. => Simon, Jovie and > Co) > - Allows you to write some notes and find them again (e.g. => Kate/Kwrite) > > * A really nice promo argument. And as we as a community are inclusive > this is > the only thing the makes sense. Make our (core) apps accessible by default. > > About the current modules [1] we have and released it's a very unbalanced > thing. Just compare KDEAdmin or KDEToys with KDEEdu or KDEPIM. So I think a > reduction and rearrangement is the best thing. About the release of these > Core > Apps, Edu Suite, PIM Collection and Co see one of the next proposals. These > suites or groups could then decide on their own if they want include new > apps > like e.g. KBibTeX or Rkward in KDEEdu or Trojita in KDEPIM. > > But I think these core apps (or call it differently) should be very well > maintained, probably team maintained, have good unit and regression tests > and > good bug triage and bug handling. Reduced to the core and let it shine. > > Next steps: > - Work on the definition for the KDE Core Apps (for Desktop). > - Decide on the applications that fulfill this definition. > - Define the minimum requirements these core apps need to fulfill to be > released. > - See what other suites or groups are logical and possible. > - Discuss and agree an development and review work for these core apps. > - Decide on a name for the "core apps". > > Now please tell me your opinion in a short, constructive and polite way. > Details can be discussed in Randa and/or at Akademy. So let's concentrate > on > the bigger ideas. > > Thanks and best regards > Mario > > [1] https://projects.kde.org/projects/kde > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community > Hi, I think it's definitely one of the discussing areas for the next months. To be honest, I'm a bit torn with the KDE Core Apps concept. On one hand it makes total sense, because they're actually applications that we want to display as they need care, but then we're not taking a stance on what's the relation between them and Plasma. To that end, we'd need the different maintainers to come up with a meaningful vision statement for these that matches the new KDE organization. With my KDE Edu hat on, I see it as things should stay mostly the same in this regard. I would like to start to see the light in the end of the tunnel, regarding what will releases look like once we re-base on KF5, but there's still much work to be done in this area. Aleix ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
El Dimarts, 22 d'abril de 2014, a les 11:31:02, Mario Fux va escriure: > Proposal: > Reduce the amount of KDE Core Apps according to a definition and release the > other apps in independent groups or suites like e.g. KDE Edu, KDE Games, > KDE PIM, Amarok or the Calligra Suite. > > Details: > We could decide on a group of KDE Core Apps (for the Desktop) based on a > definition like this: > - Allows you to manage your files and documents (e.g. => Dolphin, Ark, K3b?) > - Allows you to view documents and pictures (e.g. => Okular and Gwenview) - > Allows you to watch movies and listen to music (e.g. => Dragon and Juk) - > Allows you to administrate and manage your system (e.g. => print-manager, > ksane, systemsettings) > - Allows you to do this in an accessible way*: (e.g. => Simon, Jovie and Co) > - Allows you to write some notes and find them again (e.g. => Kate/Kwrite) > > * A really nice promo argument. And as we as a community are inclusive this > is the only thing the makes sense. Make our (core) apps accessible by > default. > > About the current modules [1] we have and released it's a very unbalanced > thing. Just compare KDEAdmin or KDEToys with KDEEdu or KDEPIM. There's no such think as "KDEAdmin" from a releasing point of view, we just release tarballs of some apps that happen to be in that "virtual" module in projects.kde.org, but besides that, it's just single apps. > So I think a > reduction and rearrangement is the best thing. About the release of these > Core Apps, Edu Suite, PIM Collection and Co see one of the next proposals. > These suites or groups could then decide on their own if they want include > new apps like e.g. KBibTeX or Rkward in KDEEdu or Trojita in KDEPIM. Which is what they already do, no? > But I think these core apps (or call it differently) should be very well > maintained, probably team maintained, have good unit and regression tests > and good bug triage and bug handling. Reduced to the core and let it shine. I don't think "team maintainance" makes much sense beyond basic bugs, I don't think I can fix a non trivial bug in Ark (fwiw i've tried [though not very hard] :D) > Next steps: > - Work on the definition for the KDE Core Apps (for Desktop). > - Decide on the applications that fulfill this definition. > - Define the minimum requirements these core apps need to fulfill to be > released. > - See what other suites or groups are logical and possible. > - Discuss and agree an development and review work for these core apps. > - Decide on a name for the "core apps". Sincerely I don't see the point of this proposal, we're already releasing those core apps, and yes, they need better unit tests, and they need more manpower, but I don't see how creating an this "Core Apps vs Suites" is going to help with these issues. Moreover I'm sure someone will be pissed off because his app is not considered to be core. Cheers, Albert > > Now please tell me your opinion in a short, constructive and polite way. > Details can be discussed in Randa and/or at Akademy. So let's concentrate on > the bigger ideas. > > Thanks and best regards > Mario > > [1] https://projects.kde.org/projects/kde > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
El Dimarts, 22 d'abril de 2014, a les 11:53:19, Luigi Toscano va escriure: > On Tuesday 22 of April 2014 11:31:02 Mario Fux wrote: > > About the current modules [1] we have and released it's a very unbalanced > > thing. Just compare KDEAdmin or KDEToys with KDEEdu or KDEPIM. So I think > > a > > reduction and rearrangement is the best thing. > > Just a very tiny note for the record: when KDEToys was moved to git, the > idea floating around (I asked on IRC, I should check my logs) was to remove > it and move the three programs to other modules. IIRC kdegames for amor, > kdepim for kteatime and kdeartwork (or workspace?) for ktux. > > It was not done at that time I think to avoid too many changes at the same > time (module splits introduce further work for packagers). Since we just release the tarballs of the repos separate you can move stuff as you please releasing wise, the only things affected I can think of is the that we need to move the .po files and do some moving of jobs in build.kde.org Cheers, Albert > > Ciao ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Wed, Apr 23, 2014 at 11:49 PM, Albert Astals Cid wrote: > El Dimarts, 22 d'abril de 2014, a les 11:31:02, Mario Fux va escriure: > > Proposal: > > Reduce the amount of KDE Core Apps according to a definition and release > the > > other apps in independent groups or suites like e.g. KDE Edu, KDE Games, > > KDE PIM, Amarok or the Calligra Suite. > > > > Details: > > We could decide on a group of KDE Core Apps (for the Desktop) based on a > > definition like this: > > - Allows you to manage your files and documents (e.g. => Dolphin, Ark, > K3b?) > > - Allows you to view documents and pictures (e.g. => Okular and > Gwenview) - > > Allows you to watch movies and listen to music (e.g. => Dragon and Juk) - > > Allows you to administrate and manage your system (e.g. => print-manager, > > ksane, systemsettings) > > - Allows you to do this in an accessible way*: (e.g. => Simon, Jovie and > Co) > > - Allows you to write some notes and find them again (e.g. => > Kate/Kwrite) > > > > * A really nice promo argument. And as we as a community are inclusive > this > > is the only thing the makes sense. Make our (core) apps accessible by > > default. > > > > About the current modules [1] we have and released it's a very unbalanced > > thing. Just compare KDEAdmin or KDEToys with KDEEdu or KDEPIM. > > There's no such think as "KDEAdmin" from a releasing point of view, we just > release tarballs of some apps that happen to be in that "virtual" module in > projects.kde.org, but besides that, it's just single apps. > > > So I think a > > reduction and rearrangement is the best thing. About the release of these > > Core Apps, Edu Suite, PIM Collection and Co see one of the next > proposals. > > These suites or groups could then decide on their own if they want > include > > new apps like e.g. KBibTeX or Rkward in KDEEdu or Trojita in KDEPIM. > > Which is what they already do, no? > > > But I think these core apps (or call it differently) should be very well > > maintained, probably team maintained, have good unit and regression tests > > and good bug triage and bug handling. Reduced to the core and let it > shine. > > I don't think "team maintainance" makes much sense beyond basic bugs, I > don't > think I can fix a non trivial bug in Ark (fwiw i've tried [though not very > hard] :D) > > > Next steps: > > - Work on the definition for the KDE Core Apps (for Desktop). > > - Decide on the applications that fulfill this definition. > > - Define the minimum requirements these core apps need to fulfill to be > > released. > > - See what other suites or groups are logical and possible. > > - Discuss and agree an development and review work for these core apps. > > - Decide on a name for the "core apps". > > Sincerely I don't see the point of this proposal, we're already releasing > those core apps, and yes, they need better unit tests, and they need more > manpower, but I don't see how creating an this "Core Apps vs Suites" is > going > to help with these issues. > > Moreover I'm sure someone will be pissed off because his app is not > considered > to be core. > I think that what Mario meant here, is that we need to provide hints to the distributions regarding what applications should be shipped with a Plasma Desktop installation. What we currently call Plasma Desktop is not a full desktop suite because it lacks many applications that, arguably, are not related to Plasma but Plasma depends on, again like Dolphin. > > Cheers, > Albert > > > > > Now please tell me your opinion in a short, constructive and polite way. > > Details can be discussed in Randa and/or at Akademy. So let's > concentrate on > > the bigger ideas. > > > > Thanks and best regards > > Mario > Aleix ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Thursday, April 24, 2014 12:02:38 PM Aleix Pol wrote: > > Next steps: > > - Work on the definition for the KDE Core Apps (for Desktop). > > - Decide on the applications that fulfill this definition. > > - Define the minimum requirements these core apps need to fulfill to be > > released. > > - See what other suites or groups are logical and possible. > > - Discuss and agree an development and review work for these core apps. > > - Decide on a name for the "core apps". > > Sincerely I don't see the point of this proposal, we're already releasing > those core apps, and yes, they need better unit tests, and they need more > manpower, but I don't see how creating an this "Core Apps vs Suites" is > going to help with these issues. > > Moreover I'm sure someone will be pissed off because his app is not > considered to be core. I rather not use the word core. > > I think that what Mario meant here, is that we need to provide hints to the > distributions regarding what applications should be shipped with a Plasma > Desktop installation. +1 > > What we currently call Plasma Desktop is not a full desktop suite because it > lacks many applications that, arguably, are not related to Plasma but > Plasma depends on, again like Dolphin. I quite like this overall idea. Some points to consider - * Considering that we're now pushing the "Plasma" brand. Perhaps we want to look at these apps as part of the full Plasma experience. * From a design point of view, this can mean that the applications can work more closely with integrating with Plasma and working with the Plasma team on having a good experience (Just a suggestion, there are pros and cons) * It leads to some more healthy competition - Say multiple video players existed, we want all of them under the KDE Umbrella, but we just want one which is part of the "Plasma experience". * We could possibly release all of these at the same time. (key word - possibly) -- Vishesh Handa ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
El Dijous, 24 d'abril de 2014, a les 12:02:38, Aleix Pol va escriure: > On Wed, Apr 23, 2014 at 11:49 PM, Albert Astals Cid wrote: > > El Dimarts, 22 d'abril de 2014, a les 11:31:02, Mario Fux va escriure: > > > Proposal: > > > Reduce the amount of KDE Core Apps according to a definition and release > > > > the > > > > > other apps in independent groups or suites like e.g. KDE Edu, KDE Games, > > > KDE PIM, Amarok or the Calligra Suite. > > > > > > Details: > > > We could decide on a group of KDE Core Apps (for the Desktop) based on a > > > definition like this: > > > - Allows you to manage your files and documents (e.g. => Dolphin, Ark, > > > > K3b?) > > > > > - Allows you to view documents and pictures (e.g. => Okular and > > > > Gwenview) - > > > > > Allows you to watch movies and listen to music (e.g. => Dragon and Juk) > > > - > > > Allows you to administrate and manage your system (e.g. => > > > print-manager, > > > ksane, systemsettings) > > > - Allows you to do this in an accessible way*: (e.g. => Simon, Jovie and > > > > Co) > > > > > - Allows you to write some notes and find them again (e.g. => > > > > Kate/Kwrite) > > > > > * A really nice promo argument. And as we as a community are inclusive > > > > this > > > > > is the only thing the makes sense. Make our (core) apps accessible by > > > default. > > > > > > About the current modules [1] we have and released it's a very > > > unbalanced > > > thing. Just compare KDEAdmin or KDEToys with KDEEdu or KDEPIM. > > > > There's no such think as "KDEAdmin" from a releasing point of view, we > > just > > release tarballs of some apps that happen to be in that "virtual" module > > in > > projects.kde.org, but besides that, it's just single apps. > > > > > So I think a > > > reduction and rearrangement is the best thing. About the release of > > > these > > > Core Apps, Edu Suite, PIM Collection and Co see one of the next > > > > proposals. > > > > > These suites or groups could then decide on their own if they want > > > > include > > > > > new apps like e.g. KBibTeX or Rkward in KDEEdu or Trojita in KDEPIM. > > > > Which is what they already do, no? > > > > > But I think these core apps (or call it differently) should be very well > > > maintained, probably team maintained, have good unit and regression > > > tests > > > and good bug triage and bug handling. Reduced to the core and let it > > > > shine. > > > > I don't think "team maintainance" makes much sense beyond basic bugs, I > > don't > > think I can fix a non trivial bug in Ark (fwiw i've tried [though not very > > hard] :D) > > > > > Next steps: > > > - Work on the definition for the KDE Core Apps (for Desktop). > > > - Decide on the applications that fulfill this definition. > > > - Define the minimum requirements these core apps need to fulfill to be > > > released. > > > - See what other suites or groups are logical and possible. > > > - Discuss and agree an development and review work for these core apps. > > > - Decide on a name for the "core apps". > > > > Sincerely I don't see the point of this proposal, we're already releasing > > those core apps, and yes, they need better unit tests, and they need more > > manpower, but I don't see how creating an this "Core Apps vs Suites" is > > going > > to help with these issues. > > > > Moreover I'm sure someone will be pissed off because his app is not > > considered > > to be core. > > I think that what Mario meant here, is that we need to provide hints to the > distributions regarding what applications should be shipped with a Plasma > Desktop installation. > > What we currently call Plasma Desktop is not a full desktop suite because > it lacks many applications that, arguably, are not related to Plasma but > Plasma depends on, again like Dolphin. Why does Plasma depend on Dolphin? I can use any other file manager just as well, no? Cheers, Albert > > > Cheers, > > > > Albert > > > > > Now please tell me your opinion in a short, constructive and polite way. > > > Details can be discussed in Randa and/or at Akademy. So let's > > > > concentrate on > > > > > the bigger ideas. > > > > > > Thanks and best regards > > > Mario > > Aleix ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
El Dijous, 24 d'abril de 2014, a les 19:07:32, Vishesh Handa va escriure: > On Thursday, April 24, 2014 12:02:38 PM Aleix Pol wrote: > > > Next steps: > > > - Work on the definition for the KDE Core Apps (for Desktop). > > > - Decide on the applications that fulfill this definition. > > > - Define the minimum requirements these core apps need to fulfill to be > > > released. > > > - See what other suites or groups are logical and possible. > > > - Discuss and agree an development and review work for these core apps. > > > - Decide on a name for the "core apps". > > > > Sincerely I don't see the point of this proposal, we're already releasing > > those core apps, and yes, they need better unit tests, and they need more > > manpower, but I don't see how creating an this "Core Apps vs Suites" is > > going to help with these issues. > > > > Moreover I'm sure someone will be pissed off because his app is not > > considered to be core. > > I rather not use the word core. > > > I think that what Mario meant here, is that we need to provide hints to > > the > > distributions regarding what applications should be shipped with a Plasma > > Desktop installation. > > +1 > > > What we currently call Plasma Desktop is not a full desktop suite because > > it lacks many applications that, arguably, are not related to Plasma but > > Plasma depends on, again like Dolphin. > > I quite like this overall idea. Some points to consider - > > * Considering that we're now pushing the "Plasma" brand. Perhaps we want to > look at these apps as part of the full Plasma experience. No, I don't want us to call "Okular" -> "Plasma Okular" or "Plasma Document Viewer" it goes against our messaging that our apps are not tied to our desktop and as as well useful elsewhere. Cheers, Albert > > * From a design point of view, this can mean that the applications can work > more closely with integrating with Plasma and working with the Plasma team > on having a good experience (Just a suggestion, there are pros and cons) > > * It leads to some more healthy competition - Say multiple video players > existed, we want all of them under the KDE Umbrella, but we just want one > which is part of the "Plasma experience". > > * We could possibly release all of these at the same time. (key word - > possibly) ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Thu, Apr 24, 2014 at 10:57 PM, Albert Astals Cid wrote: > El Dijous, 24 d'abril de 2014, a les 12:02:38, Aleix Pol va escriure: > > On Wed, Apr 23, 2014 at 11:49 PM, Albert Astals Cid > wrote: > > > El Dimarts, 22 d'abril de 2014, a les 11:31:02, Mario Fux va escriure: > > > > Proposal: > > > > Reduce the amount of KDE Core Apps according to a definition and > release > > > > > > the > > > > > > > other apps in independent groups or suites like e.g. KDE Edu, KDE > Games, > > > > KDE PIM, Amarok or the Calligra Suite. > > > > > > > > Details: > > > > We could decide on a group of KDE Core Apps (for the Desktop) based > on a > > > > definition like this: > > > > - Allows you to manage your files and documents (e.g. => Dolphin, > Ark, > > > > > > K3b?) > > > > > > > - Allows you to view documents and pictures (e.g. => Okular and > > > > > > Gwenview) - > > > > > > > Allows you to watch movies and listen to music (e.g. => Dragon and > Juk) > > > > - > > > > Allows you to administrate and manage your system (e.g. => > > > > print-manager, > > > > ksane, systemsettings) > > > > - Allows you to do this in an accessible way*: (e.g. => Simon, Jovie > and > > > > > > Co) > > > > > > > - Allows you to write some notes and find them again (e.g. => > > > > > > Kate/Kwrite) > > > > > > > * A really nice promo argument. And as we as a community are > inclusive > > > > > > this > > > > > > > is the only thing the makes sense. Make our (core) apps accessible by > > > > default. > > > > > > > > About the current modules [1] we have and released it's a very > > > > unbalanced > > > > thing. Just compare KDEAdmin or KDEToys with KDEEdu or KDEPIM. > > > > > > There's no such think as "KDEAdmin" from a releasing point of view, we > > > just > > > release tarballs of some apps that happen to be in that "virtual" > module > > > in > > > projects.kde.org, but besides that, it's just single apps. > > > > > > > So I think a > > > > reduction and rearrangement is the best thing. About the release of > > > > these > > > > Core Apps, Edu Suite, PIM Collection and Co see one of the next > > > > > > proposals. > > > > > > > These suites or groups could then decide on their own if they want > > > > > > include > > > > > > > new apps like e.g. KBibTeX or Rkward in KDEEdu or Trojita in KDEPIM. > > > > > > Which is what they already do, no? > > > > > > > But I think these core apps (or call it differently) should be very > well > > > > maintained, probably team maintained, have good unit and regression > > > > tests > > > > and good bug triage and bug handling. Reduced to the core and let it > > > > > > shine. > > > > > > I don't think "team maintainance" makes much sense beyond basic bugs, I > > > don't > > > think I can fix a non trivial bug in Ark (fwiw i've tried [though not > very > > > hard] :D) > > > > > > > Next steps: > > > > - Work on the definition for the KDE Core Apps (for Desktop). > > > > - Decide on the applications that fulfill this definition. > > > > - Define the minimum requirements these core apps need to fulfill to > be > > > > released. > > > > - See what other suites or groups are logical and possible. > > > > - Discuss and agree an development and review work for these core > apps. > > > > - Decide on a name for the "core apps". > > > > > > Sincerely I don't see the point of this proposal, we're already > releasing > > > those core apps, and yes, they need better unit tests, and they need > more > > > manpower, but I don't see how creating an this "Core Apps vs Suites" is > > > going > > > to help with these issues. > > > > > > Moreover I'm sure someone will be pissed off because his app is not > > > considered > > > to be core. > > > > I think that what Mario meant here, is that we need to provide hints to > the > > distributions regarding what applications should be shipped with a Plasma > > Desktop installation. > > > > What we currently call Plasma Desktop is not a full desktop suite because > > it lacks many applications that, arguably, are not related to Plasma but > > Plasma depends on, again like Dolphin. > > Why does Plasma depend on Dolphin? I can use any other file manager just as > well, no? > > Cheers, > Albert > > > > > > Cheers, > > > > > > Albert > > > > > > > Now please tell me your opinion in a short, constructive and polite > way. > > > > Details can be discussed in Randa and/or at Akademy. So let's > > > > > > concentrate on > > > > > > > the bigger ideas. > > > > > > > > Thanks and best regards > > > > Mario > > > > Aleix > That is definitely a good question, I would like to hear the thoughts from Plasma and Dolphin maintainers. I know it's not from a technical point of view, but from a mission/vision of the different projects point of view. I think the Plasma project will probably want to have a greater control on what experience the user is receiving further than the shell itself. But maybe not. Aleix ___ kde-community mailing list kde-co
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On 22 April 2014 11:31, Mario Fux wrote: > Proposal: > Reduce the amount of KDE Core Apps according to a definition and release the > other apps in independent groups or suites like e.g. KDE Edu, KDE Games, KDE > PIM, Amarok or the Calligra Suite. > > Details: > We could decide on a group of KDE Core Apps (for the Desktop) based on a > definition like this: > - Allows you to manage your files and documents (e.g. => Dolphin, Ark, K3b?) > - Allows you to view documents and pictures (e.g. => Okular and Gwenview) > - Allows you to watch movies and listen to music (e.g. => Dragon and Juk) > - Allows you to administrate and manage your system (e.g. => print-manager, > ksane, systemsettings) > - Allows you to do this in an accessible way*: (e.g. => Simon, Jovie and Co) > - Allows you to write some notes and find them again (e.g. => Kate/Kwrite) One note, I would not call Kate as core app. It rather belongs to a Specialized Apps group (with KDevelop, Konsole and... Kexi for example). Anyone unconvinced can look at, say, Kate's Tools menu :) So my idea could be to start from optics of basic user, discovering personas, their goals or needs, and then realistic groups would appear naturally. BTW, does even "Core Apps" sound fine for the basic user? -- regards / pozdrawiam, Jaroslaw Staniek Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen Qt Certified Specialist | http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Thursday, April 24, 2014 22:59:09 Albert Astals Cid wrote: > > * Considering that we're now pushing the "Plasma" brand. Perhaps we want > > to > > look at these apps as part of the full Plasma experience. > > No, I don't want us to call "Okular" -> "Plasma Okular" or "Plasma Document > Viewer" it goes against our messaging that our apps are not tied to our > desktop and as as well useful elsewhere. I think you have hit the core(!) of the dilemma here. On one hand, we do want to make Plasma a total environment (both desktop and mobile and possibly more). This means not only having a background, panel and start menu but also a selection of necessary applications like a document viewer. And it *is* easier for users, especially new users, if the document viewer is just named "Document Viewer", not okular. On the other hand you are totally right. KDE has always had a problem to get people to accept KDE applications on other desktops since "KDE foo" has always been interpreted as "foo for KDE (the desktop)" rather than "foo from KDE (the community)". With our rebranding of KDE going forward, although slowly, we need to be careful that we don't end up in the exact same situation again but with "Plasma" instead of "KDE". So my suggestion would be to keep the individual names but make damn sure that the full name also covers the use case. For Okular this would mean "Okular document viewer" rather than only "Okular". Another approach would be to make everything dual-named where one name is only used inside Plasma (like "Plasma document viewer" or just "document viewer") and one name is used in other places (like "Okular document viewer"). Isn't this possible with the new additions to the .desktop file standard or am I totally wrong here? ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Thursday, April 24, 2014 22:57:07 Albert Astals Cid wrote: > > > > What we currently call Plasma Desktop is not a full desktop suite because > > it lacks many applications that, arguably, are not related to Plasma but > > Plasma depends on, again like Dolphin. > > Why does Plasma depend on Dolphin? I can use any other file manager just as > well, no? Plasma is not dependent on Dolphin. But the user experience given by Plasma is dependent on having an application like Dolphin. The Plasma desktop needs to have something like Dolphin to be a complete desktop. And I think you missed the word "like" in the last sentence above.___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Thursday, April 24, 2014 10:59:09 PM Albert Astals Cid wrote: > > * Considering that we're now pushing the "Plasma" brand. Perhaps we want > > to > > look at these apps as part of the full Plasma experience. > > No, I don't want us to call "Okular" -> "Plasma Okular" or "Plasma Document > Viewer" it goes against our messaging that our apps are not tied to our > desktop and as as well useful elsewhere. I didn't mean that. I just meant that we think more on how they can integrate better. (Hypothetically) -- Vishesh Handa ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Thursday 24 April 2014 22:57:07 Albert Astals Cid wrote: > > What we currently call Plasma Desktop is not a full desktop suite because > > it lacks many applications that, arguably, are not related to Plasma but > > Plasma depends on, again like Dolphin. > > Why does Plasma depend on Dolphin? I can use any other file manager just as > well, no? on the other hand, I would consider the "intended desktop experience" complete only If dolphin (and an handful of other apps) are present, even tough technically of course the user is free to change it with any other filemanager -- Marco Martin ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
Hi, > > On the other hand you are totally right. KDE has always had a problem to > get people to accept KDE applications on other desktops since "KDE foo" has > always been interpreted as "foo for KDE (the desktop)" rather than "foo > from KDE (the community)". With our rebranding of KDE going forward, > although slowly, we need to be careful that we don't end up in the exact > same situation again but with "Plasma" instead of "KDE". > "KDE foo" has been traditionally linked to the need of "loading a heavy block of libraries for just running a single app". We are working on this, right? The battle to change the mindset is fighting this idea, no diluting the brand. We are identified based, among others, on two basic concepts: * Integration. * Solid community/project. You have been behind them for years :-) Our brand is an asset that we should use in our own benefit. We are already taking a big risk on diluting it with the current strategy of releasing separately the different layers of our stack. We haven't evaluated yet the impact and we are talking about going further. We are playing with fire. And we will only know if we got burned in a couple of years. The following months, with the "heat of the news", if we do the marketing it well, and we will, it will look like we took the right decisions.but that perception might be wrong, in the same way that in our previous transition it was perceived at the beginning that we took wrong decisions, but we didn't. Instead of increasing the risks of diluting our brand, we should be focusing on making it stronger, at least at this point. This strategy should be compatible with addressing our natural evolution as project, moving from a single unit to a meta one. Let's not forget that there are millions of people out there that care very little about our tiny individual/group differences, messages, goals We have not succeeded yet in selling a single message widely, or at least as wide as our software deserves. I read these proposals and, at the end, they talk about sending several messages, splitting resources, promoting the pieces . As strategy, I think we are heading in the wrong direction. Not because it is a bad idea to go in the proposed one, but because it is not based in our strengths in terms of message. If we want to succeed with our current resources, it is way easier to base our actions, promo included, in our strengths, not in our weaknesses, hoping that, with promo, we are going to solve them. Saludos -- Agustín Benito Bethencourt Profile: http://es.linkedin.com/in/toscalix Twitter: @toscalix ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Thursday 24 April 2014 23:23:28 Jaroslaw Staniek wrote:
> On 22 April 2014 11:31, Mario Fux wrote:
> > Proposal:
> > Reduce the amount of KDE Core Apps according to a definition and release
> > the other apps in independent groups or suites like e.g. KDE Edu, KDE
> > Games, KDE PIM, Amarok or the Calligra Suite.
> >
> > Details:
> > We could decide on a group of KDE Core Apps (for the Desktop) based on a
> > definition like this:
> > - Allows you to manage your files and documents (e.g. => Dolphin, Ark,
> > K3b?) - Allows you to view documents and pictures (e.g. => Okular and
> > Gwenview) - Allows you to watch movies and listen to music (e.g. =>
> > Dragon and Juk) - Allows you to administrate and manage your system (e.g.
> > => print-manager, ksane, systemsettings)
> > - Allows you to do this in an accessible way*: (e.g. => Simon, Jovie and
> > Co) - Allows you to write some notes and find them again (e.g. =>
> > Kate/Kwrite)
> One note, I would not call Kate as core app. It rather belongs to a
> Specialized Apps group (with KDevelop, Konsole and... Kexi for
> example). Anyone unconvinced can look at, say, Kate's Tools menu :)
>
> So my idea could be to start from optics of basic user, discovering
> personas, their
> goals or needs, and then realistic groups would appear naturally.
> BTW, does even "Core Apps" sound fine for the basic user?
Core Apps is horrible in any case, it should be something like the KDE
Essentials.
But, as Agustin also pointed out, we need to be careful not to dilute our
brand. Plasma is our desktop (ok, 'workspaces', but primarily desktop still).
We ship applications, which are currently conveniently bundled in 'KDE
Applications' with a 'Extragear' and then some separate suites, Calligra and
Amarok being separate (but Kontact being part of the KDE Applications...?).
I think the idea of grouping releases ('Sigma'?) is a good one. How about we
start there. Let's give Applications more freedom, yet allow them to be part
of the 'bunch', yes? Calligra, Amarok, the Extragear apps - they should be
part of the KDE Applications. Fold it all in there, with more flexibility
thanks to more regular (but non-mandatory) releases. Yes, everybody their own
release numbers, no synchronization needed at all. Not every release needs
every application, but perhaps for convenience of distro's we provide
everything in a tarball- just not with updated version numbers. They can ship
KDE Applications 2015.6 (?) and be sure to have all of them, but many of the
apps might not be different from those in KDE Applications 2015.2.
And then we have Plasma, as it is now - the core desktop (netbook/media
center) experience. Kwalletmanager, Systemsettings - they are part of this
already, aren't they? That makes sense. The criteria: you really need them to
use Plasma Desktop in a reasonable way (eg 95% usecase).
To satisfy the need of distributions (and users) to know what they should have
for a basic, functioning, KDE-software based desktop, we define the KDE
Essentials. Very bare: Konsole, Kwrite, Dolphin, Ark, Okular, Gwenview, you
can imagine. The criteria: EVERY user (well, ~90%) uses these applications,
BUT you can swap them with another without everything falling apart.
Example: You can't configure things without Systemsettings (gnome
systemsettings won't do the trick for you...), you can't save passwords
without kwalletmanager, but you can replace Dolphin with Nautilus and Kate is
most likely not needed by ~90% of our users. So Systemsettings goes in Plasma,
Dolphin in Essentials, Kate in its module in KDE Applications. Accessibility
also probably belongs in Essentials, not for 90% of the users needing it but,
well, let's call it human decency that accessibility is something we consider
essential!
We ship no duplicates in the essentials, and have a best-of-breed policy. Let
the release managers decide what goes in, in consensus-style discussion with
the application maintainers, that should generally work just fine. The modules
- I think they can stay where they make sense for their respective teams (KDE
Edu comes to mind) and just go away where they already don't really exist (KDE
Admin) or make no sense.
The result: branding stays the same (stronger, even, pulling in Amarok,
Calligra, Kdenlive etc), we protect what we build up over the years, it is
simple, YET it cleans up a bit of the fuzzy stuff and gives more clear
criteria for decisions.
I know. The idea above isn't much different from what Mario proposed, except
with a very limiting 'core'. More 'essentials'. I know I probably used more
words than I should have.
Hugs,
Jos
signature.asc
Description: This is a digitally signed message part.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Fri, Apr 25, 2014 at 10:12 PM, Jos Poortvliet <
jospoortvlietstanburd...@gmail.com > wrote:
>
> I think the idea of grouping releases ('Sigma'?) is a good one. How about
> we
> start there. Let's give Applications more freedom, yet allow them to be
> part
> of the 'bunch', yes? Calligra, Amarok, the Extragear apps - they should be
> part of the KDE Applications. Fold it all in there, with more flexibility
> thanks to more regular (but non-mandatory) releases. Yes, everybody their
> own
> release numbers, no synchronization needed at all. Not every release needs
> every application, but perhaps for convenience of distro's we provide
> everything in a tarball- just not with updated version numbers. They can
> ship
> KDE Applications 2015.6 (?) and be sure to have all of them, but many of
> the
> apps might not be different from those in KDE Applications 2015.2.
>
I think the release numbers should be all the same and perhaps even the
number of the "Sigma" release (also, we should come up with something else
than "Sigma" before it catches on and stays...like "SC"...unless we want it
to stay). Otherwise it will be a mess imho - "KDE Applications 2015.6
contains Dolphin 5.2.1, Calligra 7.8, Amarok 4.6.4, Kontact 5.3.1" -- "KDE
Applications 2015.12 contains Dolphin 5.2.3, Calligra 8.1, Amarok 4.8.2,
Kontact 5.4.1"are those own version numbers really that important? It
could just as well be "Dolphin 2015.6" or "Amarok 2015.12" (or some other
numbers), but unified. More coherent, more clear, more simple. The downside
I see is that the apps' developers would need to commit to this new policy,
which might hit some resistance.
> And then we have Plasma, as it is now - the core desktop (netbook/media
> center) experience. Kwalletmanager, Systemsettings - they are part of this
> already, aren't they? That makes sense. The criteria: you really need them
> to
> use Plasma Desktop in a reasonable way (eg 95% usecase).
>
> To satisfy the need of distributions (and users) to know what they should
> have
> for a basic, functioning, KDE-software based desktop, we define the KDE
> Essentials. Very bare: Konsole, Kwrite, Dolphin, Ark, Okular, Gwenview, you
> can imagine. The criteria: EVERY user (well, ~90%) uses these applications,
> BUT you can swap them with another without everything falling apart.
>
I'm a bit skeptic about the metric here. I'd rather maybe define sets of
goals the user should be able to do with our desktop and then make the list
from that - "the user must be able to read a PDF; the user must be able to
view pictures" etc.
>
> Example: You can't configure things without Systemsettings (gnome
> systemsettings won't do the trick for you...), you can't save passwords
> without kwalletmanager, but you can replace Dolphin with Nautilus and Kate
> is
> most likely not needed by ~90% of our users. So Systemsettings goes in
> Plasma,
> Dolphin in Essentials, Kate in its module in KDE Applications.
> Accessibility
> also probably belongs in Essentials, not for 90% of the users needing it
> but,
> well, let's call it human decency that accessibility is something we
> consider
> essential!
>
> We ship no duplicates in the essentials, and have a best-of-breed policy.
> Let
> the release managers decide what goes in, in consensus-style discussion
> with
> the application maintainers, that should generally work just fine. The
> modules
> - I think they can stay where they make sense for their respective teams
> (KDE
> Edu comes to mind) and just go away where they already don't really exist
> (KDE
> Admin) or make no sense.
>
+1
Cheers
--
Martin Klapetek | KDE Developer
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Monday 28 April 2014 11:08:34 Martin Klapetek wrote:
> On Fri, Apr 25, 2014 at 10:12 PM, Jos Poortvliet <
>
> jospoortvlietstanburd...@gmail.com > wrote:
> > I think the idea of grouping releases ('Sigma'?) is a good one. How about
> > we
> > start there. Let's give Applications more freedom, yet allow them to be
> > part
> > of the 'bunch', yes? Calligra, Amarok, the Extragear apps - they should
> > be
> > part of the KDE Applications. Fold it all in there, with more flexibility
> > thanks to more regular (but non-mandatory) releases. Yes, everybody their
> > own
> > release numbers, no synchronization needed at all. Not every release
> > needs
> > every application, but perhaps for convenience of distro's we provide
> > everything in a tarball- just not with updated version numbers. They can
> > ship
> > KDE Applications 2015.6 (?) and be sure to have all of them, but many of
> > the
> > apps might not be different from those in KDE Applications 2015.2.
>
> I think the release numbers should be all the same and perhaps even the
> number of the "Sigma" release (also, we should come up with something else
> than "Sigma" before it catches on and stays...like "SC"...unless we want it
> to stay). Otherwise it will be a mess imho - "KDE Applications 2015.6
> contains Dolphin 5.2.1, Calligra 7.8, Amarok 4.6.4, Kontact 5.3.1" -- "KDE
> Applications 2015.12 contains Dolphin 5.2.3, Calligra 8.1, Amarok 4.8.2,
> Kontact 5.4.1"are those own version numbers really that important? It
> could just as well be "Dolphin 2015.6" or "Amarok 2015.12" (or some other
> numbers), but unified. More coherent, more clear, more simple. The
> downside I see is that the apps' developers would need to commit to this
> new policy, which might hit some resistance.
Look at what we try to do here: message that our applications are separate
and independent. There is nothing about Ktouch that requires Amarok, and
Words is just fine without Kanagram. The fact that, on a release engineering
level, we release them in batches - that is irrelevant for users. They just
get the one app they want, be it for Windows, Mac, Linux, Android...
Delivering it as a 'suite' with the same version numbers gives the impression
they do belong together. But they don't - the only thing KDE software has in
common is the people who make it. Functionally, you can use them anywhere,
alone or in groups, separate or combined.
Also - most apps wouldn't release with every sigma release, so more than half
our applications is out of sync most of the time. Having Kontact and Gwenview
2014.8 and Words and Palapeli 2014.6 and Amarok 2015.2 all being the latest
version seems more confusing than Kontact 1.8, Gwenview 2.3 etc etc on their
own. That is what people are used too.
I don't see a strong argument for syncing the release numbers, the confusing
part doesn't convince me. There's plenty of different version numbers on your
system atm ;-)
But if anybody knows a good reason to sync, say so please.
> > And then we have Plasma, as it is now - the core desktop (netbook/media
> > center) experience. Kwalletmanager, Systemsettings - they are part of
> > this
> > already, aren't they? That makes sense. The criteria: you really need
> > them
> > to
> > use Plasma Desktop in a reasonable way (eg 95% usecase).
> >
> > To satisfy the need of distributions (and users) to know what they should
> > have
> > for a basic, functioning, KDE-software based desktop, we define the KDE
> > Essentials. Very bare: Konsole, Kwrite, Dolphin, Ark, Okular, Gwenview,
> > you can imagine. The criteria: EVERY user (well, ~90%) uses these
> > applications, BUT you can swap them with another without everything
> > falling apart.
> I'm a bit skeptic about the metric here. I'd rather maybe define sets of
> goals the user should be able to do with our desktop and then make the list
> from that - "the user must be able to read a PDF; the user must be able to
> view pictures" etc.
Well, sure, but what criteria do you use to decide what criteria should be
part of the core set? A DTP app won't be part of core following what I
propose, but "The user must be able to do DTP" seems a perfect fit to the
"user should be able to do X" list.
In other words, I'd argue that "the user must be able to do X" is a criteria
that follows out of defining what 95% of the users use. It doesn't work on
its own.
> > Example: You can't configure things without Systemsettings (gnome
> > systemsettings won't do the trick for you...), you can't save passwords
> > without kwalletmanager, but you can replace Dolphin with Nautilus and
> > Kate
> > is
> > most likely not needed by ~90% of our users. So Systemsettings goes in
> > Plasma,
> > Dolphin in Essentials, Kate in its module in KDE Applications.
> > Accessibility
> > also probably belongs in Essentials, not for 90% of the users needing it
> > but,
> > well, let's call it human decency that accessibility is something we
> > consider
> > essential!
>
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Wed, Apr 30, 2014 at 10:48 AM, Jos Poortvliet wrote:
> On Monday 28 April 2014 11:08:34 Martin Klapetek wrote:
> > On Fri, Apr 25, 2014 at 10:12 PM, Jos Poortvliet <
> >
> > jospoortvlietstanburd...@gmail.com > wrote:
> > > I think the idea of grouping releases ('Sigma'?) is a good one. How
> about
> > > we
> > > start there. Let's give Applications more freedom, yet allow them to be
> > > part
> > > of the 'bunch', yes? Calligra, Amarok, the Extragear apps - they should
> > > be
> > > part of the KDE Applications. Fold it all in there, with more
> flexibility
> > > thanks to more regular (but non-mandatory) releases. Yes, everybody
> their
> > > own
> > > release numbers, no synchronization needed at all. Not every release
> > > needs
> > > every application, but perhaps for convenience of distro's we provide
> > > everything in a tarball- just not with updated version numbers. They
> can
> > > ship
> > > KDE Applications 2015.6 (?) and be sure to have all of them, but many
> of
> > > the
> > > apps might not be different from those in KDE Applications 2015.2.
> >
> > I think the release numbers should be all the same and perhaps even the
> > number of the "Sigma" release (also, we should come up with something
> else
> > than "Sigma" before it catches on and stays...like "SC"...unless we want
> it
> > to stay). Otherwise it will be a mess imho - "KDE Applications 2015.6
> > contains Dolphin 5.2.1, Calligra 7.8, Amarok 4.6.4, Kontact 5.3.1" --
> "KDE
> > Applications 2015.12 contains Dolphin 5.2.3, Calligra 8.1, Amarok 4.8.2,
> > Kontact 5.4.1"are those own version numbers really that important? It
> > could just as well be "Dolphin 2015.6" or "Amarok 2015.12" (or some other
> > numbers), but unified. More coherent, more clear, more simple. The
> > downside I see is that the apps' developers would need to commit to this
> > new policy, which might hit some resistance.
>
> Look at what we try to do here: message that our applications are separate
> and independent. There is nothing about Ktouch that requires Amarok, and
> Words is just fine without Kanagram. The fact that, on a release
> engineering
> level, we release them in batches - that is irrelevant for users. They just
> get the one app they want, be it for Windows, Mac, Linux, Android...
>
> Delivering it as a 'suite' with the same version numbers gives the
> impression
> they do belong together. But they don't - the only thing KDE software has
> in
> common is the people who make it. Functionally, you can use them anywhere,
> alone or in groups, separate or combined.
>
>From the original proposal I understood the "core" apps would actually
belong together, to form the "core". Is that not the case?
> Also - most apps wouldn't release with every sigma release, so more than
> half
> our applications is out of sync most of the time. Having Kontact and
> Gwenview
> 2014.8 and Words and Palapeli 2014.6 and Amarok 2015.2 all being the latest
> version seems more confusing than Kontact 1.8, Gwenview 2.3 etc etc on
> their
> own. That is what people are used too.
>
> I don't see a strong argument for syncing the release numbers, the
> confusing
> part doesn't convince me. There's plenty of different version numbers on
> your
> system atm ;-)
>
> But if anybody knows a good reason to sync, say so please.
>
To be honest I don't see the point of my application actually joining the
joint release...
> > > And then we have Plasma, as it is now - the core desktop
> (netbook/media
> > > center) experience. Kwalletmanager, Systemsettings - they are part of
> > > this
> > > already, aren't they? That makes sense. The criteria: you really need
> > > them
> > > to
> > > use Plasma Desktop in a reasonable way (eg 95% usecase).
> > >
> > > To satisfy the need of distributions (and users) to know what they
> should
> > > have
> > > for a basic, functioning, KDE-software based desktop, we define the KDE
> > > Essentials. Very bare: Konsole, Kwrite, Dolphin, Ark, Okular, Gwenview,
> > > you can imagine. The criteria: EVERY user (well, ~90%) uses these
> > > applications, BUT you can swap them with another without everything
> > > falling apart.
> > I'm a bit skeptic about the metric here. I'd rather maybe define sets of
> > goals the user should be able to do with our desktop and then make the
> list
> > from that - "the user must be able to read a PDF; the user must be able
> to
> > view pictures" etc.
>
> Well, sure, but what criteria do you use to decide what criteria should be
> part of the core set?
Common sense and usability knowledge :) We should simply decide what our
desktop should do and not do based on our intended target users. More below.
> A DTP app won't be part of core following what I
> propose, but "The user must be able to do DTP" seems a perfect fit to the
> "user should be able to do X" list.
> In other words, I'd argue that "the user must be able to do X" is a
> criteria
> that follows out of defining what 95% of the users use. It
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Wednesday 30 April 2014 13:04:16 Martin Klapetek wrote: > On Wed, Apr 30, 2014 at 10:48 AM, Jos Poortvliet wrote: > > But if anybody knows a good reason to sync, say so please. > > To be honest I don't see the point of my application actually joining the > joint release... Well, the only point would be to have some work be done for you: making the tarballs, little promo perhaps, translation freeze... Currently, we do synchronized releases for this reason, I thought. If the release team brings no benefit to application developers, then we can dump the synchronization of releases all together of course. And only have individual projects including Frameworks, Calligra, Amarok, Plasma (with some basic parts like systemsettings) and other individual apps on their own. > You cannot define "what 95% users use" because you don't have that data. Filemanagement, picture viewer, document viewer... Most if it is reasonably clear-cut. I don't think you have a lot of vague stuff there but maybe I'm wrong. In any case, I'd simply NOT include something that is unclear and let users/distributions pick what they want. It isn't like they don't do that now (eg have Firefox as browser, gimp as image editor). > We > don't know our users. We don't even know how many there are, let alone > what they use. True, and that is a problem. Imho we would greatly benefit from a anonymous usage tracking functionality like Firefox includes. We could even make it opt-in instead of opt-out... I bet our usability team would drool all over data generated by something like that. > This is simply impossible and even dangerous, because 95% > of the users around me don't use Nepomuk/Baloo, should it then be removed? That's part of Frameworks or Plasma (?) anyway. > And if not, where do we draw the line then? > > On the other hand, we can define our target users; users we are writing the > software for (just like the usability "personas"). From there we can make > a list of things we want these target users to be able to do in the basic > desktop + basic apps, then look into our applications set and make the > "core" list. Note that this should not be a promo/marketing effort, but > rather usability one. Yeah, that is an entirely different thing. Not even remotely related to release management, imho. If we go there, we should also start to define and develop applications we don't yet have, or which need more love and attention, and put resources on those. We just can't do that with our current community collaboration setup in KDE. Not that I don't WANT to do it, but it isn't realistic as most people work on what THEY think is useful, not what some group of people or committee has deemed useful. Now, changing that would require* a group of individuals and (ideally) company(s) to commit a quantifiable amount of resources. So a plan can be made, and it can be executed, and you know it will happen with reasonable certainty. Then, perhaps, volunteers will pitch in. Or not. I think that's great, and cool, and can give us directions and accomplish great things and seems a bit like what Blue Systems does (but without, afaik, talking much about it in public - or at least, not exactly on the dot or such places). (note that this is kind of what Red Hat does in GNOME although it seems to come with quite a bit of social pressure against ppl who don't like what the Lead Designer Deity decides. I'd rather not duplicate that specific part) But I don't think it is a great idea to let our plans for future release scheduling depend on the creation and execution of such a plan. It just seems to big to me, and you might have noticed over the last years - I'm not a fan of 'big plans' as they have a very strong tendency to fail and leave a mess behind. * another way would be to forbid ppl to work on anything except things that fit The Grand Plan but I think it is clear that that is something we never want - and that probably wouldn't succeed in much more than killing KDE. > Cheers ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On 25 April 2014 22:12, Jos Poortvliet wrote: > On Thursday 24 April 2014 23:23:28 Jaroslaw Staniek wrote: >> On 22 April 2014 11:31, Mario Fux wrote: >> > Proposal: >> > Reduce the amount of KDE Core Apps according to a definition and release >> > the other apps in independent groups or suites like e.g. KDE Edu, KDE >> > Games, KDE PIM, Amarok or the Calligra Suite. >> > >> > Details: >> > We could decide on a group of KDE Core Apps (for the Desktop) based on a >> > definition like this: >> > - Allows you to manage your files and documents (e.g. => Dolphin, Ark, >> > K3b?) - Allows you to view documents and pictures (e.g. => Okular and >> > Gwenview) - Allows you to watch movies and listen to music (e.g. => >> > Dragon and Juk) - Allows you to administrate and manage your system (e.g. >> > => print-manager, ksane, systemsettings) >> > - Allows you to do this in an accessible way*: (e.g. => Simon, Jovie and >> > Co) - Allows you to write some notes and find them again (e.g. => >> > Kate/Kwrite) >> One note, I would not call Kate as core app. It rather belongs to a >> Specialized Apps group (with KDevelop, Konsole and... Kexi for >> example). Anyone unconvinced can look at, say, Kate's Tools menu :) >> >> So my idea could be to start from optics of basic user, discovering >> personas, their >> goals or needs, and then realistic groups would appear naturally. >> BTW, does even "Core Apps" sound fine for the basic user? > > Core Apps is horrible in any case, it should be something like the KDE > Essentials. [..] I'd like to say thank you to everyone that shares personal opinion. Here's mine. (While reading this please note that geek power users isn't a primary audience for apps I am contributing to) - 1 - I am in contact with people (Joe Users specialized in a non-IT stuff, and also many power users) that believe that with Calligra they are pulling "the KDE" so they say, thank you for now. This is unfortunate perception, phenomena that perhaps would be further analyzed. I believe Combining releases only makes this tougher. Note, the same time, similar people have no problem with running apps that are technically foreign to their desktops. Now see this extreme example: I met brilliant Linux individuals that use Notepad+ with Wine for editing. They somehow perceive Notepad+ their favourite for some (historic?) reason. Somehow, Notepad+ is not dragging alien technology, and it's light enough. It's subtle, someone feel fre to analyze that so we can see what to improve. And I do not mean just feature comparison with Kate. I do not see benefits of the proposal from my perspective, as author of large KDE apps and promotor of Qt and Frameworks (in random order). We're not controlling the deployment process, distros do so, and distros already have their versioning, maybe grouping. While this has known advantages, this is a rare situation in the IT industry, nearly everyone else ships apps independent of the OS release. Maybe only builtin apps on mobile are similar in this? I am not fan of too superficial "groups" of apps. To be specific, I am encouraging to first conduct mother/gradma test by asking for a perceived meaning of things and trying to explain. Ask whether they really care, how they feel with the extra information. How they get the software. - 2 - >From another optics: if we take a modern task-orientation into account, and own model of Activities, we'll notice that many apps belong to many groups of tasks. Someone wants to paste a rich text table into a mail app (and can't) and write a long report containing data tables. For both needs Calligra Words can be explicitly or implicitly used. Moreover both can be essential for someone. Well, Blender and Krita can be essential for many. They put their icons on the panel thus making personal, essential selection. Maybe features can be categorized much better, single app can belong to many categories. I can truly bear with reaction of geeks when old-school/childish versioning/naming is kept and promoted. They'll survive by composing extra in their minds. Long ago MS asked "Where do you want to go today?" Perhaps at first contact we should ask the user, what do you want to do today? - 3 - At project management level please also note a word from a Calligra contributor. The project is so huge that there's even lack of manpower for maintaining change logs or feature guides. Even specification of essential file formats take thousands of pages combined. 400+ dialogs. 400 services/types/plugins. I don't think syncing with joint releases wouldn't add to the manpower. I would avoid anything that narrows contributor base and user base. Secondly, our choice of release schedule for Calligra is already result of a nontrivial compromise. It's complex even now while we do not have released our Frameworks to the public, something that in my opinion can be expected as our differentiator. -- regards / pozdrawiam, Jaroslaw Staniek Kexi & Calligra & KDE | http://ca
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
El Dimecres, 30 d'abril de 2014, a les 10:48:44, Jos Poortvliet va escriure:
> On Monday 28 April 2014 11:08:34 Martin Klapetek wrote:
> > On Fri, Apr 25, 2014 at 10:12 PM, Jos Poortvliet <
> >
> > jospoortvlietstanburd...@gmail.com > wrote:
> > > I think the idea of grouping releases ('Sigma'?) is a good one. How
> > > about
> > > we
> > > start there. Let's give Applications more freedom, yet allow them to be
> > > part
> > > of the 'bunch', yes? Calligra, Amarok, the Extragear apps - they should
> > > be
> > > part of the KDE Applications. Fold it all in there, with more
> > > flexibility
> > > thanks to more regular (but non-mandatory) releases. Yes, everybody
> > > their
> > > own
> > > release numbers, no synchronization needed at all. Not every release
> > > needs
> > > every application, but perhaps for convenience of distro's we provide
> > > everything in a tarball- just not with updated version numbers. They can
> > > ship
> > > KDE Applications 2015.6 (?) and be sure to have all of them, but many of
> > > the
> > > apps might not be different from those in KDE Applications 2015.2.
> >
> > I think the release numbers should be all the same and perhaps even the
> > number of the "Sigma" release (also, we should come up with something else
> > than "Sigma" before it catches on and stays...like "SC"...unless we want
> > it
> > to stay). Otherwise it will be a mess imho - "KDE Applications 2015.6
> > contains Dolphin 5.2.1, Calligra 7.8, Amarok 4.6.4, Kontact 5.3.1" -- "KDE
> > Applications 2015.12 contains Dolphin 5.2.3, Calligra 8.1, Amarok 4.8.2,
> > Kontact 5.4.1"are those own version numbers really that important? It
> > could just as well be "Dolphin 2015.6" or "Amarok 2015.12" (or some other
> > numbers), but unified. More coherent, more clear, more simple. The
> > downside I see is that the apps' developers would need to commit to this
> > new policy, which might hit some resistance.
>
> Look at what we try to do here: message that our applications are separate
> and independent. There is nothing about Ktouch that requires Amarok, and
> Words is just fine without Kanagram. The fact that, on a release engineering
> level, we release them in batches - that is irrelevant for users. They just
> get the one app they want, be it for Windows, Mac, Linux, Android...
>
> Delivering it as a 'suite' with the same version numbers gives the
> impression they do belong together. But they don't - the only thing KDE
> software has in common is the people who make it. Functionally, you can use
> them anywhere, alone or in groups, separate or combined.
>
> Also - most apps wouldn't release with every sigma release, so more than
> half our applications is out of sync most of the time. Having Kontact and
> Gwenview 2014.8 and Words and Palapeli 2014.6 and Amarok 2015.2 all being
> the latest version seems more confusing than Kontact 1.8, Gwenview 2.3 etc
> etc on their own. That is what people are used too.
>
> I don't see a strong argument for syncing the release numbers, the confusing
> part doesn't convince me. There's plenty of different version numbers on
> your system atm ;-)
>
> But if anybody knows a good reason to sync, say so please.
There are a few reaons to sync releases:
* Most of the devels of "KDE Applications" apps don't want to do the releases
themselves after 15 years of a release team doing it for them
* Having synched release schedules for "KDE Applications" like we have done
for 15 years allows me to know easily if an application is on freeze or not,
if suddenly as a developer I have to keep track of 160 different release
schedules, count me out of doing fixes in those apps.
* We have lots of applications with "no real maintainer" but I can still go
there, fix something that is i18n related and know it will be release next
month with the next "KDE Applications" release, with your plan of "everyone
releases its own stuff" my fix would never reach the user.
Cheers,
Albert
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
El Dimecres, 30 d'abril de 2014, a les 21:36:14, Jaroslaw Staniek va escriure: > [..] > > I'd like to say thank you to everyone that shares personal opinion. Here's > mine. > > (While reading this please note that geek power users isn't a primary > audience for apps I am contributing to) > > - 3 - > > At project management level please also note a word from a Calligra > contributor. The project is so huge that there's even lack of manpower > for maintaining change logs or feature guides. Even specification of > essential file formats take thousands of pages combined. 400+ dialogs. > 400 services/types/plugins. I don't think syncing with joint releases > wouldn't add to the manpower. I would avoid anything that narrows > contributor base and user base. > Secondly, our choice of release schedule for Calligra is already > result of a nontrivial compromise. It's complex even now while we do > not have released our Frameworks to the public, something that in my > opinion can be expected as our differentiator. Do you believe that splitting Calligra into something like 10 different releases would actually help with the lack of manpower? I have the feeling that it would probably help "the big guys", but I don't think it'd have a global positive "value" for all the projects that compose Calligra at the moment. But that is my "I have no clue about Calligra" opinion so I'd value yours :) Cheers, Albert ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
Albert Astals Cid ha scritto: > El Dimecres, 30 d'abril de 2014, a les 21:36:14, Jaroslaw Staniek va escriure: >> [..] >> >> I'd like to say thank you to everyone that shares personal opinion. Here's >> mine. >> >> (While reading this please note that geek power users isn't a primary >> audience for apps I am contributing to) >> >> - 3 - >> >> At project management level please also note a word from a Calligra >> contributor. The project is so huge that there's even lack of manpower >> for maintaining change logs or feature guides. Even specification of >> essential file formats take thousands of pages combined. 400+ dialogs. >> 400 services/types/plugins. I don't think syncing with joint releases >> wouldn't add to the manpower. I would avoid anything that narrows >> contributor base and user base. >> Secondly, our choice of release schedule for Calligra is already >> result of a nontrivial compromise. It's complex even now while we do >> not have released our Frameworks to the public, something that in my >> opinion can be expected as our differentiator. > > Do you believe that splitting Calligra into something like 10 different > releases would actually help with the lack of manpower? > > I have the feeling that it would probably help "the big guys", but I don't > think it'd have a global positive "value" for all the projects that compose > Calligra at the moment. > > But that is my "I have no clue about Calligra" opinion so I'd value yours :) I think there is a bit of confusion: the proposal about "unified release" is about the Application part of KDE SC + any other application which would join. A big project like Calligra is independent enough and it can have a separate schedule as it is now. Did I get it right? Ciao -- Luigi ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
El Dijous, 1 de maig de 2014, a les 15:02:36, Luigi Toscano va escriure: > Albert Astals Cid ha scritto: > > El Dimecres, 30 d'abril de 2014, a les 21:36:14, Jaroslaw Staniek va escriure: > >> [..] > >> > >> I'd like to say thank you to everyone that shares personal opinion. > >> Here's > >> mine. > >> > >> (While reading this please note that geek power users isn't a primary > >> audience for apps I am contributing to) > >> > >> - 3 - > >> > >> At project management level please also note a word from a Calligra > >> contributor. The project is so huge that there's even lack of manpower > >> for maintaining change logs or feature guides. Even specification of > >> essential file formats take thousands of pages combined. 400+ dialogs. > >> 400 services/types/plugins. I don't think syncing with joint releases > >> wouldn't add to the manpower. I would avoid anything that narrows > >> contributor base and user base. > >> Secondly, our choice of release schedule for Calligra is already > >> result of a nontrivial compromise. It's complex even now while we do > >> not have released our Frameworks to the public, something that in my > >> opinion can be expected as our differentiator. > > > > Do you believe that splitting Calligra into something like 10 different > > releases would actually help with the lack of manpower? > > > > I have the feeling that it would probably help "the big guys", but I don't > > think it'd have a global positive "value" for all the projects that > > compose > > Calligra at the moment. > > > > But that is my "I have no clue about Calligra" opinion so I'd value yours > > :) > I think there is a bit of confusion: the proposal about "unified release" is > about the Application part of KDE SC + any other application which would > join. A big project like Calligra is independent enough and it can have a > separate schedule as it is now. Did I get it right? I don't know, I don't see an unification proposal in this email thread at all, i see an "suitification" proposal that reads as splitting of schedules to me. Cheers, Albert > > Ciao ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
> There are a few reaons to sync releases: > * Most of the devels of "KDE Applications" apps don't want to do the > releases > themselves after 15 years of a release team doing it for them > * Having synched release schedules for "KDE Applications" like we have done > for 15 years allows me to know easily if an application is on freeze or not, > if suddenly as a developer I have to keep track of 160 different release > schedules, count me out of doing fixes in those apps. > * We have lots of applications with "no real maintainer" but I can still go > there, fix something that is i18n related and know it will be release next > month with the next "KDE Applications" release, with your plan of "everyone > releases its own stuff" my fix would never reach the user. +1 :) I can only say, with my Kate maintainer hat on: I have enough time, to fix the biggest faults, shout on people breaking the compile & tests, do some reviews and port Kate from KDE x to y. I don't have the time to think up release dates and package releases. I appreciate the work the KDE release team does in that area since ever! And I really think per application releases are just overkill for most applications. At the moment, I am happy to know: If somebody has KDE SC x.y installed, he has the state of Kate from that time. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Thursday 01 May 2014 14:50:44 Albert Astals Cid wrote:
> El Dimecres, 30 d'abril de 2014, a les 10:48:44, Jos Poortvliet va
escriure:
> > On Monday 28 April 2014 11:08:34 Martin Klapetek wrote:
> > > On Fri, Apr 25, 2014 at 10:12 PM, Jos Poortvliet <
> > >
> > > jospoortvlietstanburd...@gmail.com > wrote:
> > > > I think the idea of grouping releases ('Sigma'?) is a good one. How
> > > > about
> > > > we
> > > > start there. Let's give Applications more freedom, yet allow them to
> > > > be
> > > > part
> > > > of the 'bunch', yes? Calligra, Amarok, the Extragear apps - they
> > > > should
> > > > be
> > > > part of the KDE Applications. Fold it all in there, with more
> > > > flexibility
> > > > thanks to more regular (but non-mandatory) releases. Yes, everybody
> > > > their
> > > > own
> > > > release numbers, no synchronization needed at all. Not every release
> > > > needs
> > > > every application, but perhaps for convenience of distro's we provide
> > > > everything in a tarball- just not with updated version numbers. They
> > > > can
> > > > ship
> > > > KDE Applications 2015.6 (?) and be sure to have all of them, but many
> > > > of
> > > > the
> > > > apps might not be different from those in KDE Applications 2015.2.
> > >
> > > I think the release numbers should be all the same and perhaps even the
> > > number of the "Sigma" release (also, we should come up with something
> > > else
> > > than "Sigma" before it catches on and stays...like "SC"...unless we
> > > want
> > > it
> > > to stay). Otherwise it will be a mess imho - "KDE Applications 2015.6
> > > contains Dolphin 5.2.1, Calligra 7.8, Amarok 4.6.4, Kontact 5.3.1" --
> > > "KDE
> > > Applications 2015.12 contains Dolphin 5.2.3, Calligra 8.1, Amarok
> > > 4.8.2,
> > > Kontact 5.4.1"are those own version numbers really that important?
> > > It
> > > could just as well be "Dolphin 2015.6" or "Amarok 2015.12" (or some
> > > other
> > > numbers), but unified. More coherent, more clear, more simple. The
> > > downside I see is that the apps' developers would need to commit to
> > > this
> > > new policy, which might hit some resistance.
> >
> > Look at what we try to do here: message that our applications are
> > separate
> > and independent. There is nothing about Ktouch that requires Amarok, and
> > Words is just fine without Kanagram. The fact that, on a release
> > engineering level, we release them in batches - that is irrelevant for
> > users. They just get the one app they want, be it for Windows, Mac,
> > Linux, Android...
> >
> > Delivering it as a 'suite' with the same version numbers gives the
> > impression they do belong together. But they don't - the only thing KDE
> > software has in common is the people who make it. Functionally, you can
> > use them anywhere, alone or in groups, separate or combined.
> >
> > Also - most apps wouldn't release with every sigma release, so more than
> > half our applications is out of sync most of the time. Having Kontact and
> > Gwenview 2014.8 and Words and Palapeli 2014.6 and Amarok 2015.2 all being
> > the latest version seems more confusing than Kontact 1.8, Gwenview 2.3
> > etc
> > etc on their own. That is what people are used too.
> >
> > I don't see a strong argument for syncing the release numbers, the
> > confusing part doesn't convince me. There's plenty of different version
> > numbers on your system atm ;-)
> >
> > But if anybody knows a good reason to sync, say so please.
>
> There are a few reaons to sync releases:
> * Most of the devels of "KDE Applications" apps don't want to do the
> releases themselves after 15 years of a release team doing it for them
> * Having synched release schedules for "KDE Applications" like we have
> done for 15 years allows me to know easily if an application is on freeze
> or not, if suddenly as a developer I have to keep track of 160 different
> release schedules, count me out of doing fixes in those apps.
> * We have lots of applications with "no real maintainer" but I can still
> go there, fix something that is i18n related and know it will be release
> next month with the next "KDE Applications" release, with your plan of
> "everyone releases its own stuff" my fix would never reach the user.
Agreed - but not what I was asking. Sorry, I was purely talking about syncing
the version numbers - not about doing releases together. That saves work and
is a good thing. The above would be an answer to Martin Klaptek when he said:
> To be honest I don't see the point of my application actually joining the
> joint release...
Cheers,
Jos
> Cheers,
> Albert
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Thursday 01 May 2014 15:22:49 Albert Astals Cid wrote: > El Dijous, 1 de maig de 2014, a les 15:02:36, Luigi Toscano va escriure: > > Albert Astals Cid ha scritto: > > > El Dimecres, 30 d'abril de 2014, a les 21:36:14, Jaroslaw Staniek va > > escriure: > > >> [..] > > >> > > >> I'd like to say thank you to everyone that shares personal opinion. > > >> Here's > > >> mine. > > >> > > >> (While reading this please note that geek power users isn't a primary > > >> audience for apps I am contributing to) > > >> > > >> - 3 - > > >> > > >> At project management level please also note a word from a Calligra > > >> contributor. The project is so huge that there's even lack of manpower > > >> for maintaining change logs or feature guides. Even specification of > > >> essential file formats take thousands of pages combined. 400+ dialogs. > > >> 400 services/types/plugins. I don't think syncing with joint releases > > >> wouldn't add to the manpower. I would avoid anything that narrows > > >> contributor base and user base. > > >> Secondly, our choice of release schedule for Calligra is already > > >> result of a nontrivial compromise. It's complex even now while we do > > >> not have released our Frameworks to the public, something that in my > > >> opinion can be expected as our differentiator. > > > > > > Do you believe that splitting Calligra into something like 10 different > > > releases would actually help with the lack of manpower? > > > > > > I have the feeling that it would probably help "the big guys", but I > > > don't > > > think it'd have a global positive "value" for all the projects that > > > compose > > > Calligra at the moment. > > > > > > But that is my "I have no clue about Calligra" opinion so I'd value > > > yours > > > > > > :) > > > > I think there is a bit of confusion: the proposal about "unified release" > > is about the Application part of KDE SC + any other application which > > would join. A big project like Calligra is independent enough and it can > > have a separate schedule as it is now. Did I get it right? > > I don't know, I don't see an unification proposal in this email thread at > all, i see an "suitification" proposal that reads as splitting of > schedules to me. Ok, perhaps what I wrote wasn't clear. You can't make decisions if you don't first talk about what it is you want. So, I'm going to assume here that we want something that: * little work for everybody * is flexible for app developers * gets software asap to our users * works for the distro's * is simple to understand Now you can pick any of those and get a it perfect for that one. Eg, a yearly release for ALL KDE software is awesome for promo and the release team. Not very flexible and doesn't get software quick to our users. A release whenever a developer wants would do the opposite. Etc. So, I thought to get rid of the X month schedule that apps have to fit into + separate releases for apps that don't want it. Especially now we have Frameworks AND applications AND Plasma AND Calligra AND amarok, AND bugfix releases, the current process results in multiple releases per month and a lot of work and boilerplate to be copied over (esp for bugfixes). I would think it makes more sense to get everything a bit more in line, including the apps and suites that now do their 'own' releases: this way, we can give them the benefit of the release team/tools doing some of the work for them. What I proposed is: * Let's do regular releases * ANY app (incl Calligra, as a suite or separate) can join each individual release point - or not. * Each app keeps their own release numbering, however they like it. The releasing is just for the engineering and promo. So, in this, we'd do something like a 'release point' every month. Jan release comes with Calligra 2.6, Amarok 2.7, Plasma 2016.1, Kate 5.8, Ark 2.2, Dolphin 2.3, KDE PIM 2.5, Frameworks 5.13 and so on. Feb release comes with Frameworks 5.13, Kate 5.9, Kget 3.3, ReKonq 5.6, and so on. Frameworks and Kate are on a monthly release cycle (that's really the plan for Frameworks, for Kate I just made that up). The others have different cycles - eg Plasma will release again in April with 2016.4, Ark might not release for another 8 months, Amarok comes in October etcetera. I would also suggest that the stability releases go into this as well, taking care of that too. Could of course be on a separate date: do app releases in the 1st week of the month, bugfix releases in the 3rd week. How does this fit the requirements? * as little work as possible * we know there's a release every month. That might seem more often than now, but honestly - we DO have releases *multiple times* per month already. We would certainly have to adjust (or create) processes and scripts, but I bet this can be automated to a great degree. By also taking care of Calligra and Amarok and monthly stability, we get far less work, at least for the side (promo) I can see. * is f
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Friday 02 of May 2014 19:53:47 Jos Poortvliet wrote: > * we know there's a release every month. That might seem more often than > now, but honestly - we DO have releases *multiple times* per month already. Not at the same rate as it will go, I think: one thing is to release (these days) 4.11.something for workspace + 4.12.something (already stable) + 4.13.something, another thing is to have full mix-and-matched releases also of big stuff. I think it means a neverending run. Ciao -- Luigi ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
Hi Jos, On Fri, May 2, 2014 at 7:53 PM, Jos Poortvliet wrote: ... > So, I thought to get rid of the X month schedule that apps have to fit into + > separate releases for apps that don't want it. Especially now we have > Frameworks AND applications AND Plasma AND Calligra AND amarok, AND bugfix > releases, the current process results in multiple releases per month and a > lot of work and boilerplate to be copied over (esp for bugfixes). Could you just please leave Amarok out of your examples? It makes no sense as Amarok was never released with KDE, and it is highly unlikely it ever will, and you are only adding confusion. So please, use examples that make sense, e.g the software projects that were/are part of the KDE SC release. Just my 2 cts. Regards, Myriam -- Proud member of the Amarok and KDE Community Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300) ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Saturday 03 May 2014 09:58:14 Myriam Schweingruber wrote: > Hi Jos, > > On Fri, May 2, 2014 at 7:53 PM, Jos Poortvliet > wrote: > > ... > > > So, I thought to get rid of the X month schedule that apps have to fit > > into + separate releases for apps that don't want it. Especially now we > > have Frameworks AND applications AND Plasma AND Calligra AND amarok, AND > > bugfix releases, the current process results in multiple releases per > > month and a lot of work and boilerplate to be copied over (esp for > > bugfixes). > Could you just please leave Amarok out of your examples? It makes no > sense as Amarok was never released with KDE, and it is highly unlikely > it ever will, and you are only adding confusion. So please, use > examples that make sense, e.g the software projects that were/are part > of the KDE SC release. Just curious - why would Amarok never be released by the KDE release team? Note that I propose to dump the SC and all that - I just propose that the release team takes care of all releases, syncing them monthly, just to simplify the work done for releasing. There is no connection other than that. > Just my 2 cts. Well, my idea might make no sense anyway, I'm just looking for a way to express that Kpotatoguy is no more related to Kanagram than Amarok is. Kanagram and Kpotatoguy benefit from the release team doing the release work, but Amarok not - why not level the playing field, simplify things? > Regards, Myriam ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Sat, May 3, 2014 at 11:50 AM, Jos Poortvliet wrote: > On Saturday 03 May 2014 09:58:14 Myriam Schweingruber wrote: >> Hi Jos, >> >> On Fri, May 2, 2014 at 7:53 PM, Jos Poortvliet >> wrote: >> >> ... >> >> > So, I thought to get rid of the X month schedule that apps have to fit >> > into + separate releases for apps that don't want it. Especially now we >> > have Frameworks AND applications AND Plasma AND Calligra AND amarok, AND >> > bugfix releases, the current process results in multiple releases per >> > month and a lot of work and boilerplate to be copied over (esp for >> > bugfixes). >> Could you just please leave Amarok out of your examples? It makes no >> sense as Amarok was never released with KDE, and it is highly unlikely >> it ever will, and you are only adding confusion. So please, use >> examples that make sense, e.g the software projects that were/are part >> of the KDE SC release. > > Just curious - why would Amarok never be released by the KDE release team? > > Note that I propose to dump the SC and all that - I just propose that the > release team takes care of all releases, syncing them monthly, just to > simplify the work done for releasing. There is no connection other than that. > >> Just my 2 cts. > > Well, my idea might make no sense anyway, I'm just looking for a way to > express that Kpotatoguy is no more related to Kanagram than Amarok is. > Kanagram and Kpotatoguy benefit from the release team doing the release work, > but Amarok not - why not level the playing field, simplify things? Very simple: we try to get our releases out for the users and try to get into major distributions (not rolling ones), not for our own schedule's sake. And fixed release cycles are one thing, but the availability of the devs to push and polish their work is another one. Also: doing our own release in Amarok might look like more work, but we reach a greater audience than if we would stick into a KDE releases x.y.z and get a one liner mention in an endless list nobody ever reads anyway. When did anybody here read the full release text of the KDE SC releases, but those who wrote them? The longer it gets, the less likely anybody would read it, don't forget the tl::dr attitude of most people I fear we are again doing a lot of blabla but nobody thinks about the users perspective as usual. I understand if kdelibs devs or Solid or whatever underlying structure they work on don't think of users as their first target, but that is certainly not so for applications like Amarok. So if everybody would take a step back and think of to whom and where and how we want to achieve a better distribution, then strict release schedules, regardless of the actual length, are not really helpful, they are a constraint to people who work in their free time and we try to apply company rules to them. That just doesn't work. Alienating the non-rolling distributions by our new schedules doesn't help either, btw. Also: changing names all the time and making releases for "KDE sc and x and y and z and plasma and don't call it KDE" are just not working, did ever anybody of you got aware that the whole rebranding to "KDE is not what we release, it's a community" is a complete and utter failure? I stopped long ago correcting people who call what they get on their desktop "KDE" and not "KDE SC with plasma desktop" or whatever is the "official" name we should use. It just doesn't work. Period. So let's get the perspective right: people want KDE, and there are already tons of posts out there in the web where people don't call it Frameworks5 but KDE5, and not even KDE devs commenting on those posts correct that anymore. Make a search and you will get aware of the reality, stop pretending it didn't happen. I think we talk about how we would like things to be instead of facing realities and work with facts. Regards, Myriam -- Proud member of the Amarok and KDE Community Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300) ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Sat, May 3, 2014 at 2:19 PM, Myriam Schweingruber wrote: > > Very simple: we try to get our releases out for the users and try to > get into major distributions (not rolling ones), not for our own > schedule's sake. And fixed release cycles are one thing, but the > availability of the devs to push and polish their work is another one. > Also: doing our own release in Amarok might look like more work, but > we reach a greater audience than if we would stick into a KDE releases > x.y.z and get a one liner mention in an endless list nobody ever reads > anyway. When did anybody here read the full release text of the KDE SC > releases, but those who wrote them? The longer it gets, the less > likely anybody would read it, don't forget the tl::dr attitude of most > people > I fear we are again doing a lot of blabla but nobody thinks about the > users perspective as usual. I understand if kdelibs devs or Solid or > whatever underlying structure they work on don't think of users as > their first target, but that is certainly not so for applications like > Amarok. So if everybody would take a step back and think of to whom > and where and how we want to achieve a better distribution, then > strict release schedules, regardless of the actual length, are not > really helpful, they are a constraint to people who work in their free > time and we try to apply company rules to them. That just doesn't > work. Alienating the non-rolling distributions by our new schedules > doesn't help either, btw. > With my KDE Telepathy hat on (as a main co-maintainer and the dude that does every other release), I'm putting +1 to that. I keep seeing that the joint release would be "simpler", but to whom? The release people (doing the packages) would suddenly have bazillion new packages to do (just KTp has ~14 and it varies). I kinda don't want to hand our release job to someone else as it's a bit specific process and afaik it's not the same as the rest of KDE apps, so handing this over would actually put *more* complexity onto the release team as suddenly they would have to handle lots of apps with different release processes. As for being simpler for promo - well, maybe. But the promo team would ask us "hey, can you give us some text about your release" and we would have to write one, but we do so now as well, except we can do bigger posts. Plus, we would get lost in the endless list, like Myriam said. We actually used to align our release with KDE SC but then decided to have some offset as our impact to the users and media was far less than when released standalone. True story. I'm not sure if it would be simpler for translators either - sure, there would be a "global" string freeze every month the same day, but it seems to me like lots of work suddenly cumulates at once. But this is just my thinking and I'm no translator. Well I don't know, I don't want to be the nay-sayer, but these are my thoughts on that. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
I'm putting this reply separately as it's not directly related to the previous one... On Sat, May 3, 2014 at 2:19 PM, Myriam Schweingruber wrote: > > Also: changing names all the time and making releases for "KDE sc and > x and y and z and plasma and don't call it KDE" are just not working, > did ever anybody of you got aware that the whole rebranding to "KDE is > not what we release, it's a community" is a complete and utter > failure? I stopped long ago correcting people who call what they get > on their desktop "KDE" and not "KDE SC with plasma desktop" or > whatever is the "official" name we should use. It just doesn't work. > Period. > I think we have a great chance now, to start fresh with the upcoming release. But we have to get it right and we don't have much time left. > So let's get the perspective right: people want KDE, and there are > already tons of posts out there in the web where people don't call it > Frameworks5 but KDE5, and not even KDE devs commenting on those posts > correct that anymore. Make a search and you will get aware of the > reality, stop pretending it didn't happen. > The current situation is less than fortunate, indeed. But it's not that bad I think. There is a general knowledge in the world what Frameworks are (although I see it called "KDE Framework" a lot as one single framework is more common in IT world; Qt is a framework too after all (no trailing s)), the rest is a bit blurry, so people just go "KDE5" as it's simple and everybody understands what is meant by that. My idea, which might be a complete nonsense, is to figure out the new overall branding for our software, keep it all simple, drop the technical accuracy (users don't care about technical stuff...so many times we have said that and then we have put it right into our main brand names) and be bold about it. No hiding it in the release text, make it big, clear and bold - "The software is no longer KDE, we're now". And make it big promo. It can never succeed if it will be just one or two sentences in the release text. People need to get slapped in the face with it for it to have any effect. Twice. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Saturday, May 3, 2014, Martin Klapetek wrote: called "KDE Framework" a lot as one single framework is more common in IT world; Qt is a framework too after all (no trailing s)), the rest is a bit blurry, so people just go "KDE5" as it's simple and everybody understands what is meant by that. > My idea, which might be a complete nonsense, is to figure out the new overall branding for our software, keep it all simple, drop the technical accuracy (users don't care about technical stuff...so many times we have said that and then we have put it right into our main brand names) and be bold about it. No hiding it in the release text, make it big, clear and bold - "The software is no longer KDE, we're now". And make it big promo. It can never succeed if it will be just one or two sentences in the release text. People need to get slapped in the face with it for it to have any effect. Twice. This can work if (and probably only if) there won't be any big, SC-style release amymore, or at least significantly downscaled (windowmanager, desktop, filemanager, not much more) Having separate releases for pretty much everything else. On our side i realize that is much more work. So. How this will be for users? It will be significantly worse on a normal distribution release cycle. It will be significantly better if every less than core application is distributed on a rolling-like cycle (only applications tough, not the whole distribution) Probably most distributions would never ever do anything like that, so not that useful to even talk about it. But those are my 2c on the best case scenario ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Saturday, 2014-05-03, 16:56:05, Martin Klapetek wrote: > I'm putting this reply separately as it's not directly related to the > previous one... > > On Sat, May 3, 2014 at 2:19 PM, Myriam Schweingruber wrote: > > Also: changing names all the time and making releases for "KDE sc and > > x and y and z and plasma and don't call it KDE" are just not working, > > did ever anybody of you got aware that the whole rebranding to "KDE is > > not what we release, it's a community" is a complete and utter > > failure? I stopped long ago correcting people who call what they get > > on their desktop "KDE" and not "KDE SC with plasma desktop" or > > whatever is the "official" name we should use. It just doesn't work. > > Period. > > I think we have a great chance now, to start fresh with the upcoming > release. But we have to get it right and we don't have much time left. I agree with Marco that this will be more natural once we don't have an SC release anymore. The desktop workspace product will probably still be refered to as "KDE" but the applications will be easier to conceive as separated products when they are not released at the same time as the workspace. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
Good morning dear ladies and gentlemen This is finally an attempt of a summary of this thread. Please see as well the thread "KDE applications 4.14 LTS or 4.15?" on kde-devel and its summary. But first some critic to myself. The proposal was too broad and not specific enough. First a summary of the sub-threads: - Luigi: There was a plan to split KDEToys -- Albert: shouldn't be a problem - Aleix: Pro and contra for KDE Core Apps concept. relation between them and Plasma, Vision needed? KDE Edu wants to know about KF5 based releases. - Albert: There are no real modules, team maintainance difficult (needs specific knowledge), proposal doesn't make much sense -- Aleix: Plasma needs apps to work great, lack of a definition of this set atm --- Vishesh: not "core", healthy competition (who is in "core"?), closer to Plasma Albert: no "Plasma Okular", important message: Okular works elsewhere too - Inge: +1, Difficulty between great integration with Plasma and apps works on other "Desktops"/Systems as well: Apps should make clear in name what they do: e.g. "Okular Document Viewer" -- Agustín: taking a big risk on diluting the brand "KDE" --- Aleix: Does Dolphin depend on Plasma? vision-wise not technically Inge: "Plasma is not dependent on Dolphin. But the user experience given by Plasma is dependent on having an application like Dolphin. The Plasma desktop needs to have something like Dolphin to be a complete desktop" - Jaroslaw: Kate is not a "core" app; take basic user or persona perspectives -- Jos: not "Core Apps" => "KDE Essentials"?, +1 to Agustin, "KDE Applications" should have a wider scope (incl. Calligra, Amarok and Co), more freedom if apps want to be in a release or not, different version #, something like a "KDE Applications SC" for distros, +1 for accessibility -- "KDE Essentials. Very bare: Konsole, Kwrite, Dolphin, Ark, Okular, Gwenview, you can imagine. The criteria: EVERY user (well, ~90%), swapable with others" No duplicates. Release team decides based on discussions. --- Martin: Unified versions, written goals for "KDE Essentials", otherwise +1 Jos: independent apps for different platforms => no unified versions - Martin: Why should an app join a release? Define target users, personas -- Jos: "we would greatly benefit from a anonymous usage tracking" -- Albert: Reasons to join a release (Christoph and Jos: +1) --- Jaroslaw: "We're not controlling the deployment process" & "many apps belong to many groups of tasks" & experience of Calligra Albert & Co: Splitting or Unification/Suitification? - Jos: compromise of: => "get everything a bit more in line" * little work for everybody * is flexible for app developers * gets software asap to our users * works for the distro's * is simple to understand -- Myriam: Problem of releases with too much text (visibility of project) --- Martin: +1 Marco: Rolling releases of KDE apps My conclusions: - No matter what: "Core Apps" is not the name of choice! ;-) "KDE Essentials" is an alternative or "Basic Apps" - Plasma and the apps it needs to be a complete experience and work environment. E.g. Dolphin as the file manager (or other file managers?) => needs a discussion in Plasma? - Discuss about target users and what apps they need/tasks they want to fulfill => Something for the usability people? - Joined "KDE Application" releases make sense for a lot of people (see Albert's email for the good reasons) but they can offer more freedom to be part of such a release or not => see 4.14 thread above - We don't really know our user, how many they are and what they use => we need anonymous usage tracking (opt-in or opt-out) for our KF5 based software! - About the topic of building groups or suites. Many apps fit in many groups. And yes it became a rather big email (but it took me some hours to write it as well ;-). Best regards Mario ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
