openSUSE:DyadProposal

Jump to: navigation, search

Dyad Proposal

Introduction

The openSUSE Project has several different projects under its umbrella, which collectively support the building of openSUSE and SUSE distributions. Many of these projects are supported through contributions from open-source developers, openSUSE community members and SUSE employs. This proposal was developed by the openSUSE community along with stakeholders and intends to make the case for soliciting resources from SUSE to revamp and enhance a Secure Software Supply Chain through software.opensuse.org (software.o.o). Software.o.o. is the first impression many new users experience when trying an openSUSE distribution and the website leaves a lasting impression on users. Better known as the front end for software package developed from the Open Build Service, software.o.o. is an application store used by countless of open-source developers. Dedicating resources to revamp software.o.o will enhance the usability of openSUSE’s distributions, accelerate the use of SUSE’s enterprise distribution and support core business functions; this proposal will be accompanied by a business case articulating how an improved software.o.o. will help SUSE’s business as it relates to community software being consumed through PackageHub. Since the proposal relates to two topics that are similar and related, please refer to discussion related to this as the Dyad Proposal. The names of software.o.o and PackageHub are not intended to be replaced. The Dyad Proposal is meant to eliminate any confusion when discussing topics related to this proposal.

Situation

Reorganization, attrition and years of downward trending contributions* has placed software.o.o in a dilapidated state. The responsibility/ownership of software.o.o lies with the openSUSE community and was supported by SUSE’s Director of Data Center Management Dept, who is no longer with the company as the team no longer exists. Software.o.o could use support from SUSE with the skill sets to enhance and improve usability of the site. Software.o.o. lists a variety of different software packages for different distributions to include openSUSE Leap, Tumbleweed, SUSE Linux Enterprise (SLE), Fedora, CentOS, Debian, etc. Software packages built in OBS are shown on software.o.o, but the UI/UX, naming and visibility of the distributions as well as some inconsistencies with the functioning of the website/application store causes confusion, breakage for new users and a reluctance by some to try openSUSE’s Leap and Tumbleweed distributions, which has an affect on new users trying and understanding SLE. The software.o.o could use a complete revamp and a new strategy that helps the increase of both SUSE and openSUSE distributions. Contributions from the community are showing benefit for SUSE Products through PackageHub. People who want to put software on SLE are explicitly recommended to get their packages from packagehub.suse.com. However, with the compatibility between openSUSE Leap 15.3 and SLE 15 SP3 (Closing the Leap Gap), we can not guarantee that people will expressly use packagehub.suse.com when software.o.o also lists SLE packages like SLE:backports. This proposal is asking for three developers for this project. The resources have been identified as having at least one UX/UI person and two for coding. There will also be resources needed for documenting, testing and automatic deployments. A determination is that 1.5 Full Time Equivalent (FTE) will be needed to fulfill and maintain the Dyad Proposal. Too many elements and expertise is required for one person, so a team an d/or resources from existing teams would be needed to help achieve the proposed project. A project manager would be needed for the project to stay on track.

Goal

Building a new software.o.o prototype will provide the ultimate Secure Software Supply Chain by modernizing how software packages and containers are consumed. The socialized approached with a rating systems, comments, pertinent/useful information will create a solution-oriented shared content interface. The design and structure will complements the Open Build Service and PackageHub. The revamp of software.o.o will provide data to help SUSE decision makers and users of the website. This constructive synergistic environment with help both community and enterprise interests.

Community Feedback

