a plan for updates after end of life

Jeff Spaleta jspaleta at gmail.com
Sun Feb 10 22:32:50 UTC 2008


On Feb 10, 2008 11:30 AM, Patrice Dumas <pertusus at free.fr> wrote:
> It is not something that can be easily done. The metric which makes the
> most sense to me today is: has somebody brought an issue with the
> maintainer work toward the relevant commitee (in that case I guess it
> would be the UAEL SIG) and the commitee decided to orphan the package.
> Just like in Fedora. Agreed it is not a perfect process, but there is no
> reason to have a better one for UAEL.

What about we also put a branch expiration latch on the ratio of
maintainers to packages that must be maintained as part of UAEL?
Require the number of total number of maintainers to packages in UAEL
to be above some reasonable bar. And additionally require that each
maintainer of a 'core' UAEL package keep their load with respect to
UAEL below a certain number of packages.

The goal would be to minimize a situation where a small number of
people are being overwhelmed and getting into a situation where things
a spread too thin for a long period of time after initial interest in
the branch as dropped.  The assumption being that for UAEL to work at
all, it will be relying on numbers of people instead of deep
expertise, at least initially.

>
> In any case all you say is much more relevant to EPEL. Why don't you
> raise this concern here?

EPEL isn't responsible for core elements whose continued community
maintenence is linked directly to the length of time the branch is to
exist.  Again..totally different.  If you continue to propose that
maintenence of a set of packages is linked to branch existence..I will
continue to state that better metrics about maintenence will have to
be proposed.  Don't link eol to core package set maintenence, and I
won't have a need for maintenence metrics.

>
> If it is just a time length you want, we can say 5 years maximum of
> updates. I think it will last shorter anyway, even with bad maintainers
> hiding their lack of care of packages.

I think you are wrong. I think given the chance, people who care about
this enough to participate will attempt to do everything they can to
keep the branch alive as long as possible by picking up too many
packages...to the point of burning themselves out completely.
Passionate people can be prone to self-delusions concerning the size
of the mountains they can move around.  I'm trying to make sure
project management have some credible and agreed on latches in place
by which which to make a decision to expire a branch before a small
group of people can become unhealthy obsessive over keeping it alive,
burning themselves out and doing a poor job with all their
contributions across the larger project.

If you can keep "enough" people involved, then this situation is
avoided. But as interest in a specific branch falls away, there has to
be a point at which project management comes in, and thanks those few
very committed people for making the effort to keep things going but
gently moves them along to avoid an unhealthy situation developing.

-jef




More information about the fedora-devel-list mailing list