> > Why not? If a part of the community is willing to maintain a package, they > > should be able to do it. > > That would be the "some do, some don't" playground. That's allready what is the extras project - within the policy constraints. To be more clearer, what is common is defined by the guidelines, everything else is "some do, some don't" and that's good. > We try to move away from Fedora Extras being a second class citizen. Fedora Extras isn't a second class citizen. Currently I think it is better that core for the quality of the packages, and the transparency of the package acceptance process and build process. Core may be better with regard with the security fix. But I don't have numbers on how fast the security issues are processed in extras and in core. > We cannot do that as long as we lack a well-defined life-cycle compared > with Fedora Core. And when we distinguish between active (i.e. maintained, I don't see why fedora extras would be a second class citizen if it hasn't a well-defined life-cycle. This seems unimportant with regard with other issues like packages cleaness, time to respond on bug reports, willing to track new things and completness of packages offer. > "supported") branches, legacy branches and dead branches, we need policies > which allow for improved security response times, e.g. through the work of > a Fedora Extras security response team, which under well-defined > conditions may touch packages in _all_ branches. Whether these are the > same people who would maintain legacy branches, is an unimportant detail. I agree, but this has nothing to do with the "some do, some don't" regarding maintaining or not packages for legacy branches. It is allready "some do, some don't" for 'supported' branches. It's a voluntary project, after all. > And yes, we do need improved and stricter policies on how to handle > orphaned packages. Agreed. -- Pat -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
