On Sun, Feb 10, 2008 at 01:32:50PM -0900, Jeff Spaleta wrote: > 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? The number of package is (almost) never a good metric. Indeed some packages are quite hard to maintain (the kernel for example) while others are easy to maintain, either because they are simple. Also some packages may be kept synchronized with a fedora version. The kernel may not be that hard to maintain, in the end, if the kernel of a stable fedora release can be used as soon as a security issue is found. > 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. That looks like a possible idea. What we could do is ask the maintainer for the time he has to devote to UAEL, and assign weights to packages based on their complexity and easyness to update following fedora packages. But, first, we should do that in fedora proper before, and second I don't thinkt hat the result will be much more reliable. > 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. Once again it is the same in fedora. There is an obvious difference, there can be more branches in UAEL, but more branch doesn't necessarily mean more work, if they can be kept synchronized when security issues are discovered (and it is more or less the plan for UAEL). > 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. I cannot come up with good 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. We will never be able to assess this situation. It is truely a right concern, but a metric for such thing, especially with volunteers doesn't really make sense. Per package is not right, people are not of equal disponibility and ability. > 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. Which management are you referring to? The SIG? Anyway I won't come with a metric for packager possible involvment, considering that packagers can be trusted not to do things wrong. You can consider my proposal retired. I will add the outcome of the discussion to the wiki for documentation purposes. -- Pat -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
