Mass package changes

Mass bug filing

Introduction

From time to time when changes are required accross a group of packages it may be required to mass file bugs against all packages in that group. This page attempts to describe steps to take before filing these sorts of mass bugs and how to file them in the event you need to.

Gain consensus of needed changes

First you should post to the Fedora devel list and gain consensus for the changes you want to make (also mention which packages are affected). No matter how simple or needed you might think they are, there may be better ways to do things or the change may not be needed for other reasons. After gaining a consensus from the list you may also ask involved maintainers to simply change their packages then.

Review announcement / bug text

Either ask the list or several interested maintainers to look over the text you intend to send to the devel-announce list (next step) and intend to use in your bug text. This will help make your text clear and understandable and free from typos or other simple errors. Make sure several people see your text and agree it describes the problem clearly along with solutions.

Announce to devel-announce

Once you have a clear idea of the changes needed, post a clear email on changes needed to the devel-announce list. Wait at least a week to allow maintainers to make changes or ask you further questions about the change on the devel list. If the change must be done due to some deadline, please note it in the email. If you intend to have provenpackager(s) simply make the changes to all unchanged packages, please note that as well in the email.

File tracker bug

Now you can file a tracker bug and bugs against all the packages that still need changes. Note that you should check to make sure maintainers didn't already make the changes and only file bugs against those packages that didn't.

Things to note in bugs

• Make sure you note what releases you consider must be fixed, or if only rawhide is fine.

• Note if you wish updates to be sumitted simply for this change, or if the change can be pushed the next time there is another reason to update.

• Link to the specific wiki page or guideline that is affected.

• If the change is small, please include what the maintainer needs to add or remove specifically from their spec.

• Note the announcements and any mailing list threads where the change has been discussed.

• Note any deadlines where provenpackagers might step in and make changes.

• Note where maintainers can provide feedback or ask for more information if the bug is unclear.

• Include the name of the package in the summary line of each child bug, so that it is possible to quickly see the affected components in the tree view.