Systemd discusses its kernel-version needs
Systemd discusses its kernel-version needs
Posted Mar 31, 2022 22:11 UTC (Thu) by excors (subscriber, #95769)In reply to: Systemd discusses its kernel-version needs by johannbg
Parent article: Systemd discusses its kernel-version needs
That sounds totally untrue. A healthy well-resourced project will have lots of users, who inevitably submit many low-quality bug reports where it will take a large amount of effort to investigate a very rare or non-existent bug, and will also have an endless stream of ideas for new features and improvements with varying levels of effort and value. It's always important to prioritise, because resources are always finite and there will be lots of issues that are never worth fixing. A project that *doesn't* have to prioritise is one that has few users and the developers have run out of ideas, which would not be a good sign.
Also the effort/value cutoff point will vary over time, as the list of outstanding issues and available resources vary, or as you accumulate more reports of a particular bug or feature request, so it's not practical to immediately WONTFIX everything below a certain threshold - it's better to leave them open in the issue tracker because there's a chance they might become worthwhile later. As long as the issue tracker has a decent UI, it's fine to have thousands of open issues.
(There would be a serious resourcing problem if the issues don't even get triaged and nobody can tell whether they ought to be high priority or not. But systemd doesn't appear to have that problem - nearly all the recent still-open issues have comments and labels that indicate a developer has looked at them, and a large majority of the ones labeled "regression" or "bug" are closed, and half of the open issues are RFEs, so the first impression is that they're doing okay.)
Posted Mar 31, 2022 23:09 UTC (Thu)
by johannbg (guest, #65743)
[Link] (1 responses)
Feel free to do your own research, own math yourself and your own resource measurements, but by my experience ( my own and work ) a single issue, phone call or disruption from a coworker, the cost of distraction to the developer is always atleast one hour on average.
With meetings these numbers go up significantly, which is why you never schedule meetings with developers unless it's strictly necessary and those meetings will have to be held earlies in the morning ( prior to them starting work ) or at the end of the workday ( after they finished their work ).
> There would be a serious resourcing problem if the issues don't even get triaged
So an hour of an individuals time has been spent on the issue ( if manually looked at ) and atleast an hour will be spent on it again until it enters the closed state in it's lifecycle.
High number of unmerged PR's is a clear indicator that a project lacks resources since PR have value higher than issues ( PR's more often than not save time ).
Obviously I'm just pointing out the calculation for the upstream maintainers as in I'm not bringing into the equation the time spent by the reporters, documentation writers qa's etc. ( which often get's ignored,overlooked since most people seem to be fixated strictly on the developers ) since when you looking at projects resources you look at the available pool of contributors time. ( not just the developers but everyone partaking in the project ).
Posted Apr 5, 2022 7:11 UTC (Tue)
by dtardon (subscriber, #53317)
[Link]
It's not. It only indicates that the project has got a lot of contributors. It would only be a clear indicator that the project lacks resources if the number were increasing over time.
Using (again) systemd as an example, there are 174 open PRs as I write this. When I substract PRs labeled "dont-merge" (22), "reviewed/needs-rework" (68), "ci-fails/needs-rework" (17), "needs-rebase" (28), or "needs-discussion" (35), I get 41 PRs. Let's also consider that systemd is now in stabilisation phase for release of v251, which means that only important PRs are being merged; others, even if approved, are postponed to be merged after the release.
Looking from the other side, the Insights page tells me that 181 PRs have been merged during the past month.
Side note: the reaction time of systemd upstream is amazing compared to other upstreams I've interacted with...
Systemd discusses its kernel-version needs
That an issue has been labelled ( you can call that label what you want, triage, RFE whatever ) just means two things a) the issue has been looked at ( or labelled automatically like we do in our projects ) and b) the bug will be looked at again ( otherwise it would not still remain open ).
Systemd discusses its kernel-version needs