On Mon, 2024-10-14 at 12:21 +0200, Quentin Schulz via lists.openembedded.org wrote: > Hi Katariina, > > On 10/8/24 8:33 AM, Katariina Lounento via lists.openembedded.org wrote: > > [You don't often get email from > > [email protected]. Learn why this is > > important at https://aka.ms/LearnAboutSenderIdentification ] > > > > From: Katariina Lounento <[email protected]> > > > > The list of valid statuses (`upstream_status_literal_valid_status`) was > > missing "Inactive-Upstream", which caused patchtest to fail the test > > test_patch.TestPatch.test_upstream_status_presence_format for patches > > containing lines like: > > > > +Upstream-Status: Inactive-Upstream [lastrelease: 2013 lastcommit: > > 2013] > > > > with the error: > > > > FAIL: test Upstream-Status presence: Upstream-Status is in incorrect > > format (test_patch.TestPatch.test_upstream_status_presence_format) > > > > "Inactive-Upstream" is documented in the Yocto Project and OpenEmbedded > > Contributor Guide [1]: > > > > Inactive-Upstream [lastcommit: when (and/or) lastrelease: when] > > > > The upstream is no longer available. This typically means a > > defunct project where no activity has happened for a long time — > > measured in years. To make that judgement, it is recommended to > > look at not only when the last release happened, but also when > > the last commit happened, and whether newly made bug reports and > > merge requests since that time receive no reaction. It is also > > recommended to add to the patch description any relevant links > > where the inactivity can be clearly seen. > > > > I'm wondering if we simply shouldn't remove this status?
We (as a project) have had this discussion before. There are indeed two sides to this and I can see them both. > I believe even if the project is inactive, we should still aim at > submitting patches in the event the project starts again, or maybe it's > just that nobody has sent a patch for years and the SW works good enough > for all people involved. Some of the inactive software has no place to actually visibly share patches. The other advantage to having a separate state is that it more easily allows people to focus on the areas where we can make a difference. It also gives us a big hint about which software poses a different set of risks if there is no active maintenance being done on it. Overall, I think having the state does have some benefits. I do agree we should submit where we possibly can though. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#205742): https://lists.openembedded.org/g/openembedded-core/message/205742 Mute This Topic: https://lists.openembedded.org/mt/108884475/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
