From Fedora Project Wiki
(remove categories, this is still a draft)
(init mission)
Line 1: Line 1:
 
== Mission ==
 
== Mission ==
  
TODO
+
'''This SIG is a work in progress and will be announced properly once we're ready, stay tuned.'''
 +
 
 +
We would like to offer and alternative way to maintain Fedora Linux packages in comparison to [[Package_maintenance_guide|the traditional way via dist-git]].
 +
 
 +
=== Rules ===
 +
 
 +
* Whatever we produce here, it MUST NOT violate Fedora Packaging Guidelines (we should strive to change them if needed).
 +
* Maintainers HAVE TO be able to step in for automation and replace some of its actions if needed.
 +
* Proven packagers and rel-eng still needs to be able to do their work in dist-git: their workflows NEED to keep working the same way.
 +
 
 +
=== Goals ===
 +
 
 +
For start, we would love to focus on two areas:
 +
 
 +
==== Easier maintenance for rawhide ====
 +
 
 +
Updating "simple" packages in rawhide should be as easy as merging a PR in dist-git if all tests and checks pass.
 +
 
 +
==== More convenient way to work on downstream patches ====
 +
 
 +
Track patches as git commits. This way it's easier to backport or cherry-pick changes from the upstream and rebase the patches when a new upstream release happens.
  
 
== Members ==
 
== Members ==

Revision as of 14:39, 22 March 2021

Mission

This SIG is a work in progress and will be announced properly once we're ready, stay tuned.

We would like to offer and alternative way to maintain Fedora Linux packages in comparison to the traditional way via dist-git.

Rules

  • Whatever we produce here, it MUST NOT violate Fedora Packaging Guidelines (we should strive to change them if needed).
  • Maintainers HAVE TO be able to step in for automation and replace some of its actions if needed.
  • Proven packagers and rel-eng still needs to be able to do their work in dist-git: their workflows NEED to keep working the same way.

Goals

For start, we would love to focus on two areas:

Easier maintenance for rawhide

Updating "simple" packages in rawhide should be as easy as merging a PR in dist-git if all tests and checks pass.

More convenient way to work on downstream patches

Track patches as git commits. This way it's easier to backport or cherry-pick changes from the upstream and rebase the patches when a new upstream release happens.

Members

Status

We have been in a planning stage of the SIG: bringing interested people together to flesh out the who, what, where, when, and how.

Communication

  • #packit on Freenode IRC
  • Mailing list - user-cont-team@redhat.com

Important links