Policy RFC: When to touch other peoples packages (or: Fix stuff that needs fixing)

[Thorsten Leemhuis]

Hi all!

we had some discussion one or two weeks ago (and some others earlier)
when touching other peoples packages in CVS might is okay in Fedora
Extras. FESCo worked on a policy for that. Here it is (directly from the
wiki at
http://www.fedoraproject.org/wiki/Extras/Schedule/FixStuffThatNeedsFixing
), please comment:

----
With the current CVS-Layout each packager can modify all packages. This
will probably change in the future with the next 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.

= Who is allowed to modify which packages =

Normally the maintainer that is listed as first maintainer in
[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 other 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.

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

 * if 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 [#ExperiencedPackagers experienced Extras packagers] are allowed to
fix stuff in other peoples packages.

== Examples and detailed explanations ==

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 Extras, but
it should give everyone some idea how to lay out the above rules.

=== Inactive Packager ===

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 your stuff without explicit poking if it is mentioned in the
problem reports somewhere -- that includes:

  * looking at the [:Extras/PackageStatus: Package Status] pages in the
wiki now and then

  * fix EVR problems if they get mentioned in the problem reports on the
fedora-extras-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:

  * 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 enough

  * 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 need similar treatment like security problems:

  * Important stuff (data corruption for users) should be fixed as quick
if possible -- waiting one day is considered 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 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.

 * 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.

 * if you committed changes to another package wait some hours if
possible (normally 24 or 48) before you actually build the updated
package. 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 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:

 * 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)

 * FESCo members

 * Sponsors

 * Especially the QA and Security SIGs

 * the SIG that's handling the area in which the package or the fix is
needed. But

  * the SIG has to exists for at least two months and needs to have
shown activity in the past two months

  * the member is and experienced Extras packager and around for at
least four months and member of the SIG for at least one month

----
That's it.

CU
thl