Re: CVS admin requests
On Thu, 1 Jul 2010 13:32:20 -0600, Kevin wrote: The page Package Change Requests for existing packages is unclear: http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure#Package_Change_Requests_for_existing_packages Please expand on what explanatory text you want in addition to the Package Change Request template. If there is a branch request, e.g. for a released dist version, is it necessary to transcribe the filled out template into a full sentence? Well, I'm not sure how to rephrase that... Basically we want to know if there are any non standard conditions to look at, ie: - You are not the owner and want to maintain in epel. Did you contact the fedora owner and wait and/or hear back that they didn't want to maintain it? How would I know that this would be relevant? And why is it relevant? Can the Fedora package owner block another packager's request to become the maintainer in EPEL? I don't think so. - Is the package a dead package you are bringing back? etc. You don't need to add additional text for normal vanilla regular requests. Now that you've given two examples, can't you simply sum up the special situations in which you demand additional details? How many are there? - resurrecting an orphan or retired package - bringing a package to EPEL - ... - (?) transferring ownership You know your requirements, so tell people what input you need. It just saves cvsadmins the time to ask you what you want. What is the template for then? It specifies exactly what a person wants. If you are interested in some background (a full story of what had happened prior to somebody filling out the template), you could enumerate the special cirumstances when you need those extra details. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CVS admin requests
On Fri, 2 Jul 2010 21:50:08 +0200 Michael Schwendt mschwe...@gmail.com wrote: ...snip... - You are not the owner and want to maintain in epel. Did you contact the fedora owner and wait and/or hear back that they didn't want to maintain it? How would I know that this would be relevant? And why is it relevant? Can the Fedora package owner block another packager's request to become the maintainer in EPEL? I don't think so. No. There is a process however: - Check to see if fedora packager is on the I don't do EPEL list If they are, great, request. - If they are not on that list, file a bug and ask if they wish to maintain in EPEL. If they say no in the bug, great, request. - If they don't answer in a week, great request. Sometimes however we get requests that request the branch, are filed on something different where the fedora maintainer is not cc'ed and they don't want to wait a week anyhow. - Is the package a dead package you are bringing back? etc. You don't need to add additional text for normal vanilla regular requests. Now that you've given two examples, can't you simply sum up the special situations in which you demand additional details? How many are there? I don't know. When have you been asked for additional details? - resurrecting an orphan or retired package - bringing a package to EPEL - ... - (?) transferring ownership You know your requirements, so tell people what input you need. Sure, How about we strike that part entirely, and if there is some question, cvsadmin's can just ask in the bug. It just saves cvsadmins the time to ask you what you want. What is the template for then? It specifies exactly what a person wants. If you are interested in some background (a full story of what had happened prior to somebody filling out the template), you could enumerate the special cirumstances when you need those extra details. Because sometimes we don't know if we can act on the template right then. Another example: New package review cvs request, but the submitter says someone else entirely should be the owner of the new package. Should we ask them if the person has said thats ok? If they added a note saying I've asked bob to be the owner, as he works on this upstream, he's ok with this. It would save us the round trip to ask that. Anyhow, I guess I would say we should just strike that and cvsadmins can ask if there are questions. I just don't want people to get mad at a delay when we do so. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CVS admin requests
On Sat, 26 Jun 2010 11:21:06 +0200 Michael Schwendt mschwe...@gmail.com wrote: The page Package Change Requests for existing packages is unclear: http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure#Package_Change_Requests_for_existing_packages Please expand on what explanatory text you want in addition to the Package Change Request template. If there is a branch request, e.g. for a released dist version, is it necessary to transcribe the filled out template into a full sentence? Well, I'm not sure how to rephrase that... Basically we want to know if there are any non standard conditions to look at, ie: - You are not the owner and want to maintain in epel. Did you contact the fedora owner and wait and/or hear back that they didn't want to maintain it? - Is the package a dead package you are bringing back? etc. You don't need to add additional text for normal vanilla regular requests. It just saves cvsadmins the time to ask you what you want. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
CVS admin requests
The page Package Change Requests for existing packages is unclear: http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure#Package_Change_Requests_for_existing_packages Please expand on what explanatory text you want in addition to the Package Change Request template. If there is a branch request, e.g. for a released dist version, is it necessary to transcribe the filled out template into a full sentence? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
