Hi all,
I'm looking for some feedback on what I've got so far for the Maintainer Responsibility Policy.
http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
--
== Maintainer Responsibility Policy == === How long to maintain? === 13 months from initial release.
=== Belong to the appropriate low-traffic mailing list === * Package maintainers will receive important announcements through the moderated fedora-devel-announce mailing list. Maintainers will be automatically subscribed to this list. Everyone that is a primary maintainer of a package in Fedora is also strongly encouraged to subscribe to the fedora-devel list, though this is not mandatory. * http://www.redhat.com/mailman/listinfo/fedora-devel-announce * http://www.redhat.com/mailman/listinfo/fedora-devel-list
=== Manage security issues === * Package maintainer should handle security issues quickly, and if they need help they should contact the Security Response Team. * http://fedoraproject.org/wiki/Security/ResponseTeam
=== Deal with reported bugs in a timely manner ==== * 'Nuff said.
=== Maintain stability for users === * Package maintainers should limit updates within a single Fedora release to those which do not require special user action. Many users update automatically, and if their applications stop working from no action of their own then they will be upset. This goes doubly for services which may break overnight.
=== Track dependency issues in a timely manner === * In the development tree, and to a small degree in the release trees as well, updates to packages may cause other packages to have broken dependencies. Maintainers will be alerted when this happens, and should work to rebuild their packages with all due haste. Broken dependencies may leave end user systems in a state where no updates will be applied. In order to keep the distribution in a reasonable state, someone will step in and rebuild packages that have had dependency issues for some time, but package maintainers should not rely on these rebuilds.
=== Notify others of changes that may affect their packages === * Some packages are depended upon by others; in this case, changes to one package may cause issues for others. Maintainers should be aware of the effects that changes to their packages may have, and should alert to the fedora-devel-announce mailing list of updates which contain ABI or API changes which may cause dependency problems for other packages. The announcement should occur a week before the packages update, so all maintainers affected are notified. The announcement should include the following information: * Nature of the change. * Branches (devel, F9, etc.) which will be affected by the change. * Expected date of the change. * List of packages which are affected by the change. Generally, this is merely the list of packages which depend directly on the package which is being updated, and can be found with "repoquery --whatrequires package" where "package" is the package being updated. * If your package upgrade breaks other packages in Rawhide, you should try to help fix the packages affected. For example, when Python-2.5 was integrated into Rawhide, Jeremy Katz at least fixed the important packages and queued a rebuild for all the other packages affected.
=== Miscellaneous Items === * Maintainers need to maintain an upgrade path for their packages. * F(current-1) -> F(current) -> Rawhide * Packages should be pushed to the Rawhide branch first. If it builds and works fine for a few days, then it can be pushed to F(current). If there is a good reason to push it to F(current-1), it should be done after a few days of being in F(current). ---
Thanks, /B
On Mon, 2008-05-05 at 21:01 -0400, Brian Pepple wrote:
== Maintainer Responsibility Policy == === How long to maintain? === 13 months from initial release.
From initial Fedora release right? If you bring a package in around F10 Beta, you're expected to stick around for 13 months after F10 final goes out.
=== Belong to the appropriate low-traffic mailing list === * Package maintainers will receive important announcements through the moderated fedora-devel-announce mailing list. Maintainers will be automatically subscribed to this list.
Do we have this hooked up now, or is that a future item (the autosubscribing)
Everyone that is a primary maintainer of a package in Fedora is also strongly encouraged to subscribe to the fedora-devel list, though this is not mandatory. * http://www.redhat.com/mailman/listinfo/fedora-devel-announce * http://www.redhat.com/mailman/listinfo/fedora-devel-list
=== Manage security issues === * Package maintainer should handle security issues quickly, and if they need help they should contact the Security Response Team. * http://fedoraproject.org/wiki/Security/ResponseTeam
=== Deal with reported bugs in a timely manner ==== * 'Nuff said.
I would note here that putting a comment in the bug letting folks know when you're going to be too busy to look at the bug immediately would help.
=== Maintain stability for users === * Package maintainers should limit updates within a single Fedora release to those which do not require special user action. Many users update automatically, and if their applications stop working from no action of their own then they will be upset. This goes doubly for services which may break overnight.
=== Track dependency issues in a timely manner === * In the development tree, and to a small degree in the release trees as well, updates to packages may cause other packages to have broken dependencies. Maintainers will be alerted when this happens, and should work to rebuild their packages with all due haste. Broken dependencies may leave end user systems in a state where no updates will be applied. In order to keep the distribution in a reasonable state, someone will step in and rebuild packages that have had dependency issues for some time, but package maintainers should not rely on these rebuilds.
=== Notify others of changes that may affect their packages === * Some packages are depended upon by others; in this case, changes to one package may cause issues for others. Maintainers should be aware of the effects that changes to their packages may have, and should alert to the fedora-devel-announce mailing list of updates which contain ABI or API changes which may cause dependency problems for other packages. The announcement should occur a week before the packages update, so all maintainers affected are notified. The announcement should include the following information: * Nature of the change. * Branches (devel, F9, etc.) which will be affected by the change. * Expected date of the change. * List of packages which are affected by the change. Generally, this is merely the list of packages which depend directly on the package which is being updated, and can be found with "repoquery --whatrequires package" where "package" is the package being updated.
Shouldn't there be an --all there, as well as looking at what packages BuildRequire yours?
* If your package upgrade breaks other packages in Rawhide, you should try to help fix the packages affected. For example, when Python-2.5 was integrated into Rawhide, Jeremy Katz at least fixed the important packages and queued a rebuild for all the other packages affected.=== Miscellaneous Items === * Maintainers need to maintain an upgrade path for their packages. * F(current-1) -> F(current) -> Rawhide * Packages should be pushed to the Rawhide branch first. If it builds and works fine for a few days, then it can be pushed to F(current). If there is a good reason to push it to F(current-1), it should be done after a few days of being in F(current).
On Mon, 2008-05-05 at 21:25 -0400, Jesse Keating wrote:
On Mon, 2008-05-05 at 21:01 -0400, Brian Pepple wrote:
== Maintainer Responsibility Policy == === How long to maintain? === 13 months from initial release.
From initial Fedora release right? If you bring a package in around F10 Beta, you're expected to stick around for 13 months after F10 final goes out.
Correct. I'll clarify that.
=== Belong to the appropriate low-traffic mailing list === * Package maintainers will receive important announcements through the moderated fedora-devel-announce mailing list. Maintainers will be automatically subscribed to this list.
Do we have this hooked up now, or is that a future item (the autosubscribing)
I thought that was already hooked up, but I could be mistaken on that point. Is anyone aware of the status of this?
=== Deal with reported bugs in a timely manner ==== * 'Nuff said.
I would note here that putting a comment in the bug letting folks know when you're going to be too busy to look at the bug immediately would help.
Agreed. I'll add it.
=== Notify others of changes that may affect their packages === * Some packages are depended upon by others; in this case, changes to one package may cause issues for others. Maintainers should be aware of the effects that changes to their packages may have, and should alert to the fedora-devel-announce mailing list of updates which contain ABI or API changes which may cause dependency problems for other packages. The announcement should occur a week before the packages update, so all maintainers affected are notified. The announcement should include the following information: * Nature of the change. * Branches (devel, F9, etc.) which will be affected by the change. * Expected date of the change. * List of packages which are affected by the change. Generally, this is merely the list of packages which depend directly on the package which is being updated, and can be found with "repoquery --whatrequires package" where "package" is the package being updated.
Shouldn't there be an --all there, as well as looking at what packages BuildRequire yours?
Yeah, I think your right.
Thanks for the feedback, Jesse.
Later, /B
On Tuesday 06 May 2008, Brian Pepple wrote:
On Mon, 2008-05-05 at 21:25 -0400, Jesse Keating wrote:
On Mon, 2008-05-05 at 21:01 -0400, Brian Pepple wrote:
* List of packages which are affected by the change. Generally, this is merely the list of packages which depend directly on the package which is being updated, and can be found with "repoquery --whatrequirespackage" where "package" is the package being updated.
Shouldn't there be an --all there, as well as looking at what packages BuildRequire yours?
Yeah, I think your right.
I believe Jesse meant --alldeps. --all in this context does not make much sense to me, but --alldeps does very much. I already went ahead and changed this in Wiki.
The bit about checking what packages BuildRequire the updated package from Jesse's suggestion above seems to be missing still, was that intentionally omitted?
On Mon, 05 May 2008 21:01:35 -0400 bpepple@fedoraproject.org (Brian Pepple) wrote:
Hi all,
I'm looking for some feedback on what I've got so far for the Maintainer Responsibility Policy.
http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
--
== Maintainer Responsibility Policy == === How long to maintain? === 13 months from initial release.
=== Belong to the appropriate low-traffic mailing list === * Package maintainers will receive important announcements through the moderated fedora-devel-announce mailing list. Maintainers will be automatically subscribed to this list. Everyone that is a primary maintainer of a package in Fedora is also strongly encouraged to subscribe to the fedora-devel list, though this is not mandatory. * http://www.redhat.com/mailman/listinfo/fedora-devel-announce * http://www.redhat.com/mailman/listinfo/fedora-devel-list === Manage security issues === * Package maintainer should handle security issues quickly, and if they need help they should contact the Security Response Team. * http://fedoraproject.org/wiki/Security/ResponseTeam
=== Deal with reported bugs in a timely manner ==== * 'Nuff said.
I think this needs expanding...
I would add:
"If you find yourself unable to handle the load of bugs from your package(s), please ask for assistance on the fedora-devel and/or fedora-test lists. Teaching triagers about how to triage your bugs or getting help from other maintainers can not only reduce your load, but improve Fedora. Consider reaching out for some (more) co-maintainers to assist as well".
=== Maintain stability for users === * Package maintainers should limit updates within a single Fedora release to those which do not require special user action. Many users update automatically, and if their applications stop working from no action of their own then they will be upset. This goes doubly for services which may break overnight.
I would add additionally:
"Maintainers should not push every single upstream update to all branches. Examine the changes in each upstream release and ask if the update is worth download and update time for many users. For upstreams that update very often with many small updates, consider waiting and updated only when the amount of changes is worth updating.
=== Track dependency issues in a timely manner === * In the development tree, and to a small degree in the release trees as well, updates to packages may cause other packages to have broken dependencies. Maintainers will be alerted when this happens, and should work to rebuild their packages with all due haste. Broken dependencies may leave end user systems in a state where no updates will be applied. In order to keep the distribution in a reasonable state, someone will step in and rebuild packages that have had dependency issues for some time, but package maintainers should not rely on these rebuilds.
Bodhi should prevent this in released branches now... so might need a bit of re-wording.
=== Notify others of changes that may affect their packages === * Some packages are depended upon by others; in this case, changes to one package may cause issues for others. Maintainers should be aware of the effects that changes to their packages may have, and should alert to the fedora-devel-announce mailing list of updates which contain ABI or API changes which may cause dependency problems for other packages. The announcement should occur a week before the packages update, so all maintainers affected are notified. The announcement should include the following information: * Nature of the change. * Branches (devel, F9, etc.) which will be affected by the change. * Expected date of the change. * List of packages which are affected by the change. Generally, this is merely the list of packages which depend directly on the package which is being updated, and can be found with "repoquery --whatrequires package" where "package" is the package being updated. * If your package upgrade breaks other packages in Rawhide, you should try to help fix the packages affected. For example, when Python-2.5 was integrated into Rawhide, Jeremy Katz at least fixed the important packages and queued a rebuild for all the other packages affected.
Might be worth mentioning the gcc and/or perl updates... where they were done entirely in another tag and fixes were made until the landing of the updates were pretty painless overall.
=== Miscellaneous Items === * Maintainers need to maintain an upgrade path for their packages. * F(current-1) -> F(current) -> Rawhide * Packages should be pushed to the Rawhide branch first. If it builds and works fine for a few days, then it can be pushed to F(current). If there is a good reason to push it to F(current-1), it should be done after a few days of being in F(current).
Looks like a good start... ;)
Thanks,
Thanks for looking at this.
/B
kevin
On Mon, 2008-05-05 at 20:10 -0600, Kevin Fenzi wrote:
On Mon, 05 May 2008 21:01:35 -0400 bpepple@fedoraproject.org (Brian Pepple) wrote:
=== Deal with reported bugs in a timely manner ==== * 'Nuff said.
"If you find yourself unable to handle the load of bugs from your package(s), please ask for assistance on the fedora-devel and/or fedora-test lists. Teaching triagers about how to triage your bugs or getting help from other maintainers can not only reduce your load, but improve Fedora. Consider reaching out for some (more) co-maintainers to assist as well".
Added.
=== Maintain stability for users === * Package maintainers should limit updates within a single Fedora release to those which do not require special user action. Many users update automatically, and if their applications stop working from no action of their own then they will be upset. This goes doubly for services which may break overnight.
I would add additionally:
"Maintainers should not push every single upstream update to all branches. Examine the changes in each upstream release and ask if the update is worth download and update time for many users. For upstreams that update very often with many small updates, consider waiting and updated only when the amount of changes is worth updating.
Added.
=== Track dependency issues in a timely manner === * In the development tree, and to a small degree in the release trees as well, updates to packages may cause other packages to have broken dependencies. Maintainers will be alerted when this happens, and should work to rebuild their packages with all due haste. Broken dependencies may leave end user systems in a state where no updates will be applied. In order to keep the distribution in a reasonable state, someone will step in and rebuild packages that have had dependency issues for some time, but package maintainers should not rely on these rebuilds.
Bodhi should prevent this in released branches now... so might need a bit of re-wording.
Good suggestion. I changed that to refer to Rawhide only, since that should be the only branch affected.
Thanks, Kevin!
Later, /B
Le lundi 05 mai 2008 à 22:22 -0400, Brian Pepple a écrit :
On Mon, 2008-05-05 at 20:10 -0600, Kevin Fenzi wrote:
On Mon, 05 May 2008 21:01:35 -0400 bpepple@fedoraproject.org (Brian Pepple) wrote:
=== Maintain stability for users === * Package maintainers should limit updates within a single Fedora release to those which do not require special user action. Many users update automatically, and if their applications stop working from no action of their own then they will be upset. This goes doubly for services which may break overnight.
I would add additionally:
"Maintainers should not push every single upstream update to all branches. Examine the changes in each upstream release and ask if the update is worth download and update time for many users. For upstreams that update very often with many small updates, consider waiting and updated only when the amount of changes is worth updating.
Added.
***Except for fedora devel***
Maintainers that only update devel a few days before the freeze and ignore intermediary versions (where problems in the package or in its interaction with others could be identified and reported upstream) are as time-wasting as maintainers who push everything everywhere.
Fedora devel has a limited number of users (except just before a release). That does not mean ignoring it is ok for a maintainer.
Brian Pepple wrote:
=== Deal with reported bugs in a timely manner ==== * 'Nuff said.
"Deal with" meaning what, exactly? When the maintainer has reported the bug to upstream in a timely manner, his job is done and he can patiently wait for years until upstream fixes the bug or not?
Hans Ulrich Niedermann wrote:
Brian Pepple wrote:
=== Deal with reported bugs in a timely manner ==== * 'Nuff said.
"Deal with" meaning what, exactly? When the maintainer has reported the bug to upstream in a timely manner, his job is done and he can patiently wait for years until upstream fixes the bug or not?
A little more than that:
1) Someone who can work on the bug should know about it. - If the package maintainer is capable and willing, they can be working on fixing it. - If not, the package maintainer should have tried at least some of the following options: * reported it upstream. * asked for help on fedora-devel (there are people who volunteer their time to work on code/autotools problems that other package maintainers have) * checked if other distributions have patches for the problem already (google often finds patches in Debian, for instance.)
2) Let the bug reporter know what's going on with the bug report. If that happens to be that they reported it upstream and upstream has proven disinterested in fixing it, having an upstream bug#, etc is very useful. Then the bug reporter can try to get upstream to fix the bug themselves.
Brian, we probably want to list the ways to deal with bug reports in the policy as many maintainers don't realize how many options there are for getting help fixing a bug.
-Toshio
On Tue, 2008-05-06 at 07:26 -0700, Toshio Kuratomi wrote: <snip>
Brian, we probably want to list the ways to deal with bug reports in the policy as many maintainers don't realize how many options there are for getting help fixing a bug.
Here's what I've got right now (from Kevin's suggestion) in the section regarding bugs:
"If you find yourself unable to handle the load of bugs from your package(s), please ask for assistance on the fedora-devel and/or fedora-test lists. Teaching triagers about how to triage your bugs or getting help from other maintainers can not only reduce your load, but improve Fedora. Consider reaching out for some (more) co-maintainers to assist as well."
Do we want to expand on that?
Later, /B
Brian Pepple wrote:
On Tue, 2008-05-06 at 07:26 -0700, Toshio Kuratomi wrote:
<snip> > Brian, we probably want to list the ways to deal with bug reports in the > policy as many maintainers don't realize how many options there are for > getting help fixing a bug.
Here's what I've got right now (from Kevin's suggestion) in the section regarding bugs:
"If you find yourself unable to handle the load of bugs from your package(s), please ask for assistance on the fedora-devel and/or fedora-test lists. Teaching triagers about how to triage your bugs or getting help from other maintainers can not only reduce your load, but improve Fedora. Consider reaching out for some (more) co-maintainers to assist as well."
Yeah. I think it's worthwhile to mention something like this:
"Even bugs that you aren't capable of fixing yourself because they deal with intricacies of the source code that you don't have the knowledge to fix deserve a few moments of your time. You can report the bug upstream for the user, ask for help from more code-oriented people on fedora-devel, or check whether other distros have patches for the problem. Always be sure to post to the bug report what you have done so that the reporter has a proper expectation of whether you're working on a fix or if it's something that has to wait on upstream action."
-Toshio
On Tue, 2008-05-06 at 09:12 -0700, Toshio Kuratomi wrote:
Yeah. I think it's worthwhile to mention something like this:
"Even bugs that you aren't capable of fixing yourself because they deal with intricacies of the source code that you don't have the knowledge to fix deserve a few moments of your time. You can report the bug upstream for the user, ask for help from more code-oriented people on fedora-devel, or check whether other distros have patches for the problem. Always be sure to post to the bug report what you have done so that the reporter has a proper expectation of whether you're working on a fix or if it's something that has to wait on upstream action."
Added. Thanks for the suggestion, Toshio.
Later, /B
On Tue, 2008-05-06 at 09:12 -0700, Toshio Kuratomi wrote:
Yeah. I think it's worthwhile to mention something like this:
"Even bugs that you aren't capable of fixing yourself because they deal with intricacies of the source code that you don't have the knowledge to fix deserve a few moments of your time. You can report the bug upstream for the user, ask for help from more code-oriented people on fedora-devel, or check whether other distros have patches for the problem. Always be sure to post to the bug report what you have done so that the reporter has a proper expectation of whether you're working on a fix or if it's something that has to wait on upstream action."
I'm not sure that's strong enough. It should clearly state that the package maintainer is responsible for getting bugs fixed -- if the package maintainer isn't a coder, then they need to take a more managerial röle; working with upstream or with code-monkeys within Fedora to get things fixed. How about this:
If there are bugs which you aren't capable of fixing yourself because they deal with intricacies of the source code which you don't fully understand, then you still need to address these bugs. It can be helpful to work with the upstream maintainer of the code, obtain help from more code-oriented people on fedora-devel, or check other distributions for patches. Always be sure to post to the bug report what you have done so that the reporter knows what it happening and what to expect. It is recommended that non-coder packagers should find co-maintainers who are familiar with the programming language used by their package(s), and can help with such bugs as a kind of 'second line support'.
On Wed, 2008-05-07 at 11:07 +0100, David Woodhouse wrote:
I'm not sure that's strong enough. It should clearly state that the package maintainer is responsible for getting bugs fixed -- if the package maintainer isn't a coder, then they need to take a more managerial röle; working with upstream or with code-monkeys within Fedora to get things fixed. How about this:
If there are bugs which you aren't capable of fixing yourself because they deal with intricacies of the source code which you don't fully understand, then you still need to address these bugs. It can be helpful to work with the upstream maintainer of the code, obtain help from more code-oriented people on fedora-devel, or check other distributions for patches. Always be sure to post to the bug report what you have done so that the reporter knows what it happening and what to expect. It is recommended that non-coder packagers should find co-maintainers who are familiar with the programming language used by their package(s), and can help with such bugs as a kind of 'second line support'.
Added your suggestion.
Thanks, /B
On Wed, May 7, 2008 at 2:07 AM, David Woodhouse dwmw2@infradead.org wrote:
I'm not sure that's strong enough. It should clearly state that the package maintainer is responsible for getting bugs fixed -- if the package maintainer isn't a coder, then they need to take a more managerial röle; working with upstream or with code-monkeys within Fedora to get things fixed. How about this:
Do we need to make an effort to catalog skillsets in the contributor base? to make it easier to help maintainers find a particular sort of code-monkey? For example I know you are one of the people I can come to with ppc oddness that I can't fix myself, but I'd have no idea how to turn to for say ruby-ness.
But generally speaking would it be worthwhile if 'we' made it easier for maintainers to find other contributors who could help with specific bugs based on skillset needed?
-jef"And yes i realize we can't really call people code-monkeys"spaleta
On Wed, 2008-05-07 at 09:10 -0800, Jeff Spaleta wrote:
On Wed, May 7, 2008 at 2:07 AM, David Woodhouse dwmw2@infradead.org wrote:
I'm not sure that's strong enough. It should clearly state that the package maintainer is responsible for getting bugs fixed -- if the package maintainer isn't a coder, then they need to take a more managerial röle; working with upstream or with code-monkeys within Fedora to get things fixed. How about this:
Do we need to make an effort to catalog skillsets in the contributor base? to make it easier to help maintainers find a particular sort of code-monkey?
Yes, perhaps. Or maybe it would be better to have a code-monkey sign up as co-maintainer for the package, where the primary maintainer isn't capable of actually..., well, maintaining the package.
On Thu, May 8, 2008 at 6:55 AM, David Woodhouse dwmw2@infradead.org wrote:
Yes, perhaps. Or maybe it would be better to have a code-monkey sign up as co-maintainer for the package, where the primary maintainer isn't capable of actually..., well, maintaining the package.
Generally, I would agree that the maintainer needs to be able to diagnose breakage in the dominant language of the package in question. Hence why I don't touch mono or java packages. But, there are times when an application might provide mixed language or toolkit bindings which are harder to adequately account for based on accumulated personal experience. And we certainly can't expect everyone to have direct experience nor access to both big and little endian arches.
And well, it'd be sort of nice to know how our contributor skillset breaks down, from a project resources point of view.
-jef"Though in just a couple more years, we could probably expect everyone to have access to some sort of 64bit arch"spaleta
On 05/06/2008 03:54 PM, Brian Pepple wrote:
On Tue, 2008-05-06 at 07:26 -0700, Toshio Kuratomi wrote:
<snip>
Brian, we probably want to list the ways to deal with bug reports in the policy as many maintainers don't realize how many options there are for getting help fixing a bug.
Here's what I've got right now (from Kevin's suggestion) in the section regarding bugs:
"If you find yourself unable to handle the load of bugs from your package(s), please ask for assistance on the fedora-devel and/or fedora-test lists. Teaching triagers about how to triage your bugs or getting help from other maintainers can not only reduce your load, but improve Fedora. Consider reaching out for some (more) co-maintainers to assist as well."
Do we want to expand on that?
FYI
If bugs need (Re)testing or a component needs a speedup treatment in bodhi drop a testing request to fedora-test list and/or file a request in Fedora QA trac instance on https://fedorahosted.org/fedora-qa and we will take care of it. We also assisting in any test case creation, setup test day's etc. Dont hesitate to drop a mail to the test-list or open a ticktet in Fedora QA trac instance
JBG
2008/5/6 Brian Pepple bpepple@fedoraproject.org:
Hi all,
I'm looking for some feedback on what I've got so far for the Maintainer Responsibility Policy.
http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
--
== Maintainer Responsibility Policy == === How long to maintain? === 13 months from initial release.
=== Belong to the appropriate low-traffic mailing list === * Package maintainers will receive important announcements through the moderated fedora-devel-announce mailing list. Maintainers will be automatically subscribed to this list. Everyone that is a primary maintainer of a package in Fedora is also strongly encouraged to subscribe to the fedora-devel list, though this is not mandatory. * http://www.redhat.com/mailman/listinfo/fedora-devel-announce * http://www.redhat.com/mailman/listinfo/fedora-devel-list
=== Manage security issues === * Package maintainer should handle security issues quickly, and if they need help they should contact the Security Response Team. * http://fedoraproject.org/wiki/Security/ResponseTeam
=== Deal with reported bugs in a timely manner ==== * 'Nuff said.
=== Maintain stability for users === * Package maintainers should limit updates within a single Fedora release to those which do not require special user action. Many users update automatically, and if their applications stop working from no action of their own then they will be upset. This goes doubly for services which may break overnight.
=== Track dependency issues in a timely manner === * In the development tree, and to a small degree in the release trees as well, updates to packages may cause other packages to have broken dependencies. Maintainers will be alerted when this happens, and should work to rebuild their packages with all due haste. Broken dependencies may leave end user systems in a state where no updates will be applied. In order to keep the distribution in a reasonable state, someone will step in and rebuild packages that have had dependency issues for some time, but package maintainers should not rely on these rebuilds.
=== Notify others of changes that may affect their packages === * Some packages are depended upon by others; in this case, changes to one package may cause issues for others. Maintainers should be aware of the effects that changes to their packages may have, and should alert to the fedora-devel-announce mailing list of updates which contain ABI or API changes which may cause dependency problems for other packages. The announcement should occur a week before the packages update, so all maintainers affected are notified. The announcement should include the following information: * Nature of the change. * Branches (devel, F9, etc.) which will be affected by the change. * Expected date of the change. * List of packages which are affected by the change. Generally, this is merely the list of packages which depend directly on the package which is being updated, and can be found with "repoquery --whatrequires package" where "package" is the package being updated. * If your package upgrade breaks other packages in Rawhide, you should try to help fix the packages affected. For example, when Python-2.5 was integrated into Rawhide, Jeremy Katz at least fixed the important packages and queued a rebuild for all the other packages affected.
=== Miscellaneous Items === * Maintainers need to maintain an upgrade path for their packages. * F(current-1) -> F(current) -> Rawhide * Packages should be pushed to the Rawhide branch first. If it builds and works fine for a few days, then it can be pushed to F(current). If there is a good reason to push it to F(current-1), it should be done after a few days of being in F(current).
I think you should also mention the act of "pushing to testing" repo for each current fedora release.
Thanks, /B -- Brian Pepple bpepple@fedoraproject.org
http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Tue, 2008-05-06 at 15:10 +0200, Xavier Lamien wrote:
2008/5/6 Brian Pepple bpepple@fedoraproject.org:
=== Miscellaneous Items === * Maintainers need to maintain an upgrade path for their packages. * F(current-1) -> F(current) -> Rawhide * Packages should be pushed to the Rawhide branch first. If it builds and works fine for a few days, then it can be pushed to F(current). If there is a good reason to push it to F(current-1), it should be done after a few days of being in F(current).I think you should also mention the act of "pushing to testing" repo for each current fedora release.
Yeah, that's not a bad idea. I believe when that section was written, Bodhi wasn't even around (which tells you how long this proposal has been around). I'll add a note.
Thanks, /B
Brian Pepple wrote:
On Tue, 2008-05-06 at 15:10 +0200, Xavier Lamien wrote:
* Packages should be pushed to the Rawhide branch first. If it builds and works fine for a few days, then it can be pushed to F(current). If there is a good reason to push it to F(current-1), it should be done after a few days of being in F(current).I think you should also mention the act of "pushing to testing" repo for each current fedora release.
Yeah, that's not a bad idea. I believe when that section was written, Bodhi wasn't even around (which tells you how long this proposal has been around). I'll add a note.
A restriction of "few days" might complicate the maintainer work. It is much more easy to compile for all the branches at one time, rather than to plan it for 3 different days. IMO it would be better if such a delaying will be performed automatically at "updates-testing-->updates" stage...
"BP" == Brian Pepple writes:
BP> Hi all, I'm looking for some feedback on what I've got so far for BP> the Maintainer Responsibility Policy.
BP> http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
As Extras is defunct, all the wiki pages under the namespace: Extras/Schedule
should probably be moved under the new namespace: Development/Schedule
I made a start by moving:
http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
to:
http://fedoraproject.org/wiki/Development/Schedule/MaintainerResponsibilityP...
I think I got all the places that also linked to it (I also created a redirect so that people who only have the old URL from previous messages will be redirected to it fine). Let me know if not.
Alex
devel@lists.stg.fedoraproject.org
-
"Jóhann B. Guðmundsson" -
Alex Lancaster -
Brian Pepple -
David Woodhouse -
Dmitry Butskoy -
Hans Ulrich Niedermann -
Jef Spaleta -
Jesse Keating -
Kevin Fenzi -
Nicolas Mailhot -
Toshio Kuratomi -
Ville Skyttä -
Xavier Lamien