On Friday, March 2, 2012, 12:23:51 PM, Jóhann wrote: > On 03/02/2012 05:10 PM, Rahul Sundaram wrote: >> Again, what access do you need and who have you asked for it? > It's pretty obvious that this is a proposal I made today thus I have > asked no one for it nor can I since infrastructure has made it clear to > me when I asked them to fix my user accounting mess that I found myself > into that they do not handle bugzilla that is Red Hat only territory. > Secondly first we need to reach conscious about the proposal in general > then if reached settle on a time frame for the automatic process to > start taking place as Aleksandar and other have pointed out. > I'm not sure how you do things in your part of the world but usually > here on top of the world we dont start building houses without knowing > first how they should look like... Perhaps one factor is that what you are trying to build may not be right for the problem at hand, and a new solution is required for a different sort of problem? Or perhaps the issue is that we only have one sort of tool/process, and you are attempting to solve your problem with that tool when a better solution would be to propose a new tool. The NonResponsiveMaintainer process is designed to remove all packages from a maintainer who has gone missing, and is no longer able to take care of their duties as a Fedora package owner. It seems to me that many who object to using this large hammer to solve what some view (correctly or incorrectly) as one minor packaging issue of many. Perhaps it would be better to view this as something more akin to the FTBFS (fails to build from source) process, where regular attempts are made to build packages from source, and those failures tracked. That and the follow-up process are more of an "action required by maintainer" type of process than a "fix it now or else" process. I would suggest that you might be better to propose a generalized "FTFPG" (fails to follow packaging guidelines) process, of which one of the first regular automated checks would be to discover and track packages that are not enabled for systemd. This would expand over time to check for other packages which violate other guidelines for which automated checks can be created. Automation would include creating bugs, tracking reports, and should have exception lists to support known/approved exceptions. By the way, that automation would need to be in a package... which might well be suitable to be your one/only Fedora package. 8^) -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
