Co-maintainersip policy for Fedora Packages

[Michael Schwendt]

On Mon, 29 Jan 2007 09:11:13 +0100, Hans de Goede wrote:

> > "Touching your packages" and "upgrading your packages" is not the same.
> > Why, oh, why are breakage scenarios like that used as a main argument
> > everytime there is a discussion like this?
> > 
> 
> Because:
> 1) I've sponsored several people and in general that meant having to
>     teach / coach them until they become familiar enough with packaging
>     issues and guidelines to give them the green light. At that point
>     most of them still weren't really good packagers, think of them as
>     just graduated from school and now learning the real stuff in
>     practice.
> 2) One of THL's main arguments for this co-maintaining is to allow new
>     (unexperienced) contributers to get into the game by co maintaining
>
> 3) New (unexperienced) contributers are likely to not know the
>     difference between touching and updating.

It has not become clear to me that thl refers to inexperienced people only
(I may need to reread his overlong proposal).

Experience is relative. Existing Fedora packagers can apply over-ambitious
or questionable changes, too, and sometimes make mistakes.

Generally, the entry path is blocked not only for inexperienced people,
who haven't signed up before, but also for knowledgeable people.

Without an alternative process for new contributors, they cannot become
Fedora packagers of anything that is included in the distribution
already. Even if they found a single package to submit (possibly an
orphaned one), there is an artificial hurdle that in order to find a
sponsor, they should do a couple of reviews first.

I don't really see a problem with letting new contributor sign up as
co-maintainers when they would like to help with a specific package. An
existing package owner would take the place of the account sponsor, and
there is no requirement to give new contributors a free ticket for running
wild in the scm and buildsys. Certainly it could be arranged that they
talk to the primary package owner about planned changes and build jobs.
Failure to do so could have consequences or in case something breaks
badly.

> That doesn't mean I'm opposed to all this, it just means I'm critical.
> I for one wouldn't let a new (unexperienced) contributer, co-maintain
> any (delicate) libraries as the chance for breakage is just too high 
> (IMHO).

"No chance = no breakage" is like trying to keep the door closed.

It should be possible to open the door cautiously, with proper policies
and guidelines in place.

> OTOH I have plenty of simple / small package for which a 
> co-maintainer would be more then welcome, and in that case to actual 
> handle things like new upstream versions, fix small packaging bugs etc.

Even "simple / small" packages can be build dependencies for other
packages and therefore increase the overall maintenance requirements.