extras maintainence

[Ralf Corsepius]

On Fri, 2006-02-10 at 12:42 -0500, Jeff Spaleta wrote:
> On 2/10/06, Ralf Corsepius <rc040203 at freenet.de> wrote:
> > In short: We are volunteers, and if volunteers want to do something, you
> > shouldn't prevent them from doing it - You should make it as easy as
> > possible, otherwise they will feel peed.
> 
> Volunteer fire fighers don't get to do whatever they want..
[apples and oranges]
>  Its not
> unreasonable to discuss the responsibilities and expectations on
> volunteer packagers in the context of the overall goals.
Face it: You can set up as many expectations and responsibilities as you
want, but nobody around here is in a position to force any body to do
anything. - If you do, it's the project who's going to loose.

It's characteristic for OSS projects (and any volunteered project in
general) that people come and go.

> > Example: I don't have a problem in continuing maintenance of some
> > packages for FE3 for some time, until _I_ am loosing interest, but I am
> > not interested putting the burdon a legacy project would additionally
> > impose on me.
> 
> I think its quite fair to ask all maintainers to pledge to
> maintainership for a package on the timescales of specific releases to
> be honest about what their commitment is to the project... upfront.
> If a maintainer is only interested in maintaining a package in Extras
> for the latest Core release..we should know that
It's happening all over the place.

The reasons are simple: Maintainers' resources are limited, so
maintainers restrict themselves to actively working the release they are
actively using and try to avoid to touch anything that is not "reported
to be broken" (The old: "don't try to fix what ain't broken")

In the end you see a policy of "If it builds it goes to FC(n+1)", "If it
seems to work it goes to FC(n)", "If a change is harmless it goes to
FC(n-1), if it seems scary, it doesn't".

Frankly speaking, I don't see what's wrong with this.

> .. upfront... so other
> people in the project can prepare to take over maintainership at the
> appropriate time.

> And I don't think its in this project's best interest to encourage
> packagers show up, build a package, and then lose interest in that
> package within a month and orphan it.
That's why I, as long as Fedora exists, have been demanding to abandon
the concept of "personal ownership" and to team up.

An individual may have the "lead" and "last word" on maintaining a
package, but he should not block others from improving/fixing a
packages. Unfortunately this is what current FE's policy encourages and
what currently is happening.

> And I don't think its in the project's best interest to encourage
> maintainers to lose interest part way through fc3's "legacy" process.
Let me put it this way: You'd loose maintainers if you'd try to force
people into maintaining a package for a release, they don't have any use
for.

Applying this thought on myself: I don't have a problem in "having an
eye on a package for FC3 as part of FE", nor do I have any problem in
people reporting problems with an FC3 package "I own", but you'd
probably loose me if you force me to "actively maintain/test" or if you
want to force me into "Fedora Legacy Project".

> I think we should be asking maintainers to be explicit about the
> timescales over which they are willing to make the effort over defined
> chunks of time and holding them to those estimates. Its going to save
> us lots of effort down the road scrambling to replace maintainers as
> they orphan packages willy-nilly.  I think there should be clearly
> established points at which dropping maintainership for a package is
> encouraged so other people can plan their time to pick up
> maintainership of packages they are interested in and to discourage
> dropping maintainership between those time points. 6 month periods or
> something. Every six months or so, we do a general shout out to all
> maintainers and ask them to re-affirm if they are going to be
> maintaining their packages for the next 6 months. If they can't
> honestly commit to that, then other people can plan on taking over the
> co-maintainership of those packages to prevent a gap for any package. 
> Its called planning.
As I said before, you can't force anybody around here. As in any other
project run by volunteers, people show up and drop off for various
reasons. I you'd try to commit them to anything, you'll loose people
(c.f. how the CLA is perceived - It took me 1/2 a year of careful
consideration to accept it, and I guess it caused many other willing
people to refrain from participating).

IMO, the only workaround is setting up teams, people can apply and
(temporarily) subscribe/unsubscribe to. The SIGs currently being
discussed and introduced, are a step into this direction.

> Many volunteer organizations have accountability mechanisms which rely
> on explicitly defined expectations as to how much work individual
> volunteers are pledging to do when they join the organization.  There
> is no reason that a discussion about the expectation for volunteers in
> this project cannot happen.
c.f. above. You can't control us. If you try, the project looses.

Ralf