On Feb 10, 2008 11:30 AM, Patrice Dumas <pertusus@xxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
