https://bugzilla.redhat.com/show_bug.cgi?id=1908526 --- Comment #21 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- > Concerning the submission to rawhide, looking at step 12 of https://fedoraproject.org/wiki/New_package_process_for_existing_contributors , I am not clear which Resolution I should choose for the closure of a bug such as this one. I have chosen Resolution: RAWHIDE, but Resolution: NEXTRELEASE seems just as good, I'm unsure about the difference. Maybe I haven't yet stumbled upon the doc that explains it. I don’t think it matters much. RAWHIDE is common for manual closure of a review request. If you associate the bug with a “newpackage” update for a stable release and have it auto-close it, then it will look like this: https://bugzilla.redhat.com/show_bug.cgi?id=1974821 ----- > To submit an update for f34 or f33, it looks like I have to prepare a test case that will allow testers to try and see that python-opentracing works, correct? It might be quite involving, users would have to spawn a container with a jaegertracing server, run some test Python program and see things happening in the jaegertracing web UI... This might take some time until I can finally submit updates for f33/f34 or even epel8. You can do this. It is “recommended.” (https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/#_work_with_testing) As far as I can tell, test cases belong here (https://fedoraproject.org/wiki/Category:Test_Cases), and the procedures for creating test cases and test plans are linked from that page. In practice, you can see that there are roughly 130 packages on that page, out of over 30 thousand packages in Fedora. Few packagers make these test cases, and most of the time you’ll never see anyone testing your updates anyway. You can also set up automated tests for your package (https://docs.fedoraproject.org/en-US/ci/). This is a great idea, but there’s a nontrivial learning curve and a lot of YAML to write, so it isn’t mandatory either. In practice, most packages have neither wiki test cases nor manually-configured CI gating, and that’s unlikely to change. ----- So here are the steps for using Bodhi, which you’ve probably already read: https://fedoraproject.org/wiki/Package_update_HOWTO#Later_Branched_and_stable_releases. Basically, the workflow for an update to a stable release goes like this: 1. If it’s a newpackage update, go ahead to the next step. If it’s a bugfix or enhancement update, consider if it contains any breaking API changes (or, for compiled libraries, ABI changes). For a tool or application, consider if it contains significant changes to the user experience. If so, the update shouldn’t go in a stable release. If there is a good reason to break this rule (for example, a security fix that can’t be backported), you should petition FESCo (Fedora Engineering Steering Council) for an exception. You’ll probably never have to do that. 2. OK, it’s a newpackage update, or a compatible patch or minor update. You’ve merged changes into the appropriate stable branch (“git merge rawhide”, or “git cherry-pick …”, depending on how you like to manage your branches). You’ve pushed to the branch and built the package. (I know you’ve gotten this far.) Now you can choose to use the Bodhi CLI, which is most easily accessed as “fedpkg update”, or the web interface at https://bodhi.fedoraproject.org/updates/new. The fields are pretty much the same for both. 3. If you are using the CLI, you already have a build associated with the update. If you are using the web interface, find the package you built. You should create separate updates for separate branches, i.e., one for F34 and one for F33. 4. Type a quick description of what has changed. This is for the benefit of end-users, so keep it simple and informative. When the update provides a new version, copying in the upstream changelog can be nice, if there is a useful one. For the initial newpackage update, you can just write something like “Initial package”. 5. Pick an update type. These are pretty self-explanatory. This time you’ll want “newpackage”. 6. You can leave severity unspecified except for security updates. You can leave suggestion unspecified unless there’s some reason you think users should logout or reboot after the update. That mostly applies to libraries likely to be used by the desktop session or by various daemons, especially when the update is a security one. 7. You can associate one or more bugs with the update. For a newpackage update, it’s nice to associate the review request issue (this bug). For an enhancement or bugfix update, there might or might not be a bug corresponding to an issue that’s fixed in the update, or a “new release is available” bug filed by upstream release monitoring (anitya). You usually do want to enable “close bugs” so that the status of the bug follows the update’s progress into testing and then stable. There is no requirement to have a bug for an update, even for a “bugfix” update. 8. You almost always want to disable “require bugs.” It’s very likely that nobody will ever test your package, so your update will sit in testing forever if you leave this enabled. 9. You should usually use the default karma and time settings. The minimums are 3/-3 karma and 7 days. This means that, normally, your package will sit in testing for a week and then get automatically pushed to stable. If you manage to attract three testers, and they all report the update is OK, then it will get pushed to stable early. ----- Does that make more sense? If something is still not clear, please keep asking questions! -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
