Hi Folks,
Sumantro Mukherkjee and I have been working on a concept for the last few weeks on how we could try to bridge the gap between changes for the upcoming release(s) of Fedora being announced and developed, and then tested by QA later in the release cycle. What we have come up with is called a ‘Change Proposal Blueprint’ - a fancy way of saying if a change proposal owner wants some initial testing for their change, Fedora QA will try to support them by helping write and run initial basic tests.
This 'blueprint' concept is proposed as an optional step for change proposal owners, with the condition that Fedora QA can provide assistance if available. While QA has shown enthusiasm for the idea, it's important to note that support is likely but not guaranteed. The concept is primarily aimed at System Wide and Mass Rebuild changes. By integrating this option into the change proposal template, proponents hope to enhance proposals, making them clearer and more likely to be accepted by the Fedora community and FESCo. This approach also benefits QA by involving them earlier in changes, particularly those with uncertainties or extensive scopes. By facilitating early feedback and testing, potential issues can be identified sooner, giving developers more time to address them before Beta or Final releases. Additionally, offering a supported method for creating a minimal version of the change for testing enables users to identify potentially hidden breaking dependencies that may only surface during the Rawhide builds.This early detection capability, coupled with the option for preliminary testing, provides developers with more time to address any bugs before reaching the Beta or Final stages. Given the stress typically experienced as release time approaches, providing assistance with early testing at the outset of a change proposal could significantly alleviate pressure on developers and QA teams, making it a worthwhile endeavor to explore.
Our change proposal is such a powerful process, so we wanted to leverage this by introducing the option of requesting early testing support by adding it to our change proposal template. You will now see a section in the template called Early Testing (Optional) and instructions on how to reach out to Fedora QA - it's basically send an email to test@xxxxxxxxxxxxxxxxxxxxxxx with a link to your change proposal and a member of QA (likely Sumantro) will reply to you :) You can also reach out to Sumantro directly too, but preference will be to email the list as this will give you more coverage.
Some anti-goals of this idea are not to fully test a change before it goes through the process, nor is it a shortcut to land an un-approved change in Fedora either, but rather an opportunity to bring a quality mindset into the development process much earlier so Fedora can benefit from iterative development backed by quality. We expect changes to be built in a COPR and tested here where possible, and not built in rawhide directly from scratch, as Rawhide is the next Fedora release and we would rather not break that too much :)
Sumantro is the lead on this, and I will be supporting him and QA as we work together to see if this helps enhance the project's release cycle. You can reach out to either or both of us if you would like to chat in detail about it, and we would love to hear your feedback on this idea!
--
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
