On 2/27/06, Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> wrote: > - you open a bugzilla-ticket with a fix/enhancement. Maintainer does not > react after N days (N=14, shorter timeframe if it's something more > important, e.g. security or something is totally broken) -> you go ask > on fedora-extras-list for comments and wait for another 24 hours -> > apply patch and build no for enhancements 2 weeks is too damn short for rfe's.. people have real lives that get in the way... and I think policy needs to be aware of that. This is the wrong solution. The solution is pro-active team building no re-active patching. Are you really going to demand that contributors respond to all enhancement requests regardless of crackrock status? Sounds to me like a great way to forcibly get a change into a package that the current maintainer(s) doesn't support. Duplicate enhancement request for the same thing over and over again until the maintainer decides not to respond because its a waste of time to mark the dupes. I will not personally support any policy which puts mandatory constraints on an Extras contributor reply to bugzilla tickets for non-security feature requests in X amount of time. And I don't think letting people willy-nilly patch and build packages is a good idea. If you want to set a time limit to strip maintainership status of a package from someone and hand over ownership status of the package to someone else.. fine. But encouraging other contributors to blast through patch and build updates for RFE's when they don't take over full responsibility is asking for problems associated with updates. Who's job is it to fix problems associated with the new patched build? The original maintainer? Or the person who put in the patch? The default policy on patching and building should be, if you patch/build it..you own it, unless you have the blessing of the current owner(s). And this should go for the security team as well. If we get a security team and they have the authority to step in and patch/build something if the maintainer is unavailable.. then the package should clearly change ownership to the security team so its clear who is taking responsibility for problems associated with that updated package... until such time that the original maintainer is back in touch with the project or the package. > > - if 'after N (N=something between 3 and 5) failed attempts to contact > maintainer over N (N=something between 10 and 18) weeks' a package > officially is orphaned. No... i do not think allowing contributors to patch and build packages they are not taking personal responsibility for is a good idea. All this does is muddy the waters as to which group of people are going to respond to problems resulting for that extraordinary patch/build and whether or not the package is actually "orphaned". Encouraging people to hot patch something that is potentially orphaned makes it more difficult to determine if its actually orphaned or not. I do not think you can rely solely on open bugzilla ticket status as a reliable measure as to orphan status because you are not going to get consistent bugzilla usage across contributors. If you patch it in CVS without the current owner's permission then you should be responsible for it and that package should not be considered orphaned. Instead of relying completely on ways to guess if a package is orphaned.. I would prefer specific scheduled points in time when all packagers/teams re-affirm their maintainership over packages and which branches they are actively maintaining. The goal should be to establish as much multi-contributor coverage over packages as possible, before multi-contributor coverage is actually needed. A scheduled, reliable, re-affirm process will help us identify..proactively..what packages are under multi-contributor team oversight and which aren't and can help us tell the difference between a packager that has left the ranch completely and someone who is afk for a 2 week vacation. -jef -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
