From ab1ea405bd945fcea1d7192f66380a35d68e3a90 Mon Sep 17 00:00:00 2001 From: Otto Urpelainen Date: Jun 15 2021 05:59:50 +0000 Subject: Import page 'Who is Allowed to Modify Which Packages' from wiki The page was categorized under "Package Maintainers" in wiki, but actually contains policies that are decided by FESCo. Thus, the correct location of the page is in the FESCo documentation site. Updating links to the wiki page to cross references led to applying semantic line breaks to a single line paragraph in the Provenpackager Policy page. This led to small changes in wording, too, because the original was slightly hard to read. There was no intent to change the meaning. --- diff --git a/fesco/modules/ROOT/nav.adoc b/fesco/modules/ROOT/nav.adoc index e75a420..8722035 100644 --- a/fesco/modules/ROOT/nav.adoc +++ b/fesco/modules/ROOT/nav.adoc @@ -14,6 +14,7 @@ ** xref:Policy_for_nonresponsive_package_maintainers.adoc[Policy for nonresponsive package maintainers] ** xref:Policy_for_encouraging_comaintainers_of_packages.adoc[Policy for encouraging comaintainers of packages] ** xref:Provenpackager_policy.adoc[Provenpackager policy] +** xref:Who_is_allowed_to_modify_which_packages.adoc[Who is allowed to modify which packages] ** xref:Third_Party_Repository_Policy.adoc[Third party repository policy] ** xref:Updates_Policy.adoc[Updates policy] ** xref:FESCo_election_policy.adoc[FESCo election policy] diff --git a/fesco/modules/ROOT/pages/Policy_for_encouraging_comaintainers_of_packages.adoc b/fesco/modules/ROOT/pages/Policy_for_encouraging_comaintainers_of_packages.adoc index 95b3ef6..54f5ad5 100644 --- a/fesco/modules/ROOT/pages/Policy_for_encouraging_comaintainers_of_packages.adoc +++ b/fesco/modules/ROOT/pages/Policy_for_encouraging_comaintainers_of_packages.adoc @@ -176,7 +176,7 @@ to comment on the commits before the package gets in the repo. Big changes get coordinated. -* The usual rules for https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages[modifying other people packages] remain intact. +* The usual rules for xref:Who_is_allowed_to_modify_which_packages.adoc[Who is Allowed to Modify Which Packages] remain intact. Thus people from QA, Security or Arch-SIGs might touch the package, too. There is the strong wish to have a group of long-term contributors diff --git a/fesco/modules/ROOT/pages/Provenpackager_policy.adoc b/fesco/modules/ROOT/pages/Provenpackager_policy.adoc index 017107c..32fc221 100644 --- a/fesco/modules/ROOT/pages/Provenpackager_policy.adoc +++ b/fesco/modules/ROOT/pages/Provenpackager_policy.adoc @@ -2,7 +2,19 @@ Provenpackagers are members of the 'provenpackager' group. In addition to the rights granted to members of 'packager', provenpackagers are able to commit changes to packages they do not own or maintain. They are a group of skilled package maintainers who are experienced in a wide variety of package types and who are familiar with the link:https://fedoraproject.org/wiki/Packaging:Guidelines[packaging guidelines] and xref:Package_maintainer_responsibilities.adoc[package maintainer policies], as well as acutely aware of link:https://fedoraproject.org/wiki/Releases/Schedule[release schedule] and link:https://fedoraproject.org/wiki/ReleaseEngineering#Freeze_Policies[freeze policies]. -Provenpackagers lend a hand when help is needed, always with a desire to improve the quality of Fedora. Provenpackagers should try to communicate with owners of a package in bugzilla, irc or email prior to making changes. They should be careful not to change other people's packages needlessly and try to do the minimal changes required to fix problems, as explained more in depth in the policy explaining link:https://fedoraproject.org/wiki/who_is_allowed_to_modify_which_packages[who is allowed to modify which packages]. To exclude a package from provenpackagers access, you have to open a ticket at link:https://pagure.io/fesco/new_issue[FESCo issue tracker] and explain why provenpackagers should not have access to it. xref:index.adoc[FESCo] will discuss and vote on one of its weekly meetings about your request. +Provenpackagers lend a hand when help is needed, +always with a desire to improve the quality of Fedora. +Prior to making changes, +provenpackagers should try to communicate with owners of a package +in bugzilla, irc or email. +They should be careful not to change other people's packages needlessly +and try to do the minimal changes required to fix problems, +as explained more in depth in xref:Who_is_allowed_to_modify_which_packages.adoc[Who is Allowed to Modify Which Packages]. +To exclude a package from provenpackagers access, +you have to open a ticket at link:https://pagure.io/fesco/new_issue[FESCo issue tracker] +and explain why provenpackagers should not have access to it. +xref:index.adoc[FESCo] will discuss about and vote on your request +in one of its weekly meetings. == Becoming provenpackager diff --git a/fesco/modules/ROOT/pages/Who_is_allowed_to_modify_which_packages.adoc b/fesco/modules/ROOT/pages/Who_is_allowed_to_modify_which_packages.adoc new file mode 100644 index 0000000..07dba4f --- /dev/null +++ b/fesco/modules/ROOT/pages/Who_is_allowed_to_modify_which_packages.adoc @@ -0,0 +1,167 @@ += Who is Allowed to Modify Which Packages +:toc: + +With the current Git layout +each member of the xref:Provenpackager_policy.adoc[provenpackager] group can modify most packages. +As an exception, +some specific packages can be closed to provenpackagers, +upon FESCo approval. + +[[digest]] +== Digest + +Normally the maintainer that is listed as primary maintainer +in the https://src.fedoraproject.org[dist-git repository] of a package +is the only one who modifies the package +or gives others permission +(e.g. by accepting them as co-maintainers) +to commit and build changes for that package. +Bugzilla or repository's pull requests are normally the best way +to contact the package maintainer +or to send him patches and suggestions +because they are neutral and trackable; +but poking people once or twice in IRC or directly via mail might be a good idea. + +But there are certain exceptions +where the maintainer has to accept that other packagers will modify his packages. +Those exception are described in detail below. They mostly boil down to this: +In any of the following cases, +the xref:Provenpackager_policy.adoc[provenpackagers] are allowed to fix stuff in other peoples packages: + + +* a packager doesn't fix important bugs in time + +* there are problems known that might be bad for the whole Project +or to a lot of users of the repo/a particular package + +* the changes are quite minor +or considered as a general cleanup to a lot of packages + +* the changes are part of a Fedora Objective, +with a specific plan approved by FESCo + +[[details]] +== Details + +This is section will try to explain above rules in more detail. +It will never be able to cover all things that might arise in Fedora, +but it should give everyone some idea +how to lay out the above rules. + +[[unhandled_issues]] +=== Unhandled issues + +The packager normally should keep track of his packages. That means: + +* respond in bugs reported in bugzilla, +especially fast if it's a serious problem like a security issue + +* fix his stuff without explicit poking +if it is mentioned in the problem reports somewhere +-- that includes: + +** fix EVR problems, when they get mentioned in problem reports + +** fix dependency issues (including those in the devel repo) +-- the script sends problems to both the maintainer and the list + +** participate in mass-rebuilds +and fix xref:Fails_to_build_from_source_Fails_to_install.adoc[Fails to Build from Source] bugs + +If the packager doesn't keep track of those items, +then other experienced packagers are free to fix stuff for him. +It's impossible to set a timeframe +when a contributor should step forward to fix stuff +because that depends on how bad the problem that needs fixing actually is. +But some examples: + +* security problems: + +** Important stuff should be fixed as quickly if possible +-- waiting one day for the maintainer to show up +and step in to fix a issue that got reported to him +is considered more than enough; +there may even be situations where issues need to be fixed quicker + +** not that important problems should be dealt with quickly, too +-- waiting for 2-7 days (depending how bad the issue is) is considered enough + +* bugs needing similar treatment like security problems: + +** Important stuff +(data corruption for users) +should be fixed as quick if possible +-- waiting one day is considered more than enough here, too + +** harmful, but not that bad bugs that might hurt users +-- waiting for 2-14 days (depending how bad the issue is) is considered enough + +** annoying, but not that harmful bugs +-- waiting for 21 days is considered enough + +Some notes: + +* If a packager is offline +for longer time periods (for example five days or longer) +due to vacation, traveling or other issues +they may announce that on the https://calendar.fedoraproject.org/vacation/[vacation calendar]. +In this case, others know not to expect an answer before the packager returns +and can immediately proceed to fix things +(e.g. if a Security Fix needs to be applied). + +* Unhandled actually really means completely unhandled +-- if the maintainer responded once in a bug report, +but fell silent afterwards, +try to ping him again, +maybe he has just forgotten about this bug. +Or there might be some good reason +why he hasn't yet committed the provided fix. + +* If you committed changes to another package +wait some hours if possible +(normally 24 or 48) +before you actually build the updated package +as long it is nothing serious that should be fixed quickly +(security problems, ...). +That leaves some time for the maintainer to wake up. + +* Experienced packagers should limit their changes to other people packages +to things that are well agreed upon. +I.e. don't fix things considered somewhat controversial +or a matter of style. + +[[minor_general_or_cleanup_changes]] +=== Minor, general or cleanup changes + +Sometimes there are situations where it's simply a lot easier +to fix stuff directly in Git +than via bugzilla and the proper maintainers. +So much easier that we should leave this path open. +These situations shouldn't arise that often. +Some examples of situations where bypassing the proper maintained is considered fine: + +* support for a new architecture +-- that often requires that a lot of packages +need adjustments or patches that packagers often can't even test themself. +Getting all those modifications in via bugzilla is a lot of annoying work, +so these things can be fixed directly in rawhide without contacting the individual maintainers +if the general effort was announced beforehand. +A SIG should handle the stuff +and continue with normal operations +after the initial porting efforts are finished. + +* small fixes or adjustments for new or modified packaging guidelines +can be done directly in Git after being announced some days in advance. + +* mass rebuilds. + +[[changes_for_fedora_objectives]] +=== Changes for Fedora Objectives + +Sometimes, we may want to make big changes which go beyond cleanup, +in support of a Council-approved https://docs.fedoraproject.org/en-US/project/objectives/[Fedora Objective]. +These changes will be easier to make in coordination +rather than individually. +In these situations, FESCo will discuss a plan, +including the scope of the changes +and communicate that via the devel list.