Following up with the discussions that took place in the openSUSE conference, I would like to kick off a discussion that has as an objective to come up with a step-by-step plan on how to
- Make it ridiculously easy for the users to find & install the ridiculously good software
This has various possible technical solutions. But the output has to be:
- a "place" where the user can click and see the available cool software (ie: Chromium" not ie: libhenne-devel) with screenshots, ratings, comments
- The user should not care about repositories and their combination requisites, or strange signature dialogs
- Other pieces in the distro need to be integrated, or at least it would be nice to, for example we ship KPackageKit which is a lovely app if you show a bunch of apps separated by groups, but gets completely unusable if you show 2135 packages with strange names in one category in a simple list-view. Other pieces don't, like zypper, YaST2 which are mean to be used as package managers.
- Whatever new opportunities we are able to get done in the process. For example, Frank's project bretzel has components that fit int he backoffice, aiming for a one click publishing of software from the developer's side (using adrian's _service's) which fits ridiculously great in our build service story.
Cheers
On Tuesday, November 02, 2010 11:19:18 am Duncan Mac-Vicar P. wrote:
Following up with the discussions that took place in the openSUSE conference, I would like to kick off a discussion that has as an objective to come up with a step-by-step plan on how to
- Make it ridiculously easy for the users to find & install the
ridiculously good software
This has various possible technical solutions. But the output has to be:
- a "place" where the user can click and see the available cool software
(ie: Chromium" not ie: libhenne-devel) with screenshots, ratings, comments
- The user should not care about repositories and their combination
requisites, or strange signature dialogs
- Other pieces in the distro need to be integrated, or at least it would
be nice to, for example we ship KPackageKit which is a lovely app if you show a bunch of apps separated by groups, but gets completely unusable if you show 2135 packages with strange names in one category in a simple list-view. Other pieces don't, like zypper, YaST2 which are mean to be used as package managers.
- Whatever new opportunities we are able to get done in the process. For
example, Frank's project bretzel has components that fit int he backoffice, aiming for a one click publishing of software from the developer's side (using adrian's _service's) which fits ridiculously great in our build service story.
Cheers
Right now we have technically perfect tools for package installation. These tools support almost all options libzypp provides. That's okay as long as the target audience are administrators and technically experienced users who exactly know what they want to archive and know how package management works.
If we want to introduce a tool that aims usability we should ignore technical arguments while the initial discussion. There are no dependencies and no dependency conflicts, there are no patches, packages and so on. There is just a user how wants to write a letter or play a new game. The user might even not know the application's name he/she wants to install.
But there was a statement at the openSUSE Conference that openSUSE is the distribution for technical users and admins. If we also want to take newbies into account let's copy apple's solution, paint it green and put an openSUSE sticker on it. :-)
Thomas
On Tuesday 02 November 2010 13:09:23 Thomas Goettlicher wrote:
But there was a statement at the openSUSE Conference that openSUSE is the distribution for technical users and admins. If we also want to take newbies into account let's copy apple's solution, paint it green and put an openSUSE sticker on it. :-)
You mean we should create an "i[TM]Green Store"?
Well it should at least be as easy as such stores to 1. find and 2. install the needed "APP" (meaning application, and in the end a small set of packages).
But would not call it a "Store". If is GPL software that we are distributing this way we might append wrong assumptions to this tool. I'd rather see it as some kind of an easy, end-user oriented replacement for the current package selector that does not bother the user with any kind of technical details.
There are also openSUSE versions for Netbooks and Meego devices aso. It would be great if this "Store-like-thingy" (no idea yet how to call it) would run on each of these with the same look and feel.
Ciao, Daniel
On Tuesday, November 02, 2010 01:20:40 pm J. Daniel Schmidt wrote: [...]
There are also openSUSE versions for Netbooks and Meego devices aso. It would be great if this "Store-like-thingy" (no idea yet how to call it) would run on each of these with the same look and feel.
Why not to improve http://software.opensuse.org/search in a way that it is really user friendly? Let users rate the applications, add screenshots and descriptions. We'd just need to integrate it into the desktop, because there are a lot of openSUSE web pages almost nobody knows about. Having an easily findable link to the software search is essential.
Cheers Thomas
On 11/02/2010 01:32 PM, Thomas Goettlicher wrote:
On Tuesday, November 02, 2010 01:20:40 pm J. Daniel Schmidt wrote: [...]
There are also openSUSE versions for Netbooks and Meego devices aso. It would be great if this "Store-like-thingy" (no idea yet how to call it) would run on each of these with the same look and feel.
Why not to improve http://software.opensuse.org/search in a way that it is really user friendly? Let users rate the applications, add screenshots and descriptions. We'd just need to integrate it into the desktop, because there are a lot of openSUSE web pages almost nobody knows about. Having an easily findable link to the software search is essential.
You may consider this point "a technical" details, but for example, Franks infrastructure offers:
- API - 150.000+ userbase
Right now search.opensuse.org is that, a search engine that looks into build service packages, and changing that would basically mean writing a new application to be put on software.opensuse.org/search instead.
I am not sure what are Frank "requirements" for us. We talked about some points during the conference:
- where it could be hosted? Is it ok for the project for it to be hosted by a 3rd person? (we talked about moving data as well), could it be reachable from software.opensuse.org/search
On the other hand, I think opendesktop web frontend can be improved further from the user interface perspective, however it is ok for a start.
Then you have the other parts of the "user story". Once the user has a place where the apps are reated/voted, how do you get back to the installation in a simple and cool way. Right now One Click Install is not much of an improvement.
On Tue, 2010-11-02 at 11:19 +0100, Duncan Mac-Vicar P. wrote:
Following up with the discussions that took place in the openSUSE conference, I would like to kick off a discussion that has as an objective to come up with a step-by-step plan on how to
- Make it ridiculously easy for the users to find & install the
ridiculously good software This has various possible technical solutions. But the output has to be:
- a "place" where the user can click and see the available cool software
(ie: Chromium" not ie: libhenne-devel) with screenshots, ratings, comments
Isn't there any chance a partnership with a site like Freshmeat to include OBS links and interface /front-end them with an app that just shows applications with OBS links? They already have ratings, subscriptions, comments, etc...
2010/11/2 Duncan Mac-Vicar P. dmacvicar@suse.de:
Following up with the discussions that took place in the openSUSE conference, I would like to kick off a discussion that has as an objective to come up with a step-by-step plan on how to
- Make it ridiculously easy for the users to find & install the ridiculously
good software
This has various possible technical solutions. But the output has to be:
- a "place" where the user can click and see the available cool software
(ie: Chromium" not ie: libhenne-devel) with screenshots, ratings, comments
- The user should not care about repositories and their combination
requisites, or strange signature dialogs
- Other pieces in the distro need to be integrated, or at least it would be
nice to, for example we ship KPackageKit which is a lovely app if you show a bunch of apps separated by groups, but gets completely unusable if you show 2135 packages with strange names in one category in a simple list-view. Other pieces don't, like zypper, YaST2 which are mean to be used as package managers.
- Whatever new opportunities we are able to get done in the process. For
example, Frank's project bretzel has components that fit int he backoffice, aiming for a one click publishing of software from the developer's side (using adrian's _service's) which fits ridiculously great in our build service story.
Isn't that the idea behind http://software.opensuse-community.org/? What's the status?
On Tuesday, November 02, 2010 01:31:22 pm Cristian Morales Vega wrote:
2010/11/2 Duncan Mac-Vicar P. dmacvicar@suse.de:
Following up with the discussions that took place in the openSUSE conference, I would like to kick off a discussion that has as an objective to come up with a step-by-step plan on how to
- Make it ridiculously easy for the users to find & install the
ridiculously good software
This has various possible technical solutions. But the output has to be:
- a "place" where the user can click and see the available cool software
(ie: Chromium" not ie: libhenne-devel) with screenshots, ratings, comments
- The user should not care about repositories and their combination
requisites, or strange signature dialogs
- Other pieces in the distro need to be integrated, or at least it would
be nice to, for example we ship KPackageKit which is a lovely app if you show a bunch of apps separated by groups, but gets completely unusable if you show 2135 packages with strange names in one category in a simple list-view. Other pieces don't, like zypper, YaST2 which are mean to be used as package managers.
- Whatever new opportunities we are able to get done in the process. For
example, Frank's project bretzel has components that fit int he backoffice, aiming for a one click publishing of software from the developer's side (using adrian's _service's) which fits ridiculously great in our build service story.
Isn't that the idea behind http://software.opensuse-community.org/? What's the status?
Cool! Didn't know that something like this exists! That's exactly what I proposed in my last post.
Cheers Thomas
There was a keynote at the openSUSE conference on Saturday which was held by Frank Karlitschek. He talked about the Praetzel project, which includes, among other parts, an app-store and has currently ready three clients.
I tried to find the project and fialed - perhaps because I did not get the name correctly, as it is a word in the Bavarian dialect. As it is supported for MeeGo, which uses in genral the same update stack as openSUSE, it could be on option to use it at openSUSE.
Jiri
On Tuesday 02 November 2010 11:19:18 Duncan Mac-Vicar P. wrote:
Following up with the discussions that took place in the openSUSE conference, I would like to kick off a discussion that has as an objective to come up with a step-by-step plan on how to
- Make it ridiculously easy for the users to find & install the
ridiculously good software
This has various possible technical solutions. But the output has to be:
- a "place" where the user can click and see the available cool software
(ie: Chromium" not ie: libhenne-devel) with screenshots, ratings, comments
- The user should not care about repositories and their combination
requisites, or strange signature dialogs
- Other pieces in the distro need to be integrated, or at least it would
be nice to, for example we ship KPackageKit which is a lovely app if you show a bunch of apps separated by groups, but gets completely unusable if you show 2135 packages with strange names in one category in a simple list-view. Other pieces don't, like zypper, YaST2 which are mean to be used as package managers.
- Whatever new opportunities we are able to get done in the process. For
example, Frank's project bretzel has components that fit int he backoffice, aiming for a one click publishing of software from the developer's side (using adrian's _service's) which fits ridiculously great in our build service story.
Cheers
Hi,
yes. We don´t have an website for this project yet. :-)
But I indeed suggest to use the OCS API and one of the existing client for openSUSE. MeeGo will use the same system in the next release and others are also interested. So this could be a nice area of collaboration between different distributions. It´s also good for openSUSE because most of the AppStore system already exists. It shouldn´t be a problem to launch it for 11.4
Open TODOs
- Do a meeting with people from other distributions to try to convince everybody to use the same API. This would be good for the complete Linux ecosystem. - Find a name for the openSUSE AppStore client. Something like "AppStore", "SoftwareCenter", SoftwareInstaller, .. - Create an icon for the client. - Take the existing GHNS client and convert it into a standalone Desktop client. (very easy) - Find a domainname for the website (foo.opensuse.org or opensuse-foo.org, ...) - Decision how the applications are maintained. (scanning of a existing repository and extracting metadata or user generated entries with ratings, ...) - Do the backend (Frank) - more I forgot :-)
I plan to do a proof of concept in the next few days.
We could finalize everything during a 2-3 days developer meeting.
What do you think?
Cheers Frank
On 02.11.2010, at 14:47, Jiri Srain wrote:
There was a keynote at the openSUSE conference on Saturday which was held by Frank Karlitschek. He talked about the Praetzel project, which includes, among other parts, an app-store and has currently ready three clients.
I tried to find the project and fialed - perhaps because I did not get the name correctly, as it is a word in the Bavarian dialect. As it is supported for MeeGo, which uses in genral the same update stack as openSUSE, it could be on option to use it at openSUSE.
Jiri
On Tuesday 02 November 2010 11:19:18 Duncan Mac-Vicar P. wrote:
Following up with the discussions that took place in the openSUSE conference, I would like to kick off a discussion that has as an objective to come up with a step-by-step plan on how to
- Make it ridiculously easy for the users to find & install the
ridiculously good software
This has various possible technical solutions. But the output has to be:
- a "place" where the user can click and see the available cool software
(ie: Chromium" not ie: libhenne-devel) with screenshots, ratings, comments
- The user should not care about repositories and their combination
requisites, or strange signature dialogs
- Other pieces in the distro need to be integrated, or at least it would
be nice to, for example we ship KPackageKit which is a lovely app if you show a bunch of apps separated by groups, but gets completely unusable if you show 2135 packages with strange names in one category in a simple list-view. Other pieces don't, like zypper, YaST2 which are mean to be used as package managers.
- Whatever new opportunities we are able to get done in the process. For
example, Frank's project bretzel has components that fit int he backoffice, aiming for a one click publishing of software from the developer's side (using adrian's _service's) which fits ridiculously great in our build service story.
Cheers
-- Regards,
Jiri Srain YaST Team Leader
SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
-- Frank Karlitschek karlitschek@kde.org
On 11/02/2010 04:24 PM, Frank Karlitschek wrote:
Hi,
yes. We don´t have an website for this project yet. :-)
But I indeed suggest to use the OCS API and one of the existing client for openSUSE.
What do you mean with existing client for openSUSE?
MeeGo will use the same system in the next release and others are also interested. So this could be a nice area of collaboration between different distributions. It´s also good for openSUSE because most of the AppStore system already exists. It shouldn´t be a problem to launch it for 11.4
Open TODOs
- Do a meeting with people from other distributions to try to convince everybody to use the same API. This would be good for the complete Linux ecosystem.
Makes sense
- Find a name for the openSUSE AppStore client. Something like "AppStore", "SoftwareCenter", SoftwareInstaller, ..
- Create an icon for the client.
- Take the existing GHNS client and convert it into a standalone Desktop client. (very easy)
Get Hot New Stuff? How to hook that up with the app installation?
- Find a domainname for the website (foo.opensuse.org or opensuse-foo.org, ...)
- Decision how the applications are maintained. (scanning of a existing repository and extracting metadata or user generated entries with ratings, ...)
- Do the backend (Frank)
- more I forgot :-)
I plan to do a proof of concept in the next few days.
We could finalize everything during a 2-3 days developer meeting.
On 03.11.2010, at 13:31, Duncan Mac-Vicar P. wrote:
On 11/02/2010 04:24 PM, Frank Karlitschek wrote:
Hi,
yes. We don´t have an website for this project yet. :-)
But I indeed suggest to use the OCS API and one of the existing client for openSUSE.
What do you mean with existing client for openSUSE?
Sorry for the bad phrase. I mean I suggest to use libattica for the communication with the server/repository and use the existing KDE GHNS client as native AppStore client for the desktop. It´s of course possible to write a GTK+ bases frontend on top of libattica if the GNOME community don´t like a Qt based AppStore. I already discussed this with Vincent.
MeeGo will use the same system in the next release and others are also interested. So this could be a nice area of collaboration between different distributions. It´s also good for openSUSE because most of the AppStore system already exists. It shouldn´t be a problem to launch it for 11.4
Open TODOs
- Do a meeting with people from other distributions to try to convince everybody to use the same API. This would be good for the complete Linux ecosystem.
Makes sense
- Find a name for the openSUSE AppStore client. Something like "AppStore", "SoftwareCenter", SoftwareInstaller, ..
- Create an icon for the client.
- Take the existing GHNS client and convert it into a standalone Desktop client. (very easy)
Get Hot New Stuff? How to hook that up with the app installation?
It´s very easy to transform the existing GHNS app into an AppStore client. We only have to feed in the new application categories and add a openSUSE branding with nice colors, logo, name and so on. The user get´s a link to an ymp file if he/she clikcs on install. We could use the existing system packagekit/yast system to handle the installation of the new application.
- Find a domainname for the website (foo.opensuse.org or opensuse-foo.org, ...)
- Decision how the applications are maintained. (scanning of a existing repository and extracting metadata or user generated entries with ratings, ...)
- Do the backend (Frank)
- more I forgot :-)
I plan to do a proof of concept in the next few days.
We could finalize everything during a 2-3 days developer meeting.
-- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
-- Frank Karlitschek karlitschek@kde.org
On 11/02/2010 04:24 PM, Frank Karlitschek wrote:
Hi,
yes. We don´t have an website for this project yet. :-)
But I indeed suggest to use the OCS API and one of the existing client for openSUSE.
BTW, as we are also looking into dropping our KUpdaterApplet custom PackageKit client and using the upstream KPackageKit, I was researching how to make those nice clients show applications. I was shocked with all the infrastructure that is already there.
https://github.com/hughsie/app-install/blob/master/docs/app-install-v2.txt
Is the app-install specification of PackageKit, drafted by Richard and Sebastian Heinlein (so two different distros already).
The original idea is to have one package per repo with the application metadata, that ships the data that is added to /var/lib/app-install/desktop.db, however I never liked this solution.
The nice thing is: KPackageKit already show the applications automatically if that database is there.
The thing is: We could have a small tool that queries the OCS API for the openSUSE applications (may be passing some additional HTTP headers like the distro version) and write this database. This could be done as a cron job even. If that does not work we still can try other approaches, like generating app metadata once from the APIs and shipping those in the repositories.
The result is something like: http://blogs.gnome.org/hughsie/2010/09/07/linux-and-application-installing/
Having the client tools supporting this, plus a way to install the app from the web appstore or the GHNS client (what Frank mentioned in the previous email) would give us a great concrete starting point. What do you think?
* Of course for us, in addition gives us the ability to drop the updater applet) ** KPackageKit will be renamed Apper or something like that *** Richard is open to add changes to the schema/spec if it help our neeeds.
On 03.11.2010, at 14:29, Duncan Mac-Vicar P. wrote:
On 11/02/2010 04:24 PM, Frank Karlitschek wrote:
Hi,
yes. We don´t have an website for this project yet. :-)
But I indeed suggest to use the OCS API and one of the existing client for openSUSE.
BTW, as we are also looking into dropping our KUpdaterApplet custom PackageKit client and using the upstream KPackageKit, I was researching how to make those nice clients show applications. I was shocked with all the infrastructure that is already there.
https://github.com/hughsie/app-install/blob/master/docs/app-install-v2.txt
Is the app-install specification of PackageKit, drafted by Richard and Sebastian Heinlein (so two different distros already).
The original idea is to have one package per repo with the application metadata, that ships the data that is added to /var/lib/app-install/desktop.db, however I never liked this solution.
The nice thing is: KPackageKit already show the applications automatically if that database is there.
The thing is: We could have a small tool that queries the OCS API for the openSUSE applications (may be passing some additional HTTP headers like the distro version) and write this database. This could be done as a cron job even. If that does not work we still can try other approaches, like generating app metadata once from the APIs and shipping those in the repositories.
The result is something like: http://blogs.gnome.org/hughsie/2010/09/07/linux-and-application-installing/
Having the client tools supporting this, plus a way to install the app from the web appstore or the GHNS client (what Frank mentioned in the previous email) would give us a great concrete starting point. What do you think?
This sounds interesting. The drawback of a static db approach is that the more interactive features like rating, comments, suggest application to friends, social features and other advanced features do not work.
This was the approach we had with the old GHNS where we used static xml files for the package data. Now KDE switched to OCS as real REST based client/server protocol where more interactive features are possible.
I think OCS is the more powerful approach.
- Of course for us, in addition gives us the ability to drop the updater applet)
** KPackageKit will be renamed Apper or something like that *** Richard is open to add changes to the schema/spec if it help our neeeds.
Cheers Frank
-- Frank Karlitschek karlitschek@kde.org
On 11/04/2010 11:21 AM, Frank Karlitschek wrote:
This sounds interesting. The drawback of a static db approach is that the more interactive features like rating, comments, suggest application to friends, social features and other advanced features do not work.
This was the approach we had with the old GHNS where we used static xml files for the package data. Now KDE switched to OCS as real REST based client/server protocol where more interactive features are possible.
I think OCS is the more powerful approach.
Sure, for the appstore I think something like GHNS is the way to go. However we use PackageKit for the updates (as an applet), and it would be good to have it integrated as well, so that if an update comes, and there is appdata for it, you see the update as one app.
What do you think?
On 11/04/2010 12:52 PM, Duncan Mac-Vicar P. wrote:
This was the approach we had with the old GHNS where we used static xml files for the package data. Now KDE switched to OCS as real REST based client/server protocol where more interactive features are possible.
I think OCS is the more powerful approach.
Sure, for the appstore I think something like GHNS is the way to go. However we use PackageKit for the updates (as an applet), and it would be good to have it integrated as well, so that if an update comes, and there is appdata for it, you see the update as one app.
What do you think?
btw, Daniel Nicoletti (KPackageKit developer) is also very open to integrate the Application support so it can also use the OCS API directly in addition to the desktop.db thing.
So we could start with a helper to pull some app data from OCS into desktop.db while KPackageKit gets real OCS support. At least it would solve our problem of a friendly updater.
The need for a packagekit based updater is that we have features like notifications of patch messages, distribution upgrade notifications and start of the dist-upgrade workflow, etc.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/04/2010 01:55 PM, Duncan Mac-Vicar P. wrote: [...]
So we could start with a helper to pull some app data from OCS into desktop.db while KPackageKit gets real OCS support. At least it would solve our problem of a friendly updater.
Sorry but I don't see the relationship between "applications" and "packages". The one big thing about an """AppStore""" is that we need to show "applications" to the end-user, and not packages, where applications are actually bundles of 1-n packages.
Let's just have the existing infrastructure handle package updates when it comes to patches, upgrades and fixes.
This is an entirely different beast altogether.
And we really have to make some decisions upfront because from a technical perspective, they do make a big difference. One key item is whether we want those "applications" to - - be assembled/defined manually through user/admin input - - be automatically assembled from package repositories, through heuristics (*) - - something in-between, where package repository metadata is assembled through user/admin input
(*) That's the path we took for the Software Portal (**), some heuristics having been implemented there (such as looking for .desktop files in the package, match packages on their %{SOURCERPM} tag to assemble them as an application, etc...).
(**) http://software.opensuse-community.org
And another thing to keep in mind: we're getting into exactly the same problem as with the "community repositories" thingy: if it is hosted on opensuse.org, we won't be able to have applications that are in Packman.
Furthermore, the whole thing will definitely need specific support in the OBS, in order to ping repository changes to the system, as pulling repository metadata on a regular basis does not work, the current Software Portal being a proof of that (way too many repositories, way too much metadata, completely hogs the server). But I already started discussing that with Adrian, as I'm working on a replacement for the "webpin" package search (both frontend and API), based on a real search engine (Apache Solr) rather than on a database, and I'll need the OBS' publisher to make calls to webpin whenever changes happen.
The need for a packagekit based updater is that we have features like notifications of patch messages, distribution upgrade notifications and start of the dist-upgrade workflow, etc.
I'm not sure. As said above, I'd rather let that be handled through repository metadata, as it is now, and instead focus on how packages can be presented as applications to end-users.
cheers - -- -o) Pascal Bleser pascal.bleser@opensuse.org /\ http://opensuse.org -- I took the green pill __v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org
softwaremgmt@lists.opensuse.org
-
Adam Tauno Williams -
Cristian Morales Vega -
Duncan Mac-Vicar P. -
Frank Karlitschek -
J. Daniel Schmidt -
Jiri Srain -
Pascal Bleser -
Thomas Goettlicher