Who is allowed to modify which packages

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
m (1 revision(s))
m (CVS -> Git)
(10 intermediate revisions by 6 users not shown)
Line 1: Line 1:
 
<!-- page was renamed from Extras/Policy/WhoIsAllowedToModifyWhichPackages
 
<!-- page was renamed from Extras/Policy/WhoIsAllowedToModifyWhichPackages
 
-->
 
-->
With the current CVS-Layout each packager can modify all packages. This will probably change in the future with the next [[Infrastructure/VersionControl| Version Control System]] (VCS) and a proper ACL scheme, but for now this document tries to lay down which contributor is allowed to touch which packages for now.
+
With the current Git layout each member of the [[Provenpackager_policy|provenpackager]] group can modify most packages. As an exception, some specific packages can be closed to provenpackagers, upon FESCo approval.  
  
 
= Who is allowed to modify which packages =
 
= Who is allowed to modify which packages =
 
+
<onlyinclude>
 
<!-- INCLUDEPOLICYFRONTSTART
 
<!-- INCLUDEPOLICYFRONTSTART
 
-->
 
-->
  
Normally the maintainer that is listed as primary maintainer in the [[Infrastructure/PackageDatabase|  PackageDB]]  (formerly this was [http://cvs.fedora.redhat.com/viewcvs/owners/owners.list?root=extras&view=markup owners.list] ) 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 is normally the best way to contact the package maintainer or to send him patches and suggestions because is neutral and trackable; but poking people one or twice in IRC or directly via mail might be a good idea.
+
Normally the maintainer that is listed as primary maintainer in the [https://admin.fedoraproject.org/pkgdb/  PackageDB]  (formerly this was [http://cvs.fedora.redhat.com/viewcvs/owners/owners.list?root=extras&view=markup owners.list]) 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 is normally the best way to contact the package maintainer or to send him patches and suggestions because it is 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 -- it mostly boils down to this:
 
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 -- it mostly boils down to this:
Line 16: Line 16:
 
* a packager doesn't fix important bugs in time
 
* a packager doesn't fix important bugs in time
  
* if there are problems known that might be bad for the whole Project or a lot of users of the repo/a particular package
+
* there are problems known that might be bad for the whole Project or 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 quite minor or considered as a general cleanup to a lot of packages
  
then [[ExperiencedPackagers| experienced Fedora packagers]] are allowed to fix stuff in other peoples packages.
+
then [[Provenpackager_policy|provenpackagers]] are allowed to fix stuff in other peoples packages.
  
 
<!-- INCLUDEPOLICYFRONTEND
 
<!-- INCLUDEPOLICYFRONTEND
 
-->
 
-->
 
+
</onlyinclude>
 
{{Anchor|afterinclude}}
 
{{Anchor|afterinclude}}
  
Line 31: Line 31:
 
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.
 
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.
  
=== Inactive Packager ===
+
=== Unhandled issues ===
  
 
The packager normally should keep track of his packages; that means:
 
The packager normally should keep track of his packages; that means:
Line 38: Line 38:
  
 
* fix his stuff without explicit poking if it is mentioned in the problem reports somewhere -- that includes:
 
* fix his stuff without explicit poking if it is mentioned in the problem reports somewhere -- that includes:
 +
** looking at the [[PackageMaintainers/PackageStatus|  Package Status]]  pages in the wiki now and then
 +
** 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 [[Fails_to_build_from_source]] bugs
  
* looking at the [[PackageMaintainers/PackageStatus|  Package Status]]  pages in the wiki now and then
+
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 need fixing actually is. But some examples:
 
+
* fix EVR problems if they get mentioned in the problem reports on the fedora-maintainers-list
+
 
+
* fix dependency issues (including those in the devel repo) -- the script sends problems to both the maintainer and the list
+
 
+
* participate in mass-rebuilds
+
 
+
If the packager doesn't keep track of those items, then other experiences 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 need fixing actually is. But some examples:
+
  
 
* security problems:
 
* 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 fixes 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
  
* 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 fixes quicker.
+
* 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
* not that important problems should be dealt with quickly, too -- waiting for 2-7 days (depending how bad the issue is) is considered enough
+
** 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
* bugs need 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
+
  
 
{{Template:Caution}} Some notes:
 
{{Template:Caution}} Some notes:
  
*  If you are a packager and offline due to vacation, traveling or other issues for longer time periods (for example five days or longer) please announce that in the wiki on the [[Vacation|  proper Page]] . Other in this case don't have to wait for you to fix stuff (e.g. if a Security Fix needs to be applied) or know that they don't have to expect an answer before your return.
+
*  If you are a packager and offline due to vacation, traveling or other issues for longer time periods (for example five days or longer) you may announce that in the wiki on the [[Vacation|  proper Page]]. Other in this case don't have to wait for you to fix stuff (e.g. if a Security Fix needs to be applied) or know that they don't have to expect an answer before your return.
  
* Inactive actually really means inactive -- if the maintainer responded once in a bug report, but felt 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.
+
* Unhandled actually really means completly unhandled -- if the maintainer responded once in a bug report, but felt 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 ;-)
 
* 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
+
* 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 cvs 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 were bypassing the proper maintained is considered fine:
+
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 were 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 the devel branch of cvs 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 CVS after being announced some days in advance.
+
 
+
* mass rebuilds
+
 
+
{{Anchor|ExperiencedPackagers}}
+
 
+
===  Definition of the term "Experienced packagers" ===
+
 
+
As experienced packagers count:
+
 
+
* The release manager(s) (we don't have such a position yet, but we'll probably have one sooner or later)
+
 
+
* Sponsors
+
 
+
* Especially the QA and Security SIGs
+
  
* the SIG that's handling the area in which the package or the fix is needed. But
+
* 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 the devel branch of Git 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.
  
* the SIG has to exists for at least two months and needs to have shown activity in the past two months
+
* small fixes or adjustments for new or modified packaging guidelines can be done directly in Git after being announced some days in advance.
  
* the member is an experienced Fedora packager and around for at least four months and member of the SIG for at least one month
+
* mass rebuilds.
  
* Red Hat packagers that have been through a number of reviews and have been packagers for more than 4 months.
+
[[Category:Package Maintainers]]

Revision as of 12:22, 30 January 2011

With the current Git layout each member of the provenpackager group can modify most packages. As an exception, some specific packages can be closed to provenpackagers, upon FESCo approval.

Contents

Who is allowed to modify which packages

Normally the maintainer that is listed as primary maintainer in the PackageDB (formerly this was owners.list) 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 is normally the best way to contact the package maintainer or to send him patches and suggestions because it is 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 -- it mostly boils down to this:

If

  • a packager doesn't fix important bugs in time
  • there are problems known that might be bad for the whole Project or 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

then provenpackagers are allowed to fix stuff in other peoples packages.


Who is allowed to modify which packages -- More 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

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:
    • looking at the Package Status pages in the wiki now and then
    • 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 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 need 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 fixes 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

Warning.png Some notes:

  • If you are a packager and offline due to vacation, traveling or other issues for longer time periods (for example five days or longer) you may announce that in the wiki on the proper Page. Other in this case don't have to wait for you to fix stuff (e.g. if a Security Fix needs to be applied) or know that they don't have to expect an answer before your return.
  • Unhandled actually really means completly unhandled -- if the maintainer responded once in a bug report, but felt 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

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 were 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 the devel branch of Git 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.