The openSUSE community has been doing monthly sprints working on websites within the project and software.o.o. is one topic that continues to be discussed. A workshop was also done on Nov. 12. Notes from the workshop can be found at https://etherpad.opensuse.org/p/softwareworkshop and has been incorporated into the feedback below. The feedback shows a lists of many useful features that will help to improve the usability of the site. The improvements are:

  • Have a star system (or thumbs up/thumbs down) like GitHub to rate project/packages to help understand which of the packages are most popular/most respected. (similar to GNOME Software API)
    • Rating of maintainers so users can see who they can trust regarding using home repos
    • Have a platform where maintainers and users can communicate and create community around packages (thumbs up/down, forum?, comment section, most downloaded packages automation)
    • Package rating:
      • crucial to stress that the rating is about the package not upstream software (communication challenge)
  • Allow for dates on the freshness of a software package to be displayed
  • An option to opt-in or opt-out (blacklist) of showing a home repositories on software.o.o. so those who are working on these packages, which are not for consumption are not contacted by people to fix them. (OBS will likely need an attribute that can be integrated/interpreted by software.o.o. not to show)
  • Consolidate the listing of install options into one Install button and let YAST figure out which repo to use which it will do automatically. Because the current distribution listing is complicated (need change in the background). One button that installs to the distribution being used. Regardless if it is Leap, Tumbleweed. If this is done it would make it a much better user experience.
    • Suggestion - have a ymp format redesign to enhance the install usability for openSUSE users. Software.o.o. works with YaST MetaPackage (this is the thing software.o.o uses to generate the one-click-install), but it does not work with other package managers like zypper or dnf. Only YaST. The solution in redesigning ymp would allow for a search of the repos for only your distribution and leave the use with less chance for making an error. E.g. Like installing Factory packages on a Leap system.
    • https://github.com/yast/yast-metapackage-handler
  • Have software.o.o have just openSUSE software and do repositories.opensuse.org (or repos.opensuse.org) for all software and provide results for containers from https://registry.opensuse.org/
    • Make a distro selector. Default to openSUSE and then a button or drop down pick from list (for those using OBS to build packages for other distros).
    • List openSUSE distributions more prevalent. Maybe label others as "non-openSUSE distributions" family.
  • A proper user interface with OPI (OBS Package Installer) would allow for packages to be selected and effectively installed within the system.
  • Think about writing an API for software.o.o for people who might be interested in using it to write package management solutions.
  • Search the packages online at scc.suse.com. There are also CLI (zypper) and GUI (YaST) clients, SCC provides an API so you can see the same results in all places
  • Enhance the openSUSE branding so that software packages are listing the openSUSE package prominently.
  • Enhance the visual interface with screenshot or logos that are of a consistent quality and branding.
  • Allow an option for people using the Open Build Service to attach a profile and info on software.opensuse.org. (name, email, github account, bio, blog, image, etc.)
    • GDPR opt-in and opt-out
    • Provide an option to for developers/project of a package have a profile image and fields for website links
  • Optimize filters for package searches.
  • Create an interface that can drive community self-support. Something like comments with an interface that can point to forums, mailing lists, bug reports, youtube pages, reddit pages, etc. Information can be posted and a rating option on the software package and the comments can help both enterprise and open-source communities collaborate effectively.
  • Leverage the solutions from software.o.o. features/API for SLE and/or PackageHub
  • Possibly use DocTeam’s recipes with an API.
  • Coloring systems could be used for trust of maintainer, package, and user's expertise.
  • Have the site detect the distribution. Shell script to detect the distribution and version.
  • Have communication channel(s) with maintainer(s)
  • There is some confusing behavior with the site. An AppStream button appears randomly on certain packages and confuses users. “Official Release” [Official] is not showing Leap 15.3 and shows some AppImage packages to be “Official Releases”
    • Selection of the type of package like rpm, deb, AppImage and FlatPak

Teams With Involvement

  • Packaging Team: Provides packaging expertise on the interactions, feedback loop
  • Release team has to deploy configuration
  • YaST team can help with dropping the one-click installer and help with the shell script to identify the distribution being used. (Need more research and discussion on solution software management support can be extended consultant on how packages are being installed)
  • UI/UX Team can bring the user experience with a prototype. Understanding the customer path and optimizing it in practice.
  • PackageHub: ties in the business case for resources.
  • SCC needs involvement or at least provide some feedback, which might help them with business logic.
  • Maintainer is the subject matter expert as the current maintainer.
Retrieved from "https://en.opensuse.org/index.php?title=openSUSE:DyadProposal&oldid=169163"