Given the proposed roadmap for the build service end user
frontend, and the current state of the software portal
project I believe it is now necessary to discuss the future plans
and strategy for end user software access in openSUSE. In order to
avoid duplication of effort and NIH syndrome it would be wise to
discuss and agree upon a strategy now before we get too far down any
A very brief summary of the current state
is currently live, and allows
end users to locate packages/patterns packages packaged within the
build service and install them easily. On the roadmap is adding more
features such as statistics, tags, screenshots.
* Software Portal is a project started in the middle of this year, to
improve the end user experience of locating & installing software, and
to bring together metadata from various sources with user generated
metadata. The interest in this project waned over the summer months
while everyone was very busy with the upcoming 10.3. However, there is
now renewed development, see footnote for screenshots/status.
The question is where do we go from here. We don't feel it's worth
continuing to develop the software portal project if all the same
features are going to be implemented in the build service frontend. Is
developing the build service frontend the best strategy?
We would be interested in hearing your thoughts,strategy,advice so we
can move forward in cooperation not competition with the strategy that
will most benefit openSUSE.
Some of my personal thoughts on the matter follow:
We need an end user service to enable users to:
- Locate & Install Software
- Contribute feedback - Ratings, Tags, Bug reports...
- Contribute metadata - Screenshots, Icons, Descriptions...
- Connect software to related resources - Documents, Bug reports,
A lot of the data required to expose such a service to end users is
available within the build service already. It already knows about all
the software built with the build service. Therefore it might seem to
make sense to implement a service for end users to locate software on
top of the build service - like software.opensuse.org
incrementally add features to the build service to store and reconcile
user oriented data with the packager oriented data.
However, I see some fairly significant drawbacks to this approach.
To software built with the openSUSE instance of the build service.
You're pretty much guaranteeing users still have to look in multiple
places to find software, which is less than ideal. OBS will never have
all software for legal reasons, and people will always be building
their own software, other distributions have their own build services
2: Different concepts.
Build service being originally aimed at packagers might make it
difficult to provide the best interface for end users. Packagers are
interested in the details of packages, what is in each package, where
it is, etc. End users mostly want to find & obtain software.
Does it make sense to make the build service into a monolith which
does everything, or keep it within a well defined scope. A service for
building software, and create other services for other tasks. e.g we
for user identity rather than bolting it onto
the build service. Do one thing well isn't just the unix way. Of
course the build service already has a lot of the data end users need,
and packagers using the build service can make use of much end user
generated data. However, a monolithic system is not required for data
sharing. We could develop an end user service & frontend that is
distinct from the build service, but can share data with it.
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org