openSUSE:OpenSUSE Tumbleweed Maintainer Policy

Jump to: navigation, search

DRAFT POLICY REQUEST FOR COMMENTS

Version: 20230121


Purpose

Things actively fall on maintainers, but they won't force people. Because there are complications with who/what breaks something. If things become a problem and cause something to breakage, then some changes are in effect. 

The unaffecting low level aspects are rather difficult to find a solution. Sometimes maintainers might be dormant and unresponsive, but they might have an idea and just don't want to merge a SR based on their ideas for the package. New package submissions are another topic and much more difficult. Discussions should provide some results. It won't provide something immediately, but the items should be reflected in the policies and a git workflows. Will keep listing this topic "Project maintainer work flow Status" for the next meeting on Jan. 11. 

Suggested is that all packages in openSUSE Tumbleweed need to be maintained. Maintenance can be a group or an individual maintainership, and even no designated maintainer. However, if there are reasons to believe that a package is unmaintained, it will get deprecated and eventually removed. 

Triggers for deprecation cycle

  • an existing active maintainer is asking for deprecation
  • the package fails to build in factory on the primary architectures for X weeks
  • the package has outstanding security vulnerabilities and SUSE security requests a deprecation cycle
  • the package has outstanding severe defects that limit its inherent functionality significantly for many users
  • the package has outstanding package contributions (submit requests or equivalent) that are not being reviewed for Y weeks

    

Maintainer Deprecation cycle

  • For each package where a deprecation cycle is triggered, a number of reasonable attempts are made at finding a new active package maintainer, like for example
  • asking for another package maintainer to adopt it and remove the dormant ones
  • asking for a group package maintainer ownership going forward (example "team of python/gnome/kde maintainers")
  • asking for volunteers in the community to step up (like e.g. by contacting the last submitters of changes)
  • giving existing package maintainers X weeks to react to the deprecation request and respond to the raised issues
  • if the maintainer deprecation was not successful after X weeks, the package gets into the removal cycle

   

Maintainer removal cycle

  • Dependencies to the package are analyzed. if the package is a leaf package, it gets removed from Tumbleweed. 
  • if the package has dependent packages, the dependent package maintainers have X weeks to drop the dependency, to adopt the problematic package or to get also dropped
  • if a package has large number of dependent packages (more than X), the team / person raising the deprecation has the obligation and permission to execute the deprecation, for example by merging a change to the package that resolves the deprecation reason (bypassing maintainer). The raiser of the deprecation cycle does not automatically inherit ownership of the package maintenance that way. 

Change driver

The maintainership responsibility can be shared with a change driver. A change driver can be an initiative of one or many individuals that are applying a quantitatively large number of changes limited to a specific domain (example architecture port, package rename or implementation of a new packaging macro/stylistic improvement or quality improvement efforts). The change project submitters take ownership and responsibility for the domain specific change and owns fixing the fallout of the regressions caused by that     

Owner of the policy and conflict resolution is done by the distribution release engineer.

Retrieved from "https://en.opensuse.org/index.php?title=openSUSE:OpenSUSE_Tumbleweed_Maintainer_Policy&oldid=172594